Re: [RFC PATCH part-5 00/22] VMX emulation

[Jason Chen CJ <jason.cj.chen@intel.com>]

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