[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.