| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [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
|
|
|
| |
|
Home