[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |