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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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
directly?

 -- Keir



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