On Mon, Mar 13, 2023 at 09:58:27AM -0700, Sean Christopherson wrote: > On Mon, Mar 13, 2023, Jason Chen CJ wrote: > > This patch set is part-5 of this RFC patches. It introduces VMX > > emulation for pKVM on Intel platform. > > > > Host VM wants the capability to run its guest, it needs VMX support. > > No, the host VM only needs a way to request pKVM to run a VM. If we go down the > rabbit hole of pKVM on x86, I think we should take the red pill[*] and go all the > way down said rabbit hole by heavily paravirtualizing the KVM=>pKVM interface. hi, Sean, Like I mentioned in the reply for "[RFC PATCH part-1 0/5] pKVM on Intel Platform Introduction", we hope VMX emulation can be there at least for normal VM support. > > Except for VMCALL vs. VMMCALL, it should be possible to eliminate all traces of > VMX and SVM from the interface. That means no VMCS emulation, no EPT shadowing, > etc. As a bonus, any paravirt stuff we do for pKVM x86 would also be usable for > KVM-on-KVM nested virtualization. > > E.g. an idea floating around my head is to add a paravirt paging interface for > KVM-on-KVM so that L1's (KVM-high in this RFC) doesn't need to maintain its own > TDP page tables. I haven't pursued that idea in any real capacity since most > nested virtualization use cases for KVM involve running an older L1 kernel and/or > a non-KVM L1 hypervisor, i.e. there's no concrete use case to justify the development > and maintenance cost. But if the PV code is "needed" by pKVM anyways... Yes, I agree, we could have performance & mem cost benefit by using paravirt stuff for KVM-on-KVM nested virtualization. May I know do I miss other benefit you saw? > > [*] You take the blue pill, the story ends, you wake up in your bed and believe > whatever you want to believe. You take the red pill, you stay in wonderland, > and I show you how deep the rabbit hole goes. > > -Morpheus -- Thanks Jason CJ Chen
