WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: [Xen-devel] Re: One potential issue of shadow fault emulation
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 24 Dec 2007 18:27:21 +0000
Cc: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 24 Dec 2007 10:28:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20071224175710.GA27400@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchGWp8U3b8zRLJNEdyqVgAX8io7RQ==
Thread-topic: One potential issue of shadow fault emulation
User-agent: Microsoft-Entourage/11.3.6.070618
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