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] MSR related clean up

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] MSR related clean up
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Wed, 24 Jun 2009 21:41:28 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Delivery-date: Wed, 24 Jun 2009 06:45:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C667C30B.E0C9%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>
References: <9832F13BD22FB94A829F798DA4A8280501B9C37A7F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C667C30B.E0C9%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acn0rTrEp/pda4dGTmWwsRs5r5DGUwAANMPbAABGSPAAAom+cgAFopRQ
Thread-topic: [Xen-devel] [PATCH] MSR related clean up
Keir Fraser wrote:
> On 24/06/2009 10:45, "Dong, Eddie" <eddie.dong@xxxxxxxxx> wrote:
> 
>> Returning 0 solves the security concern. But the argument is still
>> that if the guest should see same MSR sets with native. The CPUID
>> virtualization provides close features with native, but still not
>> identical. 
>> An ideal solution for those MSR read should consult guest CPUID and
>> then decide to either inject #GP if guest CPUID doesn't indicate
>> this MSR, or return a virtual MSR. In this case MSR write side
>> should provide the virtual MSR too.
> 
> Nice plan, but apart from my doubts about anyone actually bothering
> to a comprehensive job of this for current processors, there's also
> the problem that future processors may have MSRs detected via means
> such as model/family-id which we currently pass through.
> 
The simpliest change is to create the list of guest MSR so that guest 
read/write MSR can be correctly emulated. The size of guest MSR is probably not 
very big (several tens?). Of course we can have a detect of full guest MSR list 
at domain create time if guest CPUID (model/family etc) is same with native to 
keep architectural correctness. Of course the initial value can come from 
native.

A guest may use a non existing MSR to trigger into #GP handler. BTW those kind 
of native capability detect mechanism hurts migration.

Thx, eddie

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