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

Re: [Xen-devel][PATCH 2/2] Enhance MTRR/PAT virtualization for EPT & VT-

To: "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel][PATCH 2/2] Enhance MTRR/PAT virtualization for EPT & VT-d enabled both
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 23 Jan 2009 12:33:30 +0000
Cc:
Delivery-date: Fri, 23 Jan 2009 04:33:55 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C59F629D.1B61%keir.fraser@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acl8dpbanCB0DwW8TGmTMMt32OWsQQAA8//QAAMKI+cAAM3KkAACXeGIABwX57AAE8EARAABCpWp
Thread-topic: [Xen-devel][PATCH 2/2] Enhance MTRR/PAT virtualization for EPT & VT-d enabled both
User-agent: Microsoft-Entourage/12.14.0.081024
On 23/01/2009 12:03, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> Would it not be quite easy for ept_set_entry() to determine whether any
> gfn->mfn mapping has changed, since it can see the old EPTE as it modifies
> it? In which case why not have that function determine whether it needs to
> modify VT-d tables (i.e, default to 0 at top of function, and flip to 1 as
> soon as you see a gfn->mfn translation change)?
> 
> Now, I could accept your current patch if I'm missing something, because I
> prefer this new interface to the way you did it before, but perhaps you can
> hide this new flag entirely inside ept_set_entry() and avoid any extra
> interface complexity at all?

Or indeed would it be simpler to have ept_change_entry_emt_with_range()
contain the bits of ept_set_entry() it needs, rather than calling it? I'm
not sure about that -- I suppose it depends on how much of ept_set_entry()
would disappear if you basically inlined it. It might not make sense to take
this approach.

 -- Keir



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