[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH]: Add support for Intel CPUID Feature mask in Xen
> > It's good to see this feature enabled, but it would be a lot more user > > friendly if the patch took a cpu family and model number and then > > 'flattened' the cpuid back to the specification of that CPU. We don't > > need to go back very far (certainly not pre-VT), and I'd be happy if > > we just did all core2 (and newer) CPUs. > > > We also hesitate how to solve it for some time. Yet we found since cpu > models are quite much even from core2, finding each of them is not that > easy > (cpuid.1.ECX:EDX might only could be referred in corresponding BIOS > guide). > > Also, if using one older type that we did not cover, then there's some > problem. > What's more, ecx/edx only give few features that users might do care. > So maybe users should know by themselves on how to set the few bits > to 0 and passes others just 1. Well, if someone from Intel can't figure it out what hope have users got! I think it would be much better if we cooked this to a family/model number. > > Also, is there a magic MSR to change the CPU family/model number > > reported? It would make sense to do this too. > Oh, No, there are no such magic MSR. Only cpuid.1.ECX:EDX could be > masked. That's a shame. Are you 100% sure? I know it's possible for the BIOS to configure MSRs to hide certain differences, because I've seen two CPUs with different steppings get levelled to the same (older) stepping by a BIOS upgrade. > > At what point does the CPU masking occur? Ideally we'd do it just > > before starting dom0. [Actually, we might want to be able to invoke > > it from libxc in future too] > When setting cpuid_mask, both HV and all domains will all be cheated > from this > point, it is a hardware and-logic . > So for consistency, we set the msr from xen start time after detecting > cpu. > Seems setting@xen startup Or setting@domain0 startup > will not make a big difference here? That's not necessarily the case -- we may want Xen to use features that we hide from guests. Ian _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |