On Mon, Mar 02, 2015 at 06:05:43PM +0100, Igor Mammedov wrote: > On Sun, 1 Mar 2015 16:09:33 +0100 > "Michael S. Tsirkin" <[email protected]> wrote: > > > On Wed, Feb 25, 2015 at 05:08:52PM +0000, Igor Mammedov wrote: > > > Based on Microsoft's sepecifications (paper can be dowloaded from > > > http://go.microsoft.com/fwlink/?LinkId=260709), add a device > > > description to the SSDT ACPI table and its implementation. > > > > > > The GUID is set using "vmgenid.uuid" property. > > > > > > Example of using vmgenid device: > > > -device vmgenid,id=FOO,uuid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87" > > > > If you do this, doesn't windows then prompt for a driver? > it doesn't since PCI_CLASS_MEMORY_RAM is displayed as driver less > "PCI standard RAM Controller" binding in device manager. > > There was an issue with > virtio balloon device + pseries firmware + kernel bug > http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04704.html > but it shouldn't be an issue for x86 targets with which device is > supposed to be used. > CCing David and Laszlo in case UEFI might do some crazy stuff like > pseries firmware.
I have to say, if it's not RAM, using PCI_CLASS_MEMORY_RAM seems wrong. Can't we tag it in ACPI in some way? I guess I can somewhat buy 0580 "other memory controller". I think we also want some space for future expansion in this device. How about we reserve first 4K, and set bit 0 to mean "has uuid"? -- MST
