RE: [Xen-devel]Two dead-lock situation occurs on 32bit HVM SMP Windows

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

Hi, Keir,
        Thanks for fixes and you're right that PV drivers themselves don't hit 
MMIO which however enlarges the possibility to trigger deadlock case 1. PV 
drivers invoke grant ops frequently which holds big lock in the start and then 
may request shadow lock later. This should disappear now after you remove the 
lock acquisition in page fault handler.

        It's a good suggestion to use one single entry to speed up LAPIC/IOAPIC 
access, and we will make a try and bench on it. :-)

Thanks,
Kevin

________________________________________
From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
Sent: 2006年11月5日 2:58
To: Xin, Xiaohui; xen-devel@xxxxxxxxxxxxxxxxxxx
Cc: Tian, Kevin; Li, Xin B; He, Qing; Mallick, Asit K; Li, Susie; Nakajima, Jun
Subject: Re: [Xen-devel]Two dead-lock situation occurs on 32bit HVM SMP Windows 

On 4/11/06 1:48 pm, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx> wrote:
Is there anything wrong with the description?
If we’re right, then does the spurious_page_fault() need to hold the BIGLOCK? 
We have an ugly workaround to decrease the occurring frequency of the 
spurious_page_fault(), that is we try to map all the 4G P2M table area and fill 
it with INVALID_MFN accordingly at P2M table allocated time. And with the 
workaround, the 32bit HVM SMP Windows with PV drivers can now run more 
smoothly, and can be destroyed successfully. But we have no elegant solution 
now. :-(
 
Does anyone have some good suggestions? Any comments are welcome.

The deadlocks were real. I’ve fixed them in xen–unstable changesets 12240 and 
12241. Thanks!

The PV drivers should not have been hitting the MMIO region with any regularity 
however. Is it the LAPIC and IOAPIC that are getting hit? It certainly makes 
sense to cover hot regions of the P2M table with valid mappings — we should not 
expect the fault-and-fixup path to be fast. A single extra pagetable with 
INVALID_MFN just below 4GB would I’m sure speed things up quite a bit!

 -- Keir

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel