|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [PATCH 0/3]: Add UUID command-line option |
Date: | Mon, 28 Jul 2008 14:02:56 -0500 |
User-agent: | Thunderbird 2.0.0.14 (X11/20080501) |
Jamie Lokier wrote:
Anthony Liguori wrote:I'm inclined to think that on a real machine, the UUID is stored in the CMOS.CMOS has enough memory for UUID, but UUID is not the only thing that needs to be passed to BIOS, so eventually we can run out of space there.I'd imagine on a real machine the UUID cannot be changed, so it can't be stored in the CMOS. It's probably in the BIOS somewhere.
It may be part of the ROM that gets written to CMOS when you "reset to factory defaults". I can think of a number of advantages to storing it in CMOS.
I quick Google suggests at least some systems store it in the SMBIOS information, which is part of the BIOS EEPROM.
Well it definitely is part of the SMBIOS tables. The question is whether those tables are dynamically generated. I'm pretty sure they are for certain BIOSes.
For testing guest ACPI implementations or changing their behaviour? :-)
Sounds like a fantastic way for a user to shoot themselves in the foot. If you care to do this sort of work, you can certainly recompile the BIOS. The source is there afterall.
Regards, Anthony Liguori
You can not arbitrarily extend the backdoor interface. It's an interface defined and controlled by VMware. If you extend it, you risk breaking other OSes that are assuming that interface has a different meaning.I agree, better to define a sensible interface if extensions are desired. Probably at least one other VM has defined such a thing, it would be good to copy if there is one and it's extensible. -- Jamie
[Prev in Thread] | Current Thread | [Next in Thread] |