[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's



On Wed, 2012-05-02 at 10:50 +0100, Michael S. Tsirkin wrote:
> On Wed, May 02, 2012 at 10:45:27AM +0100, Ian Campbell wrote:
> > On Tue, 2012-05-01 at 16:04 +0300, Gleb Natapov wrote:
> > > > BTW, according to arch/x86/include/asm/kvm_para.h unsurprisingly KVM has
> > > > a signature too 'KVMKVMKVM'.
> > > > 
> > > > >       cpu->stepping = eax & 0xf;
> > > > >       cpu->model = (eax >> 4) & 0xf;
> > > > >       cpu->family = (eax >> 8) & 0xf;
> > > > > @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu)
> > > > >  
> > > > >       cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL);
> > > > >       cpu->maxei2 = maxei;
> > > > > +     if (ecx & 0x80000000) {
> > > > > +             cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, 
> > > > > NULL);
> > > > > +             /*
> > > > > +              * KVM up to linux 3.4 reports 0 as the max hypervisor 
> > > > > leaf,
> > > > > +              * where it really means 0x40000001.
> > > > 
> > > > This is something where I definitely think you want to check the
> > > > signature first.
> > > In theory yes, but in practice what will this break?
> > 
> > I've got no idea -- but what's the harm in checking?
> > 
> > Ian.
> 
> Users can set kvm signature to anything, if they do
> debugging will be a bit harder for them.

Ah, right, someone already mentioned that and I forgot, sorry.

And, just to complete my train of thought, cpuid just returns reserved
values for requests for non-existent leaves (rather than #GP for
example) so it's safe enough even if you do end up trying to read an
eax=0x40000001 when it doesn't exist.

Seems fine to me then.

Ian.

-- 
Ian Campbell
Current Noise: Hypocrisy - Buried

He's like a function -- he returns a value, in the form of his opinion.
It's up to you to cast it into a void or not.
                -- Phil Lapsley


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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