On Wed, May 19, 2021 at 11:47 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Tue, May 18, 2021, Reiji Watanabe wrote: > > > @@ -4504,7 +4505,11 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) > > > > > > vmx->msr_ia32_umwait_control = 0; > > > > > > - vmx->vcpu.arch.regs[VCPU_REGS_RDX] = get_rdx_init_val(); > > > + eax = 1; > > > + if (!kvm_cpuid(vcpu, &eax, &dummy, &dummy, &dummy, true)) > > > + eax = get_rdx_init_val(); > > > + kvm_rdx_write(vcpu, eax); > > > > Reviewed-by: Reiji Watanabe <reijiw@xxxxxxxxxx> > > > > For RESET, I assume that rdx should be set by userspace > > when userspace changes CPUID.0x1.EAX. > > Ya, although the ideal solution is to add a proper RESET ioctl() so userspace can > configure the vCPU model and then pull RESET#. Thank you so much for the answer ! It sounds like a good idea in terms of userspace handling as well as KVM implementation (I assume it would be something similar to KVM_ARM_VCPU_INIT). > > 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 ? Also, can't we simply use the same values that KVM_GET_SUPPORTED_CPUID provides for other CPUID fields ? Thanks, Reiji
