All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>
Cc: kvm@vger.kernel.org, Sean Christopherson <seanjc@google.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: x86: Forbid KVM_SET_CPUID{,2} after KVM_RUN
Date: Thu, 13 Jan 2022 16:41:54 +0200	[thread overview]
Message-ID: <6ae7e64c53727f9f00537d787e9612c292c4e244.camel@redhat.com> (raw)
In-Reply-To: <87zgnzn1nr.fsf@redhat.com>

On Thu, 2022-01-13 at 15:36 +0100, Vitaly Kuznetsov wrote:
> Maxim Levitsky <mlevitsk@redhat.com> writes:
> 
> > On Thu, 2022-01-13 at 10:27 +0100, Vitaly Kuznetsov wrote:
> > > Paolo Bonzini <pbonzini@redhat.com> writes:
> > > 
> > > > On 1/12/22 14:58, Vitaly Kuznetsov wrote:
> > > > > -	best = kvm_find_cpuid_entry(vcpu, 0xD, 1);
> > > > > +	best = cpuid_entry2_find(entries, nent, 0xD, 1);
> > > > >   	if (best && (cpuid_entry_has(best, X86_FEATURE_XSAVES) ||
> > > > >   		     cpuid_entry_has(best, X86_FEATURE_XSAVEC)))
> > > > >   		best->ebx = xstate_required_size(vcpu->arch.xcr0, true);
> > > > >   
> > > > > -	best = kvm_find_kvm_cpuid_features(vcpu);
> > > > > +	best = __kvm_find_kvm_cpuid_features(vcpu, vcpu->arch.cpuid_entries,
> > > > > +					     vcpu->arch.cpuid_nent);
> > > > >   	if (kvm_hlt_in_guest(vcpu->kvm) && best &&
> > > > 
> > > > I think this should be __kvm_find_kvm_cpuid_features(vcpu, entries, nent).
> > > > 
> > > 
> > > Of course.
> > > 
> > > > > +		case 0x1:
> > > > > +			/* Only initial LAPIC id is allowed to change */
> > > > > +			if (e->eax ^ best->eax || ((e->ebx ^ best->ebx) >> 24) ||
> > > > > +			    e->ecx ^ best->ecx || e->edx ^ best->edx)
> > > > > +				return -EINVAL;
> > > > > +			break;
> > > > 
> > > > This XOR is a bit weird.  In addition the EBX test is checking the wrong 
> > > > bits (it checks whether 31:24 change and ignores changes to 23:0).
> > > 
> > > Indeed, however, I've tested CPU hotplug with QEMU trying different
> > > CPUs in random order and surprisingly othing blew up, feels like QEMU
> > > was smart enough to re-use the right fd)
> > > 
> > > > You can write just "(e->ebx & ~0xff000000u) != (best->ebx ~0xff000000u)".
> > > > 
> > > > > +		default:
> > > > > +			if (e->eax ^ best->eax || e->ebx ^ best->ebx ||
> > > > > +			    e->ecx ^ best->ecx || e->edx ^ best->edx)
> > > > > +				return -EINVAL;
> > > > 
> > > > This one even more so.
> > > 
> > > Thanks for the early review, I'm going to prepare a selftest and send
> > > this out.
> > > 
> > I also looked at this recently (due to other reasons) and I found out that
> > qemu picks a parked vcpu by its vcpu_id which is its initial apic id,
> > thus apic id related features should not change.
> > 
> > Take a look at 'kvm_get_vcpu' in qemu source.
> > Maybe old qemu versions didn't do this?
> 
> I took Igor's word on this, I didn't check QEMU code :-)
> 
> In the v1 I've just sent [L,x2]APIC ids are allowed to change. This
> shouldn't screw the MMU (which was the main motivation for forbidding
> KVM_SET_CPUID{,2} after KVM_RUN in the first place) but maybe we don't
> really need to be so permissive.
> 

For my nested AVIC work I would really want the APIC ID of a VCPU to be read-only
and be equal to vcpu_id.

That simplifies lot of things, and in practice it is hightly likely that no guests
change their APIC id, and likely that qemu doesn't as well.

Best regards,
	Maxim Levitsky





  reply	other threads:[~2022-01-13 14:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-22 17:58 [PATCH 0/2] KVM: x86: Forbid KVM_SET_CPUID{,2} after KVM_RUN Vitaly Kuznetsov
2021-11-22 17:58 ` [PATCH 1/2] KVM: selftests: Avoid KVM_SET_CPUID2 after KVM_RUN in hyperv_features test Vitaly Kuznetsov
2021-11-22 17:58 ` [PATCH 2/2] KVM: x86: Forbid KVM_SET_CPUID{,2} after KVM_RUN Vitaly Kuznetsov
2021-11-26 12:20   ` Paolo Bonzini
2021-12-27 17:32     ` Igor Mammedov
2022-01-02 17:31       ` Paolo Bonzini
2022-01-03  8:04         ` Vitaly Kuznetsov
2022-01-03  9:40           ` Igor Mammedov
2022-01-03 12:56             ` Vitaly Kuznetsov
2022-01-05  8:17               ` Igor Mammedov
2022-01-05  9:12                 ` Vitaly Kuznetsov
2022-01-05  9:10               ` Paolo Bonzini
2022-01-05 10:09                 ` Vitaly Kuznetsov
2022-01-07  9:02                   ` Vitaly Kuznetsov
2022-01-07 18:15                     ` Paolo Bonzini
2022-01-11  8:00                       ` Igor Mammedov
2022-01-12 13:58                         ` Vitaly Kuznetsov
2022-01-12 18:39                           ` Paolo Bonzini
2022-01-13  9:27                             ` Vitaly Kuznetsov
2022-01-13 14:28                               ` Maxim Levitsky
2022-01-13 14:36                                 ` Vitaly Kuznetsov
2022-01-13 14:41                                   ` Maxim Levitsky [this message]
2022-01-13 14:59                                     ` Vitaly Kuznetsov
2022-01-13 16:26                                       ` Sean Christopherson
2022-01-13 16:30                                         ` Maxim Levitsky
2022-01-13 22:33             ` Sean Christopherson
2022-01-14  8:28               ` Maxim Levitsky
2022-01-14 16:08                 ` Sean Christopherson
2022-01-14  8:55               ` Igor Mammedov
2022-01-14  9:31                 ` Vitaly Kuznetsov
2022-01-14 11:22                   ` Igor Mammedov
2022-01-14 12:25                     ` Vitaly Kuznetsov
2022-01-14 17:00                       ` Sean Christopherson
2022-01-17  9:55                         ` Vitaly Kuznetsov
2022-01-17 11:20                           ` Paolo Bonzini
2022-01-17 13:02                             ` Vitaly Kuznetsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6ae7e64c53727f9f00537d787e9612c292c4e244.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.