linux-kernel - RE: [RFC PATCH v2 1/1] platform-msi: Add platform check for subdevice irq domain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MWHPR11MB18867EE2F4FA0382DCFEEE2B8CAF0@MWHPR11MB1886.namprd11.prod.outlook.com>
Date:   Thu, 7 Jan 2021 02:04:29 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Leon Romanovsky <leon@...nel.org>, Jason Gunthorpe <jgg@...dia.com>
CC:     Lu Baolu <baolu.lu@...ux.intel.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "Dey, Megha" <megha.dey@...el.com>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "eric.auger@...hat.com" <eric.auger@...hat.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "kwankhede@...dia.com" <kwankhede@...dia.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "maz@...nel.org" <maz@...nel.org>,
        "Hossain, Mona" <mona.hossain@...el.com>,
        "netanelg@...lanox.com" <netanelg@...lanox.com>,
        "parav@...lanox.com" <parav@...lanox.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "Ortiz, Samuel" <samuel.ortiz@...el.com>,
        "Kumar, Sanjay K" <sanjay.k.kumar@...el.com>,
        "shahafs@...lanox.com" <shahafs@...lanox.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        "yan.y.zhao@...ux.intel.com" <yan.y.zhao@...ux.intel.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>
Subject: RE: [RFC PATCH v2 1/1] platform-msi: Add platform check for subdevice
 irq domain

> From: Leon Romanovsky <leon@...nel.org>
> 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@...stros?
> 

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