linux-kernel - Re: [PATCH 02/43] KVM: VMX: Set EDX at INIT with CPUID.0x1, Family-Model-Stepping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 21 May 2021 15:28:15 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Reiji Watanabe <reijiw@...gle.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/43] KVM: VMX: Set EDX at INIT with CPUID.0x1,
 Family-Model-Stepping

On Fri, May 21, 2021, Reiji Watanabe wrote:
> On Wed, May 19, 2021 at 11:47 AM Sean Christopherson <seanjc@...gle.com> wrote:
> >
> > On Tue, May 18, 2021, Reiji Watanabe wrote:
> > > BTW, I would think having a default CPUID for CPUID.(EAX=0x1) would be better
> > > for consistency of a vCPU state for RESET.  I would think it doesn't matter
> > > practically anyway though.
> >
> > Probably, but that would require defining default values for all of CPUID.0x0 and
> > CPUID.0x1, which is a can of worms I'd rather not open.  E.g. vendor info, basic
> > feature set, APIC ID, etc... would all need default values.  On the other hand,
> > the EDX value stuffing predates CPUID, so using 0x600 isn't provably wrong, just
> > a bit anachronistic. :-)
> 
> I see... Then I don't think it's worth doing...
> Just out of curiosity, can't we simply use a vcpu_id for the APIC ID ?

That would mostly work, but theoretically we could overflow the 8 bit field
because max vCPUs is 288.  Thanks Larrabee.

  commit 682f732ecf7396e9d6fe24d44738966699fae6c0
  Author: Radim Krčmář <rkrcmar@...hat.com>
  Date:   Tue Jul 12 22:09:29 2016 +0200

    KVM: x86: bump MAX_VCPUS to 288

    288 is in high demand because of Knights Landing CPU.
    We cannot set the limit to 640k, because that would be wasting space.

> Also, can't we simply use the same values that KVM_GET_SUPPORTED_CPUID
> provides for other CPUID fields ?

Yes, that would mostly work.  It's certainly possible to have a moderately sane
default, but there's essentially zero benefit in doing so since practically
speaking all userspace VMMs will override CPUID anyways.  KVM could completely
default to the host CPUID, but again, it wouldn't provide any meaningful benefit,
while doing so would step on userspace's toes since KVM's approach is that KVM is
"just" an accelerator, while userspace defines the CPU model, devices, etc...
And it would also mean KVM has to start worrying about silly corner cases like
the max vCPUs thing.  That's why I say it's a can of worms :-)