[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.