linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Leon Romanovsky <leon@kernel.org>, Lu Baolu <baolu.lu@linux.intel.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"Raj, Ashok" <ashok.raj@intel.com>,
	"Jiang, Dave" <dave.jiang@intel.com>,
	"Dey, Megha" <megha.dey@intel.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"kwankhede@nvidia.com" <kwankhede@nvidia.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"maz@kernel.org" <maz@kernel.org>,
	"Hossain, Mona" <mona.hossain@intel.com>,
	"netanelg@mellanox.com" <netanelg@mellanox.com>,
	"parav@mellanox.com" <parav@mellanox.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"Ortiz, Samuel" <samuel.ortiz@intel.com>,
	"Kumar, Sanjay K" <sanjay.k.kumar@intel.com>,
	"shahafs@mellanox.com" <shahafs@mellanox.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"yan.y.zhao@linux.intel.com" <yan.y.zhao@linux.intel.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>
Subject: RE: [RFC PATCH v2 1/1] platform-msi: Add platform check for subdevice irq domain
Date: Tue, 12 Jan 2021 06:59:35 +0000	[thread overview]
Message-ID: <MWHPR11MB188672D9BB76B2C5E04934138CAA0@MWHPR11MB1886.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20210112055322.GA4678@unreal>

> From: Leon Romanovsky <leon@kernel.org>
> Sent: Tuesday, January 12, 2021 1:53 PM
> 
> On Tue, Jan 12, 2021 at 01:17:11PM +0800, Lu Baolu wrote:
> > Hi,
> >
> > On 1/7/21 3:16 PM, Leon Romanovsky wrote:
> > > On Thu, Jan 07, 2021 at 06:55:16AM +0000, Tian, Kevin wrote:
> > > > > From: Leon Romanovsky <leon@kernel.org>
> > > > > Sent: Thursday, January 7, 2021 2:09 PM
> > > > >
> > > > > On Thu, Jan 07, 2021 at 02:04:29AM +0000, Tian, Kevin wrote:
> > > > > > > From: Leon Romanovsky <leon@kernel.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@/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.
> > > > >
> > > > > This is what I imagined, this list will be forever, and this worries me.
> > > > >
> > > > > I don't know if it is true or not, but guess that at least Oracle and
> > > > > Microsoft bare metal devices and VMs will have same
> DMI_SYS_VENDOR.
> > > >
> > > > It's true. David Woodhouse also said it's the case for Amazon EC2
> instances.
> > > >
> > > > >
> > > > > It means that this on_bare_metal() function won't work reliably in
> many
> > > > > cases. Also being part of include/linux/msi.h, at some point of time,
> > > > > this function will be picked by the users outside for the non-IMS cases.
> > > > >
> > > > > I didn't even mention custom forks of QEMU which are prohibited to
> change
> > > > > DMI_SYS_VENDOR and private clouds with custom solutions.
> > > >
> > > > In this case the private QEMU forks are encouraged to set CPUID (X86_
> > > > FEATURE_HYPERVISOR) if they do plan to adopt a different vendor
> name.
> > >
> > > Does QEMU set this bit when it runs in host-passthrough CPU model?
> > >
> > > >
> > > > >
> > > > > The current array makes DMI_SYS_VENDOR interface as some sort of
> ABI. If
> > > > > in the future,
> > > > > the QEMU will decide to use more hipster name, for example "qEmU",
> this
> > > > > function
> > > > > won't work.
> > > > >
> > > > > I'm aware that DMI_SYS_VENDOR is used heavily in the kernel code
> and
> > > > > various names for the same company are good example how not
> reliable it.
> > > > >
> > > > > The most hilarious example is "Dell/Dell Inc./Dell Inc/Dell Computer
> > > > > Corporation/Dell Computer",
> > > > > but other companies are not far from them.
> > > > >
> > > > > Luckily enough, this identification is used for hardware product that
> > > > > was released to the market and their name will be stable for that
> > > > > specific model. It is not the case here where we need to ensure future
> > > > > compatibility too (old kernel on new VM emulator).
> > > > >
> > > > > I'm not in position to say yes or no to this patch and don't have plans
> to do it.
> > > > > Just expressing my feeling that this solution is too hacky for my taste.
> > > > >
> > > >
> > > > I agree with your worries and solely relying on DMI_SYS_VENDOR is
> > > > definitely too hacky. In previous discussions with Thomas there is no
> > > > elegant way to handle this situation. It has to be a heuristic approach.
> > > > First we hope the CPUID bit is set properly in most cases thus is checked
> > > > first. Then other heuristics can be made for the remaining cases. DMI_
> > > > SYS_VENDOR is the first hint and more can be added later. For example,
> > > > when IOMMU is present there is vendor specific way to detect whether
> > > > it's real or virtual. Dave also mentioned some BIOS flag to indicate a
> > > > virtual machine. Now probably the real question here is whether people
> > > > are OK with CPUID+DMI_SYS_VENDOR combo check for now (and grow
> > > > it later) or prefer to having all identified heuristics so far in-place
> together...
> > >
> > > IMHO, it should be as much as possible close to the end result.
> >
> > Okay! This seems to be a right way to go.
> >
> > The SMBIOS defines a 'virtual machine' bit in the BIOS characteristics
> > extension byte. It could be used as a possible way.
> >
> > In order to support emulated IOMMU for fully virtualized guest, the
> > iommu vendors defined methods to distinguish between bare metal and
> VMM
> > (caching mode in VT-d for example).
> >
> > I will go ahead with adding above two methods before checking the block
> > list.
> 
> I still curious to hear an answer on my question above:
> "Does QEMU set this bit when it runs in host-passthrough CPU model?"

Yes, the bit is also set in this model.

Thanks
Kevin

  reply	other threads:[~2021-01-12  7:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06  2:27 Lu Baolu
2021-01-06  6:06 ` Leon Romanovsky
2021-01-06 10:10   ` Lu Baolu
2021-01-06 10:40     ` Leon Romanovsky
2021-01-06 15:23       ` Jason Gunthorpe
2021-01-06 16:01         ` Leon Romanovsky
2021-01-07  1:55           ` Lu Baolu
2021-01-07  2:04           ` Tian, Kevin
2021-01-07  6:09             ` Leon Romanovsky
2021-01-07  6:55               ` Tian, Kevin
2021-01-07  7:16                 ` Leon Romanovsky
2021-01-12  5:17                   ` Lu Baolu
2021-01-12  5:53                     ` Leon Romanovsky
2021-01-12  6:59                       ` Tian, Kevin [this message]
2021-01-12  7:34                         ` Leon Romanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MWHPR11MB188672D9BB76B2C5E04934138CAA0@MWHPR11MB1886.namprd11.prod.outlook.com \
    --to=kevin.tian@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger@redhat.com \
    --cc=jacob.jun.pan@intel.com \
    --cc=jgg@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=megha.dey@intel.com \
    --cc=mona.hossain@intel.com \
    --cc=netanelg@mellanox.com \
    --cc=parav@mellanox.com \
    --cc=pbonzini@redhat.com \
    --cc=rafael@kernel.org \
    --cc=samuel.ortiz@intel.com \
    --cc=sanjay.k.kumar@intel.com \
    --cc=shahafs@mellanox.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vkoul@kernel.org \
    --cc=yan.y.zhao@linux.intel.com \
    --cc=yi.l.liu@intel.com \
    --subject='RE: [RFC PATCH v2 1/1] platform-msi: Add platform check for subdevice irq domain' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).