Hi guys,
In looking at the HV code, there doesn't seem to be a way to
automatically detect if we are running in a HV environment in order to
know to load the drivers in the first place.
Normally, we trigger off of things like PCI ids, or some other
externally visible id to know if we can properly load the drivers.
This also is a problem for distros, as they need to know to include the
drivers or not, through their device update processes (i.e. rpm and
install tools can detect pci dependancies of a machine to know to set
things properly.)
So, is there a way to "know" ahead of time if we are in a HV guest
environment? I was told that there is a Microsoft VGA adapter that is
exposed to the guest, could we trigger off of this device? Or is there
some other unique PCI id that we could use?
thanks,
greg k-h
> From: Greg KH [mailto:[email protected]]
> So, is there a way to "know" ahead of time if we are in a HV guest
> environment?
Here is some info from dmesg, which shows "VRTUAL MICROSFT".
ACPI: RSDT (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0000
ACPI: FADT (v002 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0200
ACPI: WAET (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0b00
ACPI: SLIC (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0b40
ACPI: OEM0 (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0d40
ACPI: SRAT (v002 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0600
ACPI: MADT (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0300
ACPI: OEMB (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001ffff240
ACPI: DSDT (v001 MSFTVM MSFTVM02 0x00000002 INTL 0x02002026) @ 0x0000000000000000
Thanks,
- Haiyang
On Thu, Feb 25, 2010 at 05:30:29PM +0000, Haiyang Zhang wrote:
> > From: Greg KH [mailto:[email protected]]
> > So, is there a way to "know" ahead of time if we are in a HV guest
> > environment?
>
> Here is some info from dmesg, which shows "VRTUAL MICROSFT".
> ACPI: RSDT (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0000
> ACPI: FADT (v002 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0200
> ACPI: WAET (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0b00
> ACPI: SLIC (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0b40
> ACPI: OEM0 (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0d40
> ACPI: SRAT (v002 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0600
> ACPI: MADT (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001fff0300
> ACPI: OEMB (v001 VRTUAL MICROSFT 0x03000919 MSFT 0x00000097) @ 0x000000001ffff240
> ACPI: DSDT (v001 MSFTVM MSFTVM02 0x00000002 INTL 0x02002026) @ 0x0000000000000000
That's a good start, so which device can we key off of here?
What does the following command output in a HV virtual system:
grep . /sys/bus/acpi/devices/*/modalias
That might give us something that we can use.
How about DMI data? Does the Host export any info there? Is there
anything in the /sys/class/dmi/id/ directory? If so, can you send the
output of:
cat /sys/class/dmi/id/modalias
And you are sure no PCI devices are present to key off of that are never
going to show up in a "physical" machine?
What do you recommend doing here?
thanks,
greg k-h
> From: Greg KH [mailto:[email protected]]
> Sent: Thursday, February 25, 2010 12:36 PM
> What does the following command output in a HV virtual system:
> grep . /sys/bus/acpi/devices/*/modalias
/sys/bus/acpi/devices/VMBus:00/modalias:acpi:VMBus:
> How about DMI data? Does the Host export any info there? Is there
> anything in the /sys/class/dmi/id/ directory? If so, can you send the
> output of:
> cat /sys/class/dmi/id/modalias
dmi:bvnAmericanMegatrendsInc.:bvr090004:bd03/19/2009:svnMicrosoftCorporation:pnVirtualMachine:pvr7.0:rvnMicrosoftCorporation:rnVirtualMachine:rvr7.0:cvnMicrosoftCorporation:ct3:cvr7.0:
> And you are sure no PCI devices are present to key off of that are
> never going to show up in a "physical" machine?
There is also a pci device as you said:
00:08.0 VGA compatible controller: Microsoft Corporation Device 5353 (prog-if 00 [VGA controller])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f8000000 (32-bit, non-prefetchable) [size=64M]
>
> What do you recommend doing here?
I think any of the above can be used.
Thanks,
- Haiyang
On Thu, Feb 25, 2010 at 06:37:05PM +0000, Haiyang Zhang wrote:
> > From: Greg KH [mailto:[email protected]]
> > Sent: Thursday, February 25, 2010 12:36 PM
> > What does the following command output in a HV virtual system:
> > grep . /sys/bus/acpi/devices/*/modalias
>
> /sys/bus/acpi/devices/VMBus:00/modalias:acpi:VMBus:
>
> > How about DMI data? Does the Host export any info there? Is there
> > anything in the /sys/class/dmi/id/ directory? If so, can you send the
> > output of:
> > cat /sys/class/dmi/id/modalias
>
> dmi:bvnAmericanMegatrendsInc.:bvr090004:bd03/19/2009:svnMicrosoftCorporation:pnVirtualMachine:pvr7.0:rvnMicrosoftCorporation:rnVirtualMachine:rvr7.0:cvnMicrosoftCorporation:ct3:cvr7.0:
Nice, can we rely on this to be static? Will the following structure always
match properly?
static struct dmi_system_id __initdata microsoft_hyperv_table[] = {
{
.ident = "hyperv",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "MicrosoftCorporation"),
DMI_MATCH(DMI_PRODUCT_NAME, "VirtualMachine"),
DMI_MATCH(DMI_BOARD_NAME, "VirtualMachine"),
},
},
};
That would be good to match with, but I don't know if all distro tools
can properly handle DMI module stuff just yet.
> > And you are sure no PCI devices are present to key off of that are
> > never going to show up in a "physical" machine?
>
> There is also a pci device as you said:
> 00:08.0 VGA compatible controller: Microsoft Corporation Device 5353 (prog-if 00 [VGA controller])
> Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at f8000000 (32-bit, non-prefetchable) [size=64M]
Ah, nice. Can we rely on this always being present?
If so, what is the vendor and product id of this device?
Is it:
Vendor id 0x1414
or:
Vendor id 0x045e
Microsoft has both assigned to them, and probably others.
Is the device id 0x5353?
You can see this by doing the following:
lspci -n | grep 08\\.0
what is the output of that?
thanks,
greg k-h
> -----Original Message-----
> From: Greg KH [mailto:[email protected]]
> Sent: Thursday, February 25, 2010 6:07 PM
> If so, what is the vendor and product id of this device?
The Vendor:Device Id is: 1414:5353
00:08.0 VGA compatible controller [0300]: Microsoft Corporation Device [1414:5353]
This hasn't been changed since the first release of HyperV. I will ask around about the future stability of the VGA card (and the DMI).
Thanks,
- Haiyang
On Thu, Feb 25, 2010 at 11:40:52PM +0000, Haiyang Zhang wrote:
> > -----Original Message-----
> > From: Greg KH [mailto:[email protected]]
> > Sent: Thursday, February 25, 2010 6:07 PM
> > If so, what is the vendor and product id of this device?
>
> The Vendor:Device Id is: 1414:5353
> 00:08.0 VGA compatible controller [0300]: Microsoft Corporation Device [1414:5353]
>
> This hasn't been changed since the first release of HyperV. I will ask
> around about the future stability of the VGA card (and the DMI).
Thanks for the device id.
I'll make up a patch for testing now, as we should be able to just
trigger on this pci device id, and do the dmi test to be "safe" as well.
Any future changes can easily be added to the tables.
thanks,
greg k-h
On Thu, Feb 25, 2010 at 11:40:52PM +0000, Haiyang Zhang wrote:
> > -----Original Message-----
> > From: Greg KH [mailto:[email protected]]
> > Sent: Thursday, February 25, 2010 6:07 PM
> > If so, what is the vendor and product id of this device?
>
> The Vendor:Device Id is: 1414:5353
> 00:08.0 VGA compatible controller [0300]: Microsoft Corporation Device [1414:5353]
>
> This hasn't been changed since the first release of HyperV. I will ask
> around about the future stability of the VGA card (and the DMI).
Ok, below are 2 patches that I will queue up in my tree.
Can you test them to verify that they work properly?
thanks,
greg k-h
From: Greg Kroah-Hartman <[email protected]>
Subject: Staging: hv: add a pci device table
This allows the HV core to be properly found and autoloaded
by the system tools.
It uses the Microsoft virtual VGA device to trigger this.
Cc: Haiyang Zhang <[email protected]>
Cc: Hank Janssen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/hv/vmbus_drv.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -24,6 +24,7 @@
#include <linux/irq.h>
#include <linux/interrupt.h>
#include <linux/sysctl.h>
+#include <linux/pci.h>
#include "VersionInfo.h"
#include "osd.h"
#include "logging.h"
@@ -974,6 +975,22 @@ static void __exit vmbus_exit(void)
return;
}
+/*
+ * We use a PCI table to determine if we should autoload this driver This is
+ * needed by distro tools to determine if the hyperv drivers should be
+ * installed and/or configured. We don't do anything else with the table, but
+ * it needs to be present.
+ *
+ * We might consider triggering off of DMI table info as well, as that does
+ * decribe the virtual machine being run on, but not all configuration tools
+ * seem to be able to handle DMI device ids properly.
+ */
+const static struct pci_device_id microsoft_hv_pci_table[] = {
+ { PCI_DEVICE(0x1414, 0x5353) }, /* VGA compatible controller */
+ { 0 }
+};
+MODULE_DEVICE_TABLE(pci, microsoft_hv_pci_table);
+
MODULE_LICENSE("GPL");
MODULE_VERSION(HV_DRV_VERSION);
module_param(vmbus_irq, int, S_IRUGO);
From: Greg Kroah-Hartman <[email protected]>
Subject: Staging: hv: match on DMI values to know if we should run.
The HV core mucks around with specific irqs and other low-level stuff
and takes forever to determine that it really shouldn't be running on a
machine. So instead, trigger off of the DMI system information and
error out much sooner. This also allows the module loading tools to
recognize that this code should be loaded on this type of system.
Cc: Haiyang Zhang <[email protected]>
Cc: Hank Janssen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/hv/vmbus_drv.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -25,6 +25,7 @@
#include <linux/interrupt.h>
#include <linux/sysctl.h>
#include <linux/pci.h>
+#include <linux/dmi.h>
#include "VersionInfo.h"
#include "osd.h"
#include "logging.h"
@@ -948,6 +949,19 @@ static irqreturn_t vmbus_isr(int irq, vo
}
}
+static struct dmi_system_id __initdata microsoft_hv_dmi_table[] = {
+ {
+ .ident = "Hyper-V",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "MicrosoftCorporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VirtualMachine"),
+ DMI_MATCH(DMI_BOARD_NAME, "VirtualMachine"),
+ },
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(dmi, microsoft_hv_dmi_table);
+
static int __init vmbus_init(void)
{
int ret = 0;
@@ -959,6 +973,9 @@ static int __init vmbus_init(void)
vmbus_loglevel, HIWORD(vmbus_loglevel), LOWORD(vmbus_loglevel));
/* Todo: it is used for loglevel, to be ported to new kernel. */
+ if (!dmi_check_system(microsoft_hv_dmi_table))
+ return -ENODEV;
+
ret = vmbus_bus_init(VmbusInitialize);
DPRINT_EXIT(VMBUS_DRV);
@@ -980,10 +997,6 @@ static void __exit vmbus_exit(void)
* needed by distro tools to determine if the hyperv drivers should be
* installed and/or configured. We don't do anything else with the table, but
* it needs to be present.
- *
- * We might consider triggering off of DMI table info as well, as that does
- * decribe the virtual machine being run on, but not all configuration tools
- * seem to be able to handle DMI device ids properly.
*/
const static struct pci_device_id microsoft_hv_pci_table[] = {
{ PCI_DEVICE(0x1414, 0x5353) }, /* VGA compatible controller */
>Ok, below are 2 patches that I will queue up in my tree.
>
>Can you test them to verify that they work properly?
Will do. We will let you know as soon as we test it.
Thanks!
Hank.
On Fri, Feb 26, 2010 at 02:14:55AM +0000, Hank Janssen wrote:
>
>
> >Ok, below are 2 patches that I will queue up in my tree.
> >
> >Can you test them to verify that they work properly?
>
> Will do. We will let you know as soon as we test it.
In looking at the second patch again, I think you will need to put some
spaces in the DMI strings to get it to match up properly. Look at what
the files in:
/sys/class/dmi/id/
look like exactly to get it to line up. The module id stuff strips
spaces out, so I can't get the real value there.
thanks,
greg k-h
Hi Greg,
On Fri, Feb 26, 2010 at 2:46 AM, Greg KH <[email protected]> wrote:
>
> On Thu, Feb 25, 2010 at 11:40:52PM +0000, Haiyang Zhang wrote:
> > > -----Original Message-----
> > > From: Greg KH [mailto:[email protected]]
> > > Sent: Thursday, February 25, 2010 6:07 PM
> > > If so, what is the vendor and product id of this device?
> >
> > The Vendor:Device Id is: 1414:5353
> > 00:08.0 VGA compatible controller [0300]: Microsoft Corporation Device [1414:5353]
> >
> > This hasn't been changed since the first release of HyperV. I will ask
> > around about the future stability of the VGA card (and the DMI).
>
> Ok, below are 2 patches that I will queue up in my tree.
>
> Can you test them to verify that they work properly?
>
> thanks,
>
> greg k-h
>
> From: Greg Kroah-Hartman <[email protected]>
> Subject: Staging: hv: add a pci device table
>
> This allows the HV core to be properly found and autoloaded
> by the system tools.
>
> It uses the Microsoft virtual VGA device to trigger this.
>
> Cc: Haiyang Zhang <[email protected]>
> Cc: Hank Janssen <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/staging/hv/vmbus_drv.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> --- a/drivers/staging/hv/vmbus_drv.c
> +++ b/drivers/staging/hv/vmbus_drv.c
> @@ -24,6 +24,7 @@
> #include <linux/irq.h>
> #include <linux/interrupt.h>
> #include <linux/sysctl.h>
> +#include <linux/pci.h>
> #include "VersionInfo.h"
> #include "osd.h"
> #include "logging.h"
> @@ -974,6 +975,22 @@ static void __exit vmbus_exit(void)
> return;
> }
>
> +/*
> + * We use a PCI table to determine if we should autoload this driver This is
> + * needed by distro tools to determine if the hyperv drivers should be
> + * installed and/or configured. We don't do anything else with the table, but
> + * it needs to be present.
> + *
> + * We might consider triggering off of DMI table info as well, as that does
> + * decribe the virtual machine being run on, but not all configuration tools
> + * seem to be able to handle DMI device ids properly.
> + */
> +const static struct pci_device_id microsoft_hv_pci_table[] = {
You can have:
const static DEFINE_PCI_DEVICE_TABLE(microsoft_hv_pci_table) = {
> + { PCI_DEVICE(0x1414, 0x5353) }, /* VGA compatible controller */
> + { 0 }
> +};
> +MODULE_DEVICE_TABLE(pci, microsoft_hv_pci_table);
> +
Cheers,
Ameya.
On Fri, Feb 26, 2010 at 11:47:58AM +0200, Ameya Palande wrote:
> > +const static struct pci_device_id microsoft_hv_pci_table[] = {
>
> You can have:
> const static DEFINE_PCI_DEVICE_TABLE(microsoft_hv_pci_table) = {
Yeah, you could, if you liked that macro, which I certainly do not.
thanks,
greg k-h
> From: Greg KH [mailto:[email protected]]
> Sent: Thursday, February 25, 2010 9:57 PM
> In looking at the second patch again, I think you will need to put some
> spaces in the DMI strings to get it to match up properly. Look at what
> the files in:
> /sys/class/dmi/id/
> look like exactly to get it to line up. The module id stuff strips
> spaces out, so I can't get the real value there.
Thanks for your help! I have applied the two patches -- auto loading of hv_vmbus works fine after a space was inserted into the DMI strings ("Microsoft Corporation", "Virtual Machine").
Also, according to our Hyper-V team, we have no plan to change the virtual VGA card id and DMI info.
Thanks,
- Haiyang
On Fri, Feb 26, 2010 at 07:07:14PM +0000, Haiyang Zhang wrote:
> > From: Greg KH [mailto:[email protected]]
> > Sent: Thursday, February 25, 2010 9:57 PM
> > In looking at the second patch again, I think you will need to put some
> > spaces in the DMI strings to get it to match up properly. Look at what
> > the files in:
> > /sys/class/dmi/id/
> > look like exactly to get it to line up. The module id stuff strips
> > spaces out, so I can't get the real value there.
>
> Thanks for your help! I have applied the two patches -- auto loading
> of hv_vmbus works fine after a space was inserted into the DMI strings
> ("Microsoft Corporation", "Virtual Machine").
Great, I'll add a space and then queue them up for the merge window.
> Also, according to our Hyper-V team, we have no plan to change the
> virtual VGA card id and DMI info.
That's good to know, but if it changes in the future, we can trivially
add new device ids.
thanks,
greg k-h