[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: One potential issue of shadow fault emulation
Great! Can you guys please also test xen-3.1-testing c/s 15572. This is the equivalent, but rather different, fix for 3.1 branch. Thanks, Keir On 27/12/07 15:30, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> wrote: > Hi Keir, > I made tests on 2 kinds of platforms, and the previous weird > vTPR-related issues disappear using the c/s 16663; I believe the issues > have been fixed by the c/s. > > Thanks! > > -- Dexuan > > -----Original Message----- > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser > Sent: Thursday, December 27, 2007 8:24 PM > To: Jiang, Yunhong; Tim Deegan > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: [Xen-devel] Re: One potential issue of shadow fault emulation > > Can you please try xen-unstable c/s 16663. This implements Tim's good > idea > of mapping the apic page in the p2m with type mmio-direct rather than > type > ram. I had to do some rejigging in the changeset before that so that > gfn->mfn lookup failures do not inject #PF into the guest. I've done > enough > testing around this code to be confident it should work, but I don't > actually have a test machine to hand with this feature to do a proper > full-confidence test. > > We'll need a different patch for xen-3.1-testing, which is going to be > awkward since it doesn't have a typed p2m table. Probably __hvm_copy() > and > emulate_map_dest() will need to explicitly check for the apic access > page. > That, plus avoidance of injecting #PF in this case, should work okay. > > -- Keir > > On 21/12/07 14:58, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote: > >> Currently shadow fault handler try to emulate up to four extra >> instruction for PAE guest, to reduce vmexit times. >> >> But there is a potential issue here: Consider the second instruction > is >> a change to virtual TPR register. In physical environment, if the TPR >> acceleration is enabled, the cpu will try to access the >> VIRTUAL_APIC_PAGE_ADDR set in the VMCS. However, when we do emulation, >> we didn't cope with this situation, and will access the > APIC_ACCESS_ADDR >> page pointed by the shadow. This is sure cause problem to guest, > usually >> blue screen, and this issue will happen randomly depends on the > content >> in the apic access page. >> >> So how should we cope with such situation? Stop emulation or, continue >> emulate , but access the virtual APIC page? Or any better idea? >> >> Thanks >> -- Yunhong Jiang > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |