On Tue, 2022-03-15 at 23:10 +0800, Chao Gao wrote: > On Sun, Mar 13, 2022 at 05:09:08PM +0200, Maxim Levitsky wrote: > > > > > This won't work with nested AVIC - we can't just inhibit a nested guest using its own AVIC, > > > > > because migration happens. > > > > > > > > I mean because host decided to change its apic id, which it can in theory do any time, > > > > even after the nested guest has started. Seriously, the only reason guest has to change apic id, > > > > is to try to exploit some security hole. > > > > > > Hi > > > > > > Thanks for the information. > > > > > > IIUC, you mean KVM applies APICv inhibition only to L1 VM, leaving APICv > > > enabled for L2 VM. Shouldn't KVM disable APICv for L2 VM in this case? > > > It looks like a generic issue in dynamically toggling APICv scheme, > > > e.g., qemu can set KVM_GUESTDBG_BLOCKIRQ after nested guest has started. > > > > > > > That is the problem - you can't disable it for L2, unless you are willing to emulate it in software. > > Or in other words, when nested guest uses a hardware feature, you can't at some point say to it: > > sorry buddy - hardware feature disappeared. > > Hi Maxim, > > I may miss something. When reading Sean's APICv inhibition cleanups, I > find AVIC is disabled for L1 when nested is enabled (SVM is advertised > to L1). Then, I think the new inhibition introduced for changed xAPIC ID > shouldn't be a problem for L2 VM. Or, you plan to remove > APICV_INHIBIT_REASON_NESTED and expose AVIC to L1? Yep, I have a patch for this ( which I hope to be accepted really soon (KVM: x86: SVM: allow AVIC to co-exist with a nested guest running) I also implemented working support for nested AVIC, which includes support for IPI without vm exits between L2's vCPUs. I had sent an RFC for that. With all patches applied both L1 and L2 switch hands on AVIC, L1's avic is inhibited (only locally) on the vCPU which runs nested, and while it runs nested, L2 uses AVIC to target other vCPUs which also run nested. I and Paolo talked about this, and we reached a very promising conclusion. I will add new KVM cap, say KVM_CAP_READ_ONLY_APIC, which userspace will set prior to creating a vCPU, and which will make APIC ID fully readonly when set. As a bonus, if you don't object, I will also make this cap, make APIC base read-only, since this feature is also broken in kvm, optional in x86 spec, and not really used by guests just like writable apic id. I hope to have patches in day or two for this. When this cap is not set, it is fair to disable both IPIv, my nested AVIC, or even better inhibit AVIC completely, including any nested support. Best regards, Maxim Levitsky > > svm_vcpu_after_set_cpuid: > /* > * Currently, AVIC does not work with nested virtualization. > * So, we disable AVIC when cpuid for SVM is set in the L1 guest. > */ > if (nested && guest_cpuid_has(vcpu, X86_FEATURE_SVM)) > kvm_request_apicv_update(vcpu->kvm, false, > APICV_INHIBIT_REASON_NESTED); >
