[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |