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

From: "Tian, Kevin" <kevin.tian@intel.com>
To: David Woodhouse <dwmw2@infradead.org>,
	Lu Baolu <baolu.lu@linux.intel.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>
Cc: "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>,
	"jgg@mellanox.com" <jgg@mellanox.com>,
	"jing.lin@intel.com" <jing.lin@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 1/1] platform-msi: Add platform check for subdevice irq domain
Date: Thu, 7 Jan 2021 07:01:38 +0000	[thread overview]
Message-ID: <MWHPR11MB1886B23293B64C26B5C4B0458CAF0@MWHPR11MB1886.namprd11.prod.outlook.com> (raw)
In-Reply-To: <dad0bf6e271532badd84f2a811449be566f537a9.camel@infradead.org>

> From: David Woodhouse <dwmw2@infradead.org>
> Sent: Thursday, December 10, 2020 4:23 PM
> 
> On Thu, 2020-12-10 at 08:46 +0800, Lu Baolu wrote:
> > +/*
> > + * We want to figure out which context we are running in. But the
> hardware
> > + * does not introduce a reliable way (instruction, CPUID leaf, MSR,
> whatever)
> > + * which can be manipulated by the VMM to let the OS figure out where it
> runs.
> > + * So we go with the below probably_on_bare_metal() function as a
> replacement
> > + * for definitely_on_bare_metal() to go forward only for the very simple
> reason
> > + * that this is the only option we have.
> > + */
> > +static const char * const possible_vmm_vendor_name[] = {
> > +       "QEMU", "Bochs", "KVM", "Xen", "VMware", "VMW", "VMware Inc.",
> > +       "innotek GmbH", "Oracle Corporation", "Parallels", "BHYVE",
> > +       "Microsoft Corporation"
> > +};
> 
> People do use SeaBIOS ("Bochs") on bare metal.
> 
> You'll also see "Amazon EC2" on virt instances as well as bare metal
> instances. Although in that case I believe the virt instances do have
> the 'virtual machine' flag set in bit 4 of the BIOS Characteristics
> Extension Byte 2, and the bare metal obviously don't.
> 

Are those virtual instances having CPUID hypervisor bit set? If yes,
they can be differentiated from bare metal instances w/o checking
the vendor list.

btw do you know whether this 'virtual machine' flag is widely used
in virtualization environments? If yes, we probably should add check
on this flag even before checking DMI_SYS_VENDOR. It sounds more
general...

Thanks
Kevin