Problem with auto-detecting a HV environment from within Linux
in [Kernel]
|
Prev: readahead: thrashing safe context readahead
Next: [tip:x86/mrst] x86, numaq: Make CONFIG_X86_NUMAQ depend on CONFIG_PCI
From: Greg KH on 25 Feb 2010 11:50 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 25 Feb 2010 12:40 On Thu, Feb 25, 2010 at 05:30:29PM +0000, Haiyang Zhang wrote: > > From: Greg KH [mailto:greg(a)kroah.com] > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Haiyang Zhang on 25 Feb 2010 12:40 > From: Greg KH [mailto:greg(a)kroah.com] > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Haiyang Zhang on 25 Feb 2010 13:40 > From: Greg KH [mailto:greg(a)kroah.com] > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 25 Feb 2010 18:10
On Thu, Feb 25, 2010 at 06:37:05PM +0000, Haiyang Zhang wrote: > > From: Greg KH [mailto:greg(a)kroah.com] > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |