Xen project Mailing List

Sample code would be great if it can be forwarded to the list.

Thanks
Art

From: Ross Philipson <Ross.Philipson@xxxxxxxxxx>
To: Art Napor <artnapor@xxxxxxxxx>; "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
Sent: Wednesday, October 10, 2012 11:00 AM
Subject: RE: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

It looks like this thread fell off the xen-devel list â putting it back. I am not sure what you mean by hard-coded. Newer kernels expose the DMI/SMBIOS information in sysfs. I could send out some sample code that does this.

General question for xen-devel: Is it ok to forward sample code to the list? I am not sure what the rules of engagement are concerning that.

Thanks

Ross

From: Art Napor [mailto:artnapor@xxxxxxxxx]
Sent: Tuesday, October 09, 2012 3:58 PM
To: Ross Philipson
Subject: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

Ross,

I wish I could say yes. I think I see where these are intended to be loaded in from the fourth patch in the v3 series. I guess I'm not clear on how the tool stack would read these in. Would these values be hard coded in from /sysfs or could these be configured in xen.cfg or other arguments passed in?

+#define HVM_XS_HVMLOADER               "hvmloader"
+#define HVM_XS_BIOS                    "hvmloader/bios"
+#define HVM_XS_GENERATION_ID_ADDRESS   "hvmloader/generation-id-address"
+
+/* The following values allow additional ACPI tables to be added to the
+ * virtual ACPI BIOS that hvmloader constructs. The values specify the guest
+ * physical address and length of a block of ACPI tables to add. The format of
+ * the block is simply concatenated raw tables (which specify their own length
+ * in the ACPI header).
+ */
+#define HVM_XS_ACPI_PT_ADDRESS         "hvmloader/acpi/address"
+#define HVM_XS_ACPI_PT_LENGTH          "hvmloader/acpi/length"
+
+/* Any number of SMBIOS types can be passed through to an HVM guest using
+ * the following xenstore values. The values specify the guest physical
+ * address and length of a block of SMBIOS structures for hvmloader to use.
+ * The block is formatted in the following way:
+ *
+ * <length><struct><length><struct>...
+ *
+ * Each length separator is a 32b integer indicating the length of the next
+ * SMBIOS structure. For DMTF defined types (0 - 121), the passed in struct
+ * will replace the default structure in hvmloader. In addition, any
+ * OEM/vendortypes (128 - 255) will all be added.
+ */
+#define HVM_XS_SMBIOS_PT_ADDRESS       "hvmloader/smbios/address"
+#define HVM_XS_SMBIOS_PT_LENGTH        "hvmloader/smbios/length"
+
+/* Set to 1 to enable SMBIOS default portable battery (type 22) values. */
+#define HVM_XS_SMBIOS_DEFAULT_BATTERY "hvmloader/smbios/default_battery"
+
+/* The following xenstore values are used to override some of the default
+ * string values in the SMBIOS table constructed in hvmloader.
+ */
+#define HVM_XS_BIOS_STRINGS            "bios-strings"
+#define HVM_XS_BIOS_VENDOR             "bios-strings/bios-vendor"
+#define HVM_XS_BIOS_VERSION            "bios-strings/bios-version"
+#define HVM_XS_SYSTEM_MANUFACTURER     "bios-strings/system-manufacturer"
+#define HVM_XS_SYSTEM_PRODUCT_NAME     "bios-strings/system-product-name"
+#define HVM_XS_SYSTEM_VERSION          "bios-strings/system-version"
+#define HVM_XS_SYSTEM_SERIAL_NUMBER    "bios-strings/system-serial-number"
+#define HVM_XS_ENCLOSURE_MANUFACTURER "bios-strings/enclosure-manufacturer"
+#define HVM_XS_ENCLOSURE_SERIAL_NUMBER "bios-strings/enclosure-serial-number"
+#define HVM_XS_BATTERY_MANUFACTURER    "bios-strings/battery-manufacturer"
+#define HVM_XS_BATTERY_DEVICE_NAME     "bios-strings/battery-device-name"
+
+/* Up to 100 OEM strings can be set in xenstore using values of the form

From: Ross Philipson <Ross.Philipson@xxxxxxxxxx>
To: Art Napor <artnapor@xxxxxxxxx>
Sent: Tuesday, October 9, 2012 2:06 PM
Subject: RE: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

Hi,

So the patches to xen are only part of what you need to make it all work. Something in your toolstack needs to load the tables you want into the new guest. There was no really good place to do this in the xen tools so I did not push. I am guessing e.g. somewhere in you dom0 tools, you would call dmidecode or read the tables from sysfs, form the set of tables for the guest that you want and pass them in to the libxc domain creator function. Does that make sense?

Thanks

Ross

From: Art Napor [mailto:artnapor@xxxxxxxxx]
Sent: Tuesday, October 09, 2012 1:55 PM
To: Ross Philipson
Subject: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

Ross,

Thanks again for the information. I was able to apply the SMBIOS patch series cleanly to 4.1.2 and v3 of your later patch series to 4.2 and 4.3 testing. Is there an option or flag that needs to be set to enable the HVM passthrough? I believe the patches applied cleanly - I didn't notice any rejects. I have smbios loaded in the Dom0 /sys/firmware/smbios and /sys/class/dmi/. A Centos 5 DomU with the patched Xen 4.2/4.3 appears to still report the standard Xen bios information via dmidecode.

From: Ross Philipson <Ross.Philipson@xxxxxxxxxx>
To: Art Napor <artnapor@xxxxxxxxx>; "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
Sent: Friday, August 31, 2012 4:36 PM
Subject: RE: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

> I also came across the earlier smbios passthrough patch series. I'm looking to be able to pass the DMI block from the Dom0 to the DomU when. Your earlier smbios patch series applied cleanly built against to 4.1.2, but the Dom0 smbios data didn't seem to make it into the HVM DomU.

> Are there any version or other changset limitations that would prevent the patches from being manually applied to 4.1?

> http://lists.xen.org/archives/html/xen-devel/2012-02/msg01754.html

Well there were some tool stack changes (in libxl) that happened right around the time I was making the patches so I had to change things to match that. So in an older branch you might have to change the way the BIOS blobs get sent in to the domain building code.

The rest of the code to load the BIOS bits into the new guests memory and the changes to hvmloader to process them should apply cleanly I think.

Note that the last patch set for this (v3) does support passing in both SMBIOS structures and ACPI tables so you can use that patch set.

Thanks
Ross