> From: Leon Romanovsky <leon@xxxxxxxxxx>
> Sent: Thursday, January 7, 2021 12:02 AM
>
> On Wed, Jan 06, 2021 at 11:23:39AM -0400, Jason Gunthorpe wrote:
> > On Wed, Jan 06, 2021 at 12:40:17PM +0200, Leon Romanovsky wrote:
> >
> > > I asked what will you do when QEMU will gain needed functionality?
> > > Will you remove QEMU from this list? If yes, how such "new" kernel will
> > > work on old QEMU versions?
> >
> > The needed functionality is some VMM hypercall, so presumably new
> > kernels that support calling this hypercall will be able to discover
> > if the VMM hypercall exists and if so superceed this entire check.
>
> Let's not speculate, do we have well-known path?
> Will such patch be taken to stable@/distros?
>
There are two functions introduced in this patch. One is to detect whether
running on bare metal or in a virtual machine. The other is for deciding
whether the platform supports ims. Currently the two are identical because
ims is supported only on bare metal at current stage. In the future it will look
like below when ims can be enabled in a VM:
bool arch_support_pci_device_ims(struct pci_dev *pdev)
{
return on_bare_metal() || hypercall_irq_domain_supported();
}
The VMM vendor list is for on_bare_metal, and suppose a vendor will
never be removed once being added to the list since the fact of running
in a VM never changes, regardless of whether this hypervisor supports
extra VMM hypercalls. hypercall_irq_domain_supported will actually
detect in hypervisor-specific way whether ims can be enabled in a VM
(return true only when a 'new' kernel runs on a 'new' hypervisor). In
this way no backporting is required when running a 'new' kernel on an
'old' hypervisor.
Thanks
Kevin
