On Mon, Nov 11, 2024 at 1:49 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 11/9/24 22:11, Doug Covelli wrote: > > On Sat, Nov 9, 2024 at 1:20 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > >> On 11/8/24 06:03, Zack Rusin wrote: > >>>>> There's no spec but we have open headers listing the hypercalls. > >>>>> There's about a 100 of them (a few were deprecated), the full > >>>>> list starts here: > >>>>> https://github.com/vmware/open-vm-tools/blob/739c5a2f4bfd4cdda491e6a6f6869d88c0bd6972/open-vm-tools/lib/include/backdoor_def.h#L97 > >>>>> They're not well documented, but the names are pretty self-explenatory. > >>>> > >>>> At a quick glance, this one needs to be handled in KVM: > >>>> > >>>> BDOOR_CMD_VCPU_MMIO_HONORS_PAT > >>>> > >>>> and these probably should be in KVM: > >>>> > >>>> BDOOR_CMD_GETTIME > >>>> BDOOR_CMD_SIDT > >>>> BDOOR_CMD_SGDT > >>>> BDOOR_CMD_SLDT_STR > >>>> BDOOR_CMD_GETTIMEFULL > >>>> BDOOR_CMD_VCPU_LEGACY_X2APIC_OK > >>>> BDOOR_CMD_STEALCLOCK > >>> > >>> I'm not sure if there's any value in implementing a few of them. > >> > >> The value is that some of these depend on what the hypervisor does, not > >> on what userspace does. For Hypervisor.framework you have a lot of > >> leeway, for KVM and Hyper-V less so. [..] From the KVM maintainers' > >> point of view, the feature you're adding might be used by others and > >> not just VMware Workstation. Microsoft and Apple might see things > >> differently (Apple in particular has a much thinner wrapper around > >> the processor's virtualization capbilities). > > > > [...] > > > > the SGDT/SLDT/STR/SIDT backdoor calls these were added > 20 > > years ago for SW that used these instructions from CPL3 which did not > > work well before VT/SVM were introduced. These are really of no use > > on modern CPUs and will be blocked if the guest OS has enabled UMIP. > > [...] > > > > For stolen time the backdoor call is [...] currently > > really only supported by ESX (and only currently used by Photon OS) so > > I don't think adding that support to KVM is critical. > > Sounds good. All I want is ensuring that someone with access to the > spec did the exercise. > > Still guessing, but for MMIO_HONORS_PAT we probably want to add a > separate KVM_CHECK_EXTENSION capability. > > Is BDOOR_CMD_VCPU_LEGACY_X2APIC_OK something where you can just return a > constant? > > This leaves just GETTIME and GETTIMEFULL. If four hypercalls require > some care in the hypervisor (which may or may not be an in-kernel > implementation), that's not bad. Can you share a bit more about these four? 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. 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. 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. Doug > >> 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.
