RE: [Xen-devel] [PATCH] MSR related clean up

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

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