Re: [Qemu-devel] Re: [PATCH 0/3]: Add UUID command-line option

[Blue Swirl]

On 7/28/08, Gleb Natapov <address@hidden> wrote:
> On Mon, Jul 28, 2008 at 11:17:33AM -0500, Anthony Liguori wrote:
>  > Gleb Natapov wrote:
>  >>
>  >> 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'm inclined to think that on a real machine, the UUID is stored in the
>  > CMOS.
>  >
>
> Should be easy to check.
>
>
>  >> For example we have a requirement to pass additional ACPI tables that
>  >> user may specify on command line.
>  >
>  > What's the use-case?  I don't think this is a very good idea.
>  >
>
> AFAIK some OEM version of windows needs special ACPI table for
>  activation.
>
>
>  >>  There is no enough space to put those
>  >> tables into CMOS. What I did is that: BIOS passes to qemu address where to
>  >> store additional tables (via backdoor) and qemu copies them there. To
>  >> this scheme to work there should be bidirectional channel between qemu
>  >> and BIOS. Other then that I am not particularly attached to vmware
>  >> backdoor :)
>  >>
>  >
>  > 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 am not disagreeing with you. Lets define another interface that is
>  acceptable by everyone here and I (or somebody else) will implement it.

I propose to extend hw/firmware_abi.h structure to cover x86 needs in
addition to Sparc32, Sparc64 and PPC. The structure could reside in a
ROM somewhere, pointer to it could be in CMOS.