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

[Blue Swirl]

On 7/29/08, Gleb Natapov <address@hidden> wrote:
> On Tue, Jul 29, 2008 at 02:22:54PM -0500, Anthony Liguori wrote:
>  > Gleb Natapov wrote:
>  >> On Mon, Jul 28, 2008 at 09:37:01AM -0500, Anthony Liguori wrote:
>  >>
>  >>> The backdoor interface is deprecated (from a VMware perspective) and
>  >>> is  pretty terrible.  I'll go through and do a more thorough review
>  >>> of the  patches Chris posted but one thing I already know I'd like to
>  >>> see the
>  >> Review my last submission I linked above then too.
>  >>
>  >
>  > Applying the -uuid support without making use of that uuid anywhere
>  > isn't very useful.
>  >
>
> You can read it from monitor, so management software can benefit from
>  it. And this will reduce my patch backlog :)
>
>
>  >>> UUID plumbed through the SMBIOS tables for x86.  That's a requirement
>  >>> in  my mind for adding a -uuid option.  I see no harm in also
>  >>> supporting the  backdoor interface but the primary way to expose a
>  >>> UUID should be SMBIOS.
>  >>>
>  >> I am not sure I understand what you mean. Currently SMBIOS tables are
>  >> built by bochs bios and UUID backdoor is needed to fill in missing info.
>  >>
>  >
>  > But that patch that got pushed into the Bochs BIOS was wrong.
>  >
>  > So here's what I'd like to see in order to apply these patches:
>  >
>  > 1) A new patch to the Bochs BIOS that used CMOS to pass a UUID (or
>  > possibly an OF data structure as Blue Swirl suggested--although CMOS is
>  > safer).
>
> We will run out of space in CMOS quickly if we will use it as qemu->bios
>  communication channel. Is passing pointer to memory location (Blue Swirl
>  suggestion) acceptable solution by everyone?

Here's a patch implementing a configuration ROM (probably in a bad
address) including a fake UUID. I skipped the more difficult parts
like kernel address etc.

pc_use_firmware_abi.diff
Description: plain/text