On Mon, Feb 27, 2023, Yu Zhang wrote: > On Fri, Feb 24, 2023 at 08:16:40AM -0800, Sean Christopherson wrote: > > On Fri, Feb 24, 2023, Yu Zhang wrote: > > > But why it is related to nested migration? > > > > I understand why it's related, but I don't understand why we bothered to add "support" > > for this. > > > > In theory, if L1 is migrated by L0 while L1 is running an L2 that uses SYSENTER, > > problems will occur. I'm a bit lost as to how this matters in practice, as KVM > > doesn't support cross-vendor nested virtualization, and if L1 can be enlightened > > to the point where it can switch from VMX=>SVM during migration, what's the point > > of doing a migration? > > Oh. So that is what people call "nested migration". I had thought "nested > migration" is to migrate L2. Instead, it is still a migration of L1 with > VMX/SVM capability... :( More or less, yes. I personally would prefer a less ambiguous description, e.g. "migration with nested VMs", but unfortunately I can't mind control others :-) > Is it a possible scenario that: > 1> A L1 VM is created on Intel platform, with VMX capability virtualized > to it. > 2> The SYSENTER_EIP/ESP is set to a 64-bit value in L1. > 3> Before creating a L2 VM, this L1 VM is migrated to a AMD machine. > 4> The migrated L1 VM is exposed with SVM capability. > 5> And then when L1 tries to create L2, the virtual vmload/vmsave shall > be disabled. > > But is step 4> a valid operation in KVM? It's valid in KVM (as L0), but I don't see how L1 can handle it cleanly without an absurd level of enlightenment. And if L1 is highly enlightened, I don't see why it's desirable to do cross-vendor migration of the VM.
