Alex Williamson wrote:
SMBIOS entries can be read from the VM using the same mechanism as additional ACPI tables. External entries will supercede generated entries.Signed-off-by: Alex Williamson <alex.william...@hp.com> + + /* A type 1 entry provides a UUID, but so does the QEMU_CFG_UUID + * port. If the QEMU_CFG_UUID value is not zero, use it, otherwise + * use whatever was in the provided table. */ + if (type == 1) { + const static uint8_t null_uuid[16] = { 0 }; + if (memcmp(bios_uuid, null_uuid, 16)) { + struct smbios_type_1 *t = (struct smbios_type_1 *)*q; + memcpy(t->uuid, bios_uuid, 16); + } + }
This is what I was getting at in my other post. I'd sort of rather that a certain set of SMBIOS tables be specified at a higher level (like uuid, manufacture, vendor, etc.) and the blobs just be the OEM tables. I think that matches the work going on with the device configuration files more appropriately.
Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
