Message-ID: <CADH9ctA_C1dAOus1K+wOH_SOKTb=-X1sVawt5R=dkH1iGt8QUg@mail.gmail.com>
Date: Tue, 12 Nov 2024 15:44:11 -0500
From: Doug Covelli <doug.covelli@...adcom.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Zack Rusin <zack.rusin@...adcom.com>, Sean Christopherson <seanjc@...gle.com>, 
	kvm <kvm@...r.kernel.org>, Jonathan Corbet <corbet@....net>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "the arch/x86 maintainers" <x86@...nel.org>, 
	"H. Peter Anvin" <hpa@...or.com>, Shuah Khan <shuah@...nel.org>, Namhyung Kim <namhyung@...nel.org>, 
	Arnaldo Carvalho de Melo <acme@...hat.com>, Isaku Yamahata <isaku.yamahata@...el.com>, 
	Joel Stanley <joel@....id.au>, Linux Doc Mailing List <linux-doc@...r.kernel.org>, 
	"Kernel Mailing List, Linux" <linux-kernel@...r.kernel.org>, 
	linux-kselftest <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH 2/3] KVM: x86: Add support for VMware guest specific hypercalls

On Tue, Nov 12, 2024 at 12:44 PM Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> Il lun 11 nov 2024, 21:55 Doug Covelli <doug.covelli@...adcom.com> ha scritto:
> >
> > BDOOR_CMD_VCPU_MMIO_HONORS_PAT and BDOOR_CMD_VCPU_LEGACY_X2APIC_OK are not
> > actually backdoor calls - they are flags returned by BDOOR_CMD_GET_VCPU_INFO.
> >
> > BDOOR_CMD_VCPU_MMIO_HONORS_PAT is only ever set to 1 on ESX as it is only
> > relevant for PCI passthru which is not supported on Linux/Windows/macOS.  IIRC
> > this was added over 10 years ago for some Infiniband device vendor to use in
> > their driver although I'm not sure that ever materialized.
>
> Ok. So I guess false is safe.
>
> > BDOOR_CMD_VCPU_LEGACY_X2APIC_OK indicates if it is OK to use x2APIC w/o
> > interrupt remapping (e.g a virtual IOMMU).  I'm not sure if KVM supports this
> > but I think this one can be set to TRUE unconditionally as we have no plans to
> > use KVM_CREATE_IRQCHIP - if anything we would use KVM_CAP_SPLIT_IRQCHIP although
> > my preference would be to handle all APIC/IOAPIC/PIC emulation ourselves
> > provided we can avoid CR8 exits but that is another discussion.
>
> Split irqchip should be the best tradeoff. Without it, moves from cr8
> stay in the kernel, but moves to cr8 always go to userspace with a
> KVM_EXIT_SET_TPR exit. You also won't be able to use Intel
> flexpriority (in-processor accelerated TPR) because KVM does not know
> which bits are set in IRR. So it will be *really* every move to cr8
> that goes to userspace.

Sorry to hijack this thread but is there a technical reason not to allow CR8
based accesses to the TPR (not MMIO accesses) when the in-kernel local APIC is
not in use?  Both MSFT's WHP and Apple's hypervisor framework allow this and it
seems like it would be generally useful for any Hypervisor that does not want to
use the in-kernel APIC but still want to run Windows guests with decent
performance.

When we switched to WHP the biggest source of problems by far was from trying
to integrate our monitor with MSFT's APIC emulation code.  Even if we do want
to use the KVM in-kernel APIC at some point in the future it is still nice to
be able to fall back on our own APIC emulation code if necessary.

Also I could not find these documented anywhere but with MSFT's APIC our monitor
relies on extensions for trapping certain events such as INIT/SIPI plus LINT0
and SVR writes:

UINT64 X64ApicInitSipiExitTrap    : 1; // WHvRunVpExitReasonX64ApicInitSipiTrap
UINT64 X64ApicWriteLint0ExitTrap  : 1; // WHvRunVpExitReasonX64ApicWriteTrap
UINT64 X64ApicWriteLint1ExitTrap  : 1; // WHvRunVpExitReasonX64ApicWriteTrap
UINT64 X64ApicWriteSvrExitTrap    : 1; // WHvRunVpExitReasonX64ApicWriteTrap

I did not see any similar functionality for KVM.  Does anything like that exist?
In any case we would be happy to add support for handling CR8 accesses w/o
exiting w/o the in-kernel APIC along with some sort of a way to configure the
TPR threshold if folks are not opposed to that.

Doug

> > For now I think it makes sense to handle BDOOR_CMD_GET_VCPU_INFO at userlevel
> > like we do on Windows and macOS.
> >
> > BDOOR_CMD_GETTIME/BDOOR_CMD_GETTIMEFULL are similar with the former being
> > deprecated in favor of the latter.  Both do essentially the same thing which is
> > to return the host OS's time - on Linux this is obtained via gettimeofday.  I
> > believe this is mainly used by tools to fix up the VM's time when resuming from
> > suspend.  I think it is fine to continue handling these at userlevel.
>
> As long as the TSC is not involved it should be okay.
>
> Paolo
>
> > > >> Anyway, one question apart from this: is the API the same for the I/O
> > > >> port and hypercall backdoors?
> > > >
> > > > Yeah the calls and arguments are the same.  The hypercall based
> > > > interface is an attempt to modernize the backdoor since as you pointed
> > > > out the I/O based interface is kind of hacky as it bypasses the normal
> > > > checks for an I/O port access at CPL3.  It would be nice to get rid of
> > > > it but unfortunately I don't think that will happen in the foreseeable
> > > > future as there are a lot of existing VMs out there with older SW that
> > > > still uses this interface.
> > >
> > > Yeah, but I think it still justifies that the KVM_ENABLE_CAP API can
> > > enable the hypercall but not the I/O port.
> > >
> > > Paolo
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

Powered by blists - more mailing lists