Hi Bjorn,
On 12/11/20 2:57 AM, Bjorn Helgaas wrote:
On Thu, Dec 10, 2020 at 08:46:24AM +0800, Lu Baolu wrote:
The pci_subdevice_msi_create_irq_domain() should fail if the underlying
platform is not able to support IMS (Interrupt Message Storage). Otherwise,
the isolation of interrupt is not guaranteed.
For x86, IMS is only supported on bare metal for now. We could enable it
in the virtualization environments in the future if interrupt HYPERCALL
domain is supported or the hardware has the capability of interrupt
isolation for subdevices.
+ * 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"
+};
+
+static bool probably_on_bare_metal(void)
What is the point of a function called probably_on_bare_metal()?
*Probably*? The caller can't really do anything with the fact that
we're not 100% sure this gives the correct answer. Just call it
"on_bare_metal()" or something and accept the fact that it might be
wrong sometimes.
Agreed. we can use on_bare_metal() and add comments and kernel messages
to let users and developers know that we're not 100% sure. People should
help to make it more accurate by reporting exceptions.
This patch goes with IMS support, which somebody else is handling, so
I assume you don't need anything from the PCI side.
Yes. This is a followup of previous discussion.
Best regards,
baolu
