[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: One potential issue of shadow fault emulation

On 24/12/07 17:57, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx> wrote:

> At 21:54 +0000 on 21 Dec (1198274059), Keir Fraser wrote:
>> Probably gfn_to_mfn() should explicitly check for vmx_apic_access_mfn and
>> return INVALID_MFN instead. That will fix all emulation routines by causing
>> them to take their mmio path (or bail if they don't have them) which is the
>> correct behaviour for this case.
> That will disable the VMX TPR optimization too -- the p2m lookup needs
> to return this magic page when the shadow propagation code looks it up
> but not when other callers look it up.  Maybe the existing scheme for
> mapping MMIO pages directly would do; mark the page as direct MMIO
> instead of as RAM?  Otherwise at least one of the shadow propagation
> code and the emulator needs to special-case the vlapic page.

There are quite a few users of gfn-to-mfn functionality and only one of them
wants the magic page. So I think it'd be cleaner to push the vlapic check a
bit deeper than just the shadow emulation callbacks.

Can we wrap gfn_to_mfn for export outside the shadow code, get all
non-shadow propagation callers to use the wrapper, and stick the vlapic page
check in that? Or equivalently, move the current gfn_to_mfn code into a new
shadow-internal function that only the shadow-propagation code calls

 -- Keir

Xen-devel mailing list



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