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

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

[Chris Lalancette]

All,
     Attached is a three part patch series to implement a "-uuid" command-line
option to qemu.  The original work for this was all done by Gleb Natapov; since
there hadn't seemed to be any activity on this since June, I picked up his
patches and ran with them (original posting:
http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00167.html).  These
patches are basically the same as his, just cleaned up according to Anthony
Liguori's feedback.

Gleb: I'm willing to do the additional work to get these patches included in
Qemu proper; if you prefer to do it, that's fine too.  I don't care either way,
I would just like to see them go in.

Anthony: I've addressed all of your comments from the previous patch series
except for one.  I didn't remove most of the "#ifdef CONFIG_UUID" from the vl.c
file.  In the case where UUID is not compiled into qemu, I think it is much
preferable to noisily complain that we don't understand the -uuid command-line
option, rather than silently fail to set it.

Signed-off-by: Chris Lalancette <clalance@redhat.com>
Cc: Gleb Natapov <gleb@qumranet.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>

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

[Gleb Natapov]

Hi Chris,

On Mon, Jul 28, 2008 at 03:25:06PM +0200, Chris Lalancette wrote:
> All,
>      Attached is a three part patch series to implement a "-uuid" command-line
> option to qemu.  The original work for this was all done by Gleb Natapov; since
> there hadn't seemed to be any activity on this since June, I picked up his
> patches and ran with them (original posting:
> http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00167.html).  These
> patches are basically the same as his, just cleaned up according to Anthony
> Liguori's feedback.
Actually there was activity on this. I addressed Anthony's feedback and
reposted the patch series (I think even twice). Here is the last one:
http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00448.html
http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00442.html
http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00443.html
http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00444.html
http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00445.html
http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00446.html

Fabrice said that he doesn't like vmware backdoor interface though
(http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00487.html)
I asked what interface he wants to use for qemu/guest communication, but
he never replied to this :(

I also want to see those patches going in I don't care much who will
push them. I can resent last series one more time if it will help.

--
			Gleb.

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

[Anthony Liguori]

Gleb Natapov wrote:
> Hi Chris,
>
> On Mon, Jul 28, 2008 at 03:25:06PM +0200, Chris Lalancette wrote:
>   
>> All,
>>      Attached is a three part patch series to implement a "-uuid" command-line
>> option to qemu.  The original work for this was all done by Gleb Natapov; since
>> there hadn't seemed to be any activity on this since June, I picked up his
>> patches and ran with them (original posting:
>> http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00167.html).  These
>> patches are basically the same as his, just cleaned up according to Anthony
>> Liguori's feedback.
>>     
> Actually there was activity on this. I addressed Anthony's feedback and
> reposted the patch series (I think even twice). Here is the last one:
> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00448.html
> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00442.html
> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00443.html
> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00444.html
> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00445.html
> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00446.html
>
> Fabrice said that he doesn't like vmware backdoor interface though
> (http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00487.html)
> I asked what interface he wants to use for qemu/guest communication, but
> he never replied to this :(
>   

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 
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.

Regards,

Anthony Liguori

> I also want to see those patches going in I don't care much who will
> push them. I can resent last series one more time if it will help.
>
> --
> 			Gleb.
>   

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

[Chris Lalancette]

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 
> 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.

Hm, but that's basically what this does, in combination with the Bochs BIOS.
Once the Bochs BIOS reaches the rombios32 code, it makes the calls into the
device model VMware backdoor to get the UUID.  Assuming this all succeeds, the
Bochs BIOS then plumbs it into the SMBIOS tables.

Is that what you meant, or did you mean something else?  A quick grep for
"smbios" didn't turn up anything in the qemu source tree, so I'm not sure where
else we would implement this.

Thanks,
Chris Lalancette

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

[Anthony Liguori]

Chris Lalancette wrote:
> 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 
>> 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.
>>     
>
> Hm, but that's basically what this does, in combination with the Bochs BIOS.
> Once the Bochs BIOS reaches the rombios32 code, it makes the calls into the
> device model VMware backdoor to get the UUID.  Assuming this all succeeds, the
> Bochs BIOS then plumbs it into the SMBIOS tables.
>   

Are there patches for the Bochs BIOS to do this?  Why wouldn't it just 
use CMOS to get at the UUID?

Regards,

Anthony Liguori

> Is that what you meant, or did you mean something else?  A quick grep for
> "smbios" didn't turn up anything in the qemu source tree, so I'm not sure where
> else we would implement this.
>
> Thanks,
> Chris Lalancette
>   

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

[Chris Lalancette]

Anthony Liguori wrote:
>> Hm, but that's basically what this does, in combination with the Bochs BIOS.
>> Once the Bochs BIOS reaches the rombios32 code, it makes the calls into the
>> device model VMware backdoor to get the UUID.  Assuming this all succeeds, the
>> Bochs BIOS then plumbs it into the SMBIOS tables.
>>   
> 
> Are there patches for the Bochs BIOS to do this?  Why wouldn't it just 
> use CMOS to get at the UUID?

Yeah, there's a uuid_probe() function that's already been merged into the Bochs
BIOS, and subsequently to most of the downstream projects (including KVM).

void uuid_probe(void)
{
#ifdef BX_QEMU
    uint32_t eax, ebx, ecx, edx;

    // check if backdoor port exists
    asm volatile ("outl %%eax, %%dx"
        : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
        : "a" (0x564d5868), "c" (0xa), "d" (0x5658));
    if (ebx == 0x564d5868) {
        uint32_t *uuid_ptr = (uint32_t *)bios_uuid;
        // get uuid
        asm volatile ("outl %%eax, %%dx"
            : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
            : "a" (0x564d5868), "c" (0x13), "d" (0x5658));
        uuid_ptr[0] = eax;
        uuid_ptr[1] = ebx;
        uuid_ptr[2] = ecx;
        uuid_ptr[3] = edx;
    } else
#endif
    {
        // UUID not set
        memset(bios_uuid, 0, 16);
    }
}

Later on in the rombios32 code the bios_uuid[] is used to build up the SMBIOS
tables.

Chris Lalancette

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

[Anthony Liguori]

Chris Lalancette wrote:
> Anthony Liguori wrote:
>   
>>> Hm, but that's basically what this does, in combination with the Bochs BIOS.
>>> Once the Bochs BIOS reaches the rombios32 code, it makes the calls into the
>>> device model VMware backdoor to get the UUID.  Assuming this all succeeds, the
>>> Bochs BIOS then plumbs it into the SMBIOS tables.
>>>   
>>>       
>> Are there patches for the Bochs BIOS to do this?  Why wouldn't it just 
>> use CMOS to get at the UUID?
>>     
>
> Yeah, there's a uuid_probe() function that's already been merged into the Bochs
> BIOS, and subsequently to most of the downstream projects (including KVM).
>
> void uuid_probe(void)
> {
> #ifdef BX_QEMU
>     uint32_t eax, ebx, ecx, edx;
>
>     // check if backdoor port exists
>     asm volatile ("outl %%eax, %%dx"
>         : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
>         : "a" (0x564d5868), "c" (0xa), "d" (0x5658));
>     if (ebx == 0x564d5868) {
>         uint32_t *uuid_ptr = (uint32_t *)bios_uuid;
>         // get uuid
>         asm volatile ("outl %%eax, %%dx"
>             : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
>             : "a" (0x564d5868), "c" (0x13), "d" (0x5658));
>         uuid_ptr[0] = eax;
>         uuid_ptr[1] = ebx;
>         uuid_ptr[2] = ecx;
>         uuid_ptr[3] = edx;
>     } else
> #endif
>     {
>         // UUID not set
>         memset(bios_uuid, 0, 16);
>     }
> }
>   

That makes me sad that they merged that.  What a terribly complicated 
way to do something that's relatively simple.

Regards,

Anthony Liguori

> Later on in the rombios32 code the bios_uuid[] is used to build up the SMBIOS
> tables.
>
> Chris Lalancette
>   

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

[Chris Lalancette]

Anthony Liguori wrote:
> 
> That makes me sad that they merged that.  What a terribly complicated 
> way to do something that's relatively simple.

Heh.  OK.  Well, that's where we are today, which may not be the best place, but
it's where both Gleb and I based the work off of.

I'll ask a naive question about CMOS; is there room in a standard CMOS to store
a UUID?  From my limited knowledge about it, I thought the CMOS was a quite
small region of ROM, and so there wouldn't really be room for something like a
128-byte UUID.  I could be totally wrong about that, though.

Chris Lalancette

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

[Gleb Natapov]

On Mon, Jul 28, 2008 at 05:42:12PM +0200, Chris Lalancette wrote:
> Anthony Liguori wrote:
> > 
> > That makes me sad that they merged that.  What a terribly complicated 
> > way to do something that's relatively simple.
> 
> Heh.  OK.  Well, that's where we are today, which may not be the best place, but
> it's where both Gleb and I based the work off of.
> 
> I'll ask a naive question about CMOS; is there room in a standard CMOS to store
> a UUID?  From my limited knowledge about it, I thought the CMOS was a quite
> small region of ROM, and so there wouldn't really be room for something like a
> 128-byte UUID.  I could be totally wrong about that, though.
> 
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.
For example we have a requirement to pass additional ACPI tables that
user may specify on command line. 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 :)

--
			Gleb.

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

[Anthony Liguori]

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.

> 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.

>  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.

Regards,

Anthony Liguori
> --
> 			Gleb.
>   

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

[Gleb Natapov]

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. 

--
			Gleb.

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

[Blue Swirl]

On 7/28/08, Gleb Natapov <gleb@qumranet.com> 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.

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

[Jamie Lokier]

Anthony Liguori 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.

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.

I quick Google suggests at least some systems store it in the SMBIOS
information, which is part of the BIOS EEPROM.  It also suggested that
some Dell laptops store it in the keyboard controller!

The logical equivalent would be to directly write the UUID (and other)
information into the Bochs BIOS when loading it into the emulator.

> >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.

For testing guest ACPI implementations or changing their behaviour? :-)

> 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

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

[Anthony Liguori]

Jamie Lokier wrote:
> Anthony Liguori 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.
>>     
>
> 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
>
>
>   

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

[Jamie Lokier]

Anthony Liguori 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.
> >>    
> >
> >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 thought the point of UUID is you're not supposed to be able to
change it on real hardware.  If it's in CMOS, and OSes/BIOS read it
from CMOS, then it's easy to change.

> >For testing guest ACPI implementations or changing their behaviour? :-)
> 
> Sounds like a fantastic way for a user to shoot themselves in the foot.

As if the other QEMU options are not like that :-)

> If you care to do this sort of work, you can certainly recompile the 
> BIOS.  The source is there afterall.

Indeed, same goes for all the other QEMU options.  The question is
whether it's useful enough to have an option, or obscure enough not to.

I'm inclined to think modifying ACPI tables is obscure, except
perhaps for specific tweaks that some versions of Windows or Linux
might need to run correctly, or to prevent them from using some
hardware feature or other.

-- Jamie

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

[Anthony Liguori]

Jamie Lokier wrote:
>> If you care to do this sort of work, you can certainly recompile the 
>> BIOS.  The source is there afterall.
>>     
>
> Indeed, same goes for all the other QEMU options.  The question is
> whether it's useful enough to have an option, or obscure enough not to.
>
> I'm inclined to think modifying ACPI tables is obscure, except
> perhaps for specific tweaks that some versions of Windows or Linux
> might need to run correctly, or to prevent them from using some
> hardware feature or other.
>   

In the future, it may be interesting to allow a precompiled ACPI table 
to be loaded and specified as part of a machine configuration file.  I 
think it makes a lot more sense if you can actually change the machine 
layout without recompiling.

Regards,

Anthony Liguori

> -- Jamie
>
>
>   

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

[Paul Brook]

On Monday 28 July 2008, Anthony Liguori wrote:
> Jamie Lokier wrote:
> >> If you care to do this sort of work, you can certainly recompile the
> >> BIOS.  The source is there afterall.
> >
> > Indeed, same goes for all the other QEMU options.  The question is
> > whether it's useful enough to have an option, or obscure enough not to.
> >
> > I'm inclined to think modifying ACPI tables is obscure, except
> > perhaps for specific tweaks that some versions of Windows or Linux
> > might need to run correctly, or to prevent them from using some
> > hardware feature or other.
>
> In the future, it may be interesting to allow a precompiled ACPI table
> to be loaded and specified as part of a machine configuration file.  I
> think it makes a lot more sense if you can actually change the machine
> layout without recompiling.

Why would changing machine layout need to be able to override the ACPI table? 
If the ACPI table doesn't match the emulated hardware that's a bug, and IMHO 
having users supply their own tables is not a good way to fix that bug.

Paul

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

[Anthony Liguori]

Paul Brook wrote:
> On Monday 28 July 2008, Anthony Liguori wrote:
>   
> Why would changing machine layout need to be able to override the ACPI table? 
> If the ACPI table doesn't match the emulated hardware that's a bug, and IMHO 
> having users supply their own tables is not a good way to fix that bug.
>   

Not everything in ACPI maps directly to emulated hardware.  The SMBIOS 
tables are a good example of this.

If I understand correctly, it's not uncommon for hardware manufactures 
to have a mostly static table, with sub-tables that are dynamically 
generated.  So we may create a mostly "static" table based on the chosen 
emulated hardware and then allow a user to fill in the sub tables.

Regards,

Anthony Liguori

> Paul
>   

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

[Gleb Natapov]

On Mon, Jul 28, 2008 at 03:25:39PM -0500, Anthony Liguori wrote:
> Jamie Lokier wrote:
>>> If you care to do this sort of work, you can certainly recompile the  
>>> BIOS.  The source is there afterall.
>>>     
>>
>> Indeed, same goes for all the other QEMU options.  The question is
>> whether it's useful enough to have an option, or obscure enough not to.
>>
>> I'm inclined to think modifying ACPI tables is obscure, except
>> perhaps for specific tweaks that some versions of Windows or Linux
>> might need to run correctly, or to prevent them from using some
>> hardware feature or other.
>>   
>
> In the future, it may be interesting to allow a precompiled ACPI table  
> to be loaded and specified as part of a machine configuration file.  I  
> think it makes a lot more sense if you can actually change the machine  
> layout without recompiling.
>
We don't need to change existing ACPI tables (well except of
OEMID/OEMTableID). We need to have a way to provide additional ACPI
tables. This is to support Windows Vista OEM activation, so blame
Microsoft for that :). Actually the need to provide additional ACPI
tables to BIOS exists on real HW too. See following link for a tutorial
how to do it for Award BIOS:
http://www.mydigitallife.info/2007/02/18/improved-way-to-add-slic-slp-20-table-into-bios-acpi-to-activate-windows-vista-oem/

--
			Gleb.

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

[Jamie Lokier]

Anthony Liguori wrote:
> >void uuid_probe(void)
> >{
> >#ifdef BX_QEMU
> >    uint32_t eax, ebx, ecx, edx;
> >
> >    // check if backdoor port exists
> >    asm volatile ("outl %%eax, %%dx"
> >        : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
> >        : "a" (0x564d5868), "c" (0xa), "d" (0x5658));
> >    if (ebx == 0x564d5868) {

Has a bug.

EBX is not initialised prior to the ASM, and could contain the same
value as EAX.

If the I/O doesn't do anything (like on a real PC), it could match the
condition which says its a backdoor.

The ASM should initialise EBX to something else:

   asm volatile ("outl %%eax, %%dx"
       : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
       : "a" (0x564d5868), "b" (0), "c" (0xa), "d" (0x5658));

-- Jamie

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

[Sebastian Herbszt]

Jamie Lokier wrote:
>> >void uuid_probe(void)
>> >{
>> >#ifdef BX_QEMU
>> >    uint32_t eax, ebx, ecx, edx;
>> >
>> >    // check if backdoor port exists
>> >    asm volatile ("outl %%eax, %%dx"
>> >        : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
>> >        : "a" (0x564d5868), "c" (0xa), "d" (0x5658));
>> >    if (ebx == 0x564d5868) {
> 
> Has a bug.
> 
> EBX is not initialised prior to the ASM, and could contain the same
> value as EAX.
> 
> If the I/O doesn't do anything (like on a real PC), it could match the
> condition which says its a backdoor.
> 
> The ASM should initialise EBX to something else:
> 
>   asm volatile ("outl %%eax, %%dx"
>       : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
>       : "a" (0x564d5868), "b" (0), "c" (0xa), "d" (0x5658));

Fixed in cvs (rombios32.c r1.29) now. Thanks for spotting it.

- Sebastian

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

[Jamie Lokier]

Anthony Liguori wrote:
> That makes me sad that they merged that.  What a terribly complicated 
> way to do something that's relatively simple.

I guess it's for backwards compatibility with ancient versions of
VMware, but it does seem out of place now.

-- Jamie

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

[Anthony Liguori]

Jamie Lokier wrote:
> Anthony Liguori wrote:
>   
>> That makes me sad that they merged that.  What a terribly complicated 
>> way to do something that's relatively simple.
>>     
>
> I guess it's for backwards compatibility with ancient versions of
> VMware, but it does seem out of place now.
>   

The Bochs BIOS doesn't run under VMware.  Plus it's under a BX_QEMU 
define in the Bochs BIOS.  It looks like it was merged into Bochs with 
them thinking that it was an interface we were supporting when we really 
aren't yet.  This seems unfortunately to me :-(

If we can use the CMOS, I'd rather use the CMOS.  If we absolutely need 
a different interface, I'd prefer it not be the backdoor interface and 
instead be something is either an existing standard or somethign that we 
have some level of control over.

We can't extend the backdoor interface for arbitrary things.

Regards,

Anthony Liguori

Regards,

Anthony Liguori

> -- Jamie
>
>
>   

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

[Gleb Natapov]

On Mon, Jul 28, 2008 at 09:37:01AM -0500, Anthony Liguori wrote:
> Gleb Natapov wrote:
>> Hi Chris,
>>
>> On Mon, Jul 28, 2008 at 03:25:06PM +0200, Chris Lalancette wrote:
>>   
>>> All,
>>>      Attached is a three part patch series to implement a "-uuid" command-line
>>> option to qemu.  The original work for this was all done by Gleb Natapov; since
>>> there hadn't seemed to be any activity on this since June, I picked up his
>>> patches and ran with them (original posting:
>>> http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00167.html).  These
>>> patches are basically the same as his, just cleaned up according to Anthony
>>> Liguori's feedback.
>>>     
>> Actually there was activity on this. I addressed Anthony's feedback and
>> reposted the patch series (I think even twice). Here is the last one:
>> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00448.html
>> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00442.html
>> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00443.html
>> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00444.html
>> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00445.html
>> http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00446.html
>>
>> Fabrice said that he doesn't like vmware backdoor interface though
>> (http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00487.html)
>> I asked what interface he wants to use for qemu/guest communication, but
>> he never replied to this :(
>>   
>
> 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.

> 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.


--
			Gleb.

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

[Anthony Liguori]

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.

>> 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).
2) The patches updated to work with this new interface.

We should only support the VMware backdoor interface when it lets us 
reuse existing third-party code.  We should not be creating new guest 
code (or BIOS code) that makes use of the backdoor interface.

Regards,

Anthony Liguori

> --
> 			Gleb.
>   

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

[Gleb Natapov]

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?

--
			Gleb.

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

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

On 7/29/08, Gleb Natapov <gleb@qumranet.com> 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.

[-- Attachment #2: pc_use_firmware_abi.diff --]
[-- Type: plain/text, Size: 5462 bytes --]

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

[Gleb Natapov]

> 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.
I haven't seen any comments on this. Anthony, is this approach
acceptable?

> Index: qemu/hw/pc.c
> ===================================================================
> --- qemu.orig/hw/pc.c	2008-07-30 16:58:03.000000000 +0000
> +++ qemu/hw/pc.c	2008-07-30 17:24:01.000000000 +0000
> @@ -32,6 +32,7 @@
>  #include "smbus.h"
>  #include "boards.h"
>  #include "console.h"
> +#include "firmware_abi.h"
>  
>  /* output Bochs bios info messages */
>  //#define DEBUG_BIOS
> @@ -41,6 +42,8 @@
>  #define VGABIOS_CIRRUS_FILENAME "vgabios-cirrus.bin"
>  
>  #define PC_MAX_BIOS_SIZE (4 * 1024 * 1024)
> +#define PC_CFG_ROM_ADDR 0xf0000000
> +#define PC_CFG_ROM_SIZE 4096
>  
>  /* Leave a chunk of memory at the top of RAM for the BIOS ACPI tables.  */
>  #define ACPI_DATA_SIZE       0x10000
> @@ -712,6 +715,55 @@
>      nb_ne2k++;
>  }
>  
> +static int pc_cfg_rom_set_params(ram_addr_t cfg_rom,
> +                                 const char *arch,
> +                                 ram_addr_t below_4g_mem_size,
> +                                 ram_addr_t above_4g_mem_size,
> +                                 const char *boot_devices)
> +{
> +    uint32_t start;
> +    uint8_t image[PC_CFG_ROM_SIZE];
> +    ohwcfg_v3_t *header = (ohwcfg_v3_t *)ℑ
> +    struct pc_arch_cfg *pc_header;
> +    extern int nographic;
> +
> +    memset(image, '\0', sizeof(image));
> +
> +    // Try to match PPC NVRAM
> +    strcpy((char *)header->struct_ident, "QEMU_BIOS");
> +    header->struct_version = cpu_to_le32(3); /* structure v3 */
> +
> +    header->nvram_arch_ptr = cpu_to_le16(sizeof(ohwcfg_v3_t));
> +    header->nvram_arch_size = cpu_to_le16(sizeof(struct pc_arch_cfg));
> +    strcpy((char *)header->arch, arch);
> +    header->nb_cpus = smp_cpus & 0xff;
> +    header->RAM0_base = 0;
> +    header->RAM0_size = cpu_to_le64((uint64_t)below_4g_mem_size);
> +    if (above_4g_mem_size) {
> +        header->RAM1_base = 0x100000000ULL;
> +        header->RAM1_size = cpu_to_le64((uint64_t)above_4g_mem_size);
> +    }
> +    strcpy((char *)header->boot_devices, boot_devices);
> +    header->nboot_devices = strlen(boot_devices) & 0xff;
> +
> +    if (nographic)
> +        header->graphic_flags = cpu_to_le16(OHW_GF_NOGRAPHICS);
> +
> +    strncpy((char *)header->uuid, "QEMUQEMUQEMUQEMU", 16);
> +
> +    header->crc = cpu_to_le16(OHW_compute_crc(header, 0x00, 0xF8));
> +
> +    // Architecture specific header
> +    start = sizeof(ohwcfg_v3_t);
> +    pc_header = (struct pc_arch_cfg *)&image[start];
> +    pc_header->valid = 1;
> +    start += sizeof(struct pc_arch_cfg);
> +
> +    cpu_physical_memory_write_rom(cfg_rom, image, sizeof(image));
> +
> +    return 0;
> +}
> +
>  /* PC hardware initialisation */
>  static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
>                       const char *boot_device, DisplayState *ds,
> @@ -723,6 +775,7 @@
>      int ret, linux_boot, i;
>      ram_addr_t ram_addr, vga_ram_addr, bios_offset, vga_bios_offset;
>      ram_addr_t below_4g_mem_size, above_4g_mem_size = 0;
> +    ram_addr_t cfg_rom_offset;
>      int bios_size, isa_bios_size, vga_bios_size;
>      PCIBus *pci_bus;
>      int piix3_devfn = -1;
> @@ -867,6 +920,14 @@
>      cpu_register_physical_memory((uint32_t)(-bios_size),
>                                   bios_size, bios_offset | IO_MEM_ROM);
>  
> +    /* map configuration ROM */
> +    cfg_rom_offset = qemu_ram_alloc(PC_CFG_ROM_SIZE);
> +    cpu_register_physical_memory(PC_CFG_ROM_ADDR, PC_CFG_ROM_SIZE,
> +                                 cfg_rom_offset | IO_MEM_ROM);
> +    pc_cfg_rom_set_params(PC_CFG_ROM_ADDR, pci_enabled? "pc" : "isapc",
> +                          below_4g_mem_size, above_4g_mem_size,
> +                          boot_device);
> +
>      bochs_bios_init();
>  
>      if (linux_boot)
> Index: qemu/hw/firmware_abi.h
> ===================================================================
> --- qemu.orig/hw/firmware_abi.h	2008-07-30 16:57:53.000000000 +0000
> +++ qemu/hw/firmware_abi.h	2008-07-30 17:22:12.000000000 +0000
> @@ -54,8 +54,10 @@
>      uint8_t  pad3[5];
>      /* 0xD0: boot devices                            */
>      uint8_t  boot_devices[0x10];
> -    /* 0xE0                                          */
> -    uint8_t  pad4[0x1C]; /* 28 */
> +    /* 0xE0: UUID                                    */
> +    uint8_t  uuid[0x10];
> +    /* 0xF0                                          */
> +    uint8_t  pad4[0xC]; /* 12 */
>      /* 0xFC: checksum                                */
>      uint16_t crc;
>      uint8_t  pad5[0x02];
> @@ -176,6 +178,12 @@
>      header->checksum = tmp;
>  }
>  
> +/* PC configuration structure */
> +struct pc_arch_cfg {
> +    uint8_t valid;
> +    uint8_t unused[63];
> +};
> +
>  #else /* __ASSEMBLY__ */
>  
>  /* Structure offsets for asm use */
> Index: qemu/hw/sun4m.c
> ===================================================================
> --- qemu.orig/hw/sun4m.c	2008-07-30 17:24:14.000000000 +0000
> +++ qemu/hw/sun4m.c	2008-07-30 17:24:56.000000000 +0000
> @@ -213,6 +213,8 @@
>      if (nographic)
>          header->graphic_flags = cpu_to_be16(OHW_GF_NOGRAPHICS);
>  
> +    strncpy((char *)header->uuid, "QEMUQEMUQEMUQEMU", 16);
> +
>      header->crc = cpu_to_be16(OHW_compute_crc(header, 0x00, 0xF8));
>  
>      // Architecture specific header
> Index: qemu/hw/sun4u.c
> ===================================================================
> --- qemu.orig/hw/sun4u.c	2008-07-30 17:24:16.000000000 +0000
> +++ qemu/hw/sun4u.c	2008-07-30 17:24:33.000000000 +0000
> @@ -144,6 +144,8 @@
>      if (nographic)
>          header->graphic_flags = cpu_to_be16(OHW_GF_NOGRAPHICS);
>  
> +    strncpy((char *)header->uuid, "QEMUQEMUQEMUQEMU", 16);
> +
>      header->crc = cpu_to_be16(OHW_compute_crc(header, 0x00, 0xF8));
>  
>      // Architecture specific header


--
			Gleb.

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

[Anthony Liguori]

Gleb Natapov wrote:
>> 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.
>>     
> I haven't seen any comments on this. Anthony, is this approach
> acceptable?
>   

I like having a configuration blob but am uncomfortable with stashing it 
in memory somewhere.  I would think maybe stealing a few IO ports and 
using that to read the rom may be nicer (albeit slower).  I think it's 
something that needs to be implemented fully to work out the kinks.

Regards,

Anthony Liguori


> 			Gleb.
>   

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

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On 8/6/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Gleb Natapov wrote:
>
> >
> > > 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.
> > >
> > >
> > I haven't seen any comments on this. Anthony, is this approach
> > acceptable?
> >
> >
>
>  I like having a configuration blob but am uncomfortable with stashing it in
> memory somewhere.  I would think maybe stealing a few IO ports and using
> that to read the rom may be nicer (albeit slower).  I think it's something
> that needs to be implemented fully to work out the kinks.

Ok, I made a new version that uses IO ports. But then you have to
select a port instead of address, is that any better?

[-- Attachment #2: pc_use_firmware_abi.diff --]
[-- Type: plain/text, Size: 5715 bytes --]

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

[Anthony Liguori]

Blue Swirl wrote:
> On 8/6/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>>  I like having a configuration blob but am uncomfortable with stashing it in
>> memory somewhere.  I would think maybe stealing a few IO ports and using
>> that to read the rom may be nicer (albeit slower).  I think it's something
>> that needs to be implemented fully to work out the kinks.
>>     
>
> Ok, I made a new version that uses IO ports. But then you have to
> select a port instead of address, is that any better?
>   

A lot of the BIOS code is 16-bit and accessing high memory location from 
16-bit code is a royal pain.  That is simplified with using IO ports.

Regards,

Anthony Liguori

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

[Sebastian Herbszt]

Anthony Liguori wrote:
>>>  I like having a configuration blob but am uncomfortable with stashing it in
>>> memory somewhere.  I would think maybe stealing a few IO ports and using
>>> that to read the rom may be nicer (albeit slower).  I think it's something
>>> that needs to be implemented fully to work out the kinks.
>>>     
>>
>> Ok, I made a new version that uses IO ports. But then you have to
>> select a port instead of address, is that any better?
>>   
> 
> A lot of the BIOS code is 16-bit and accessing high memory location from 
> 16-bit code is a royal pain.  That is simplified with using IO ports.

Could put it in the 0xe000 segment, e.g. 4kb below rombios16.bin at 0xf000.

- Sebastian

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

[Anthony Liguori]

Sebastian Herbszt wrote:
> Anthony Liguori wrote:
>>>>  I like having a configuration blob but am uncomfortable with 
>>>> stashing it in
>>>> memory somewhere.  I would think maybe stealing a few IO ports and 
>>>> using
>>>> that to read the rom may be nicer (albeit slower).  I think it's 
>>>> something
>>>> that needs to be implemented fully to work out the kinks.
>>>>     
>>>
>>> Ok, I made a new version that uses IO ports. But then you have to
>>> select a port instead of address, is that any better?
>>>   
>>
>> A lot of the BIOS code is 16-bit and accessing high memory location 
>> from 16-bit code is a royal pain.  That is simplified with using IO 
>> ports.
>
> Could put it in the 0xe000 segment, e.g. 4kb below rombios16.bin at 
> 0xf000.

Which limits the size to 4kb.  If we use the IO port patch that Blue 
Swirl proposed, we have 64kb of space with a pretty reasonable expansion 
mechanism.

Regards,

Anthony Liguori

> - Sebastian
>

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

[Daniel P. Berrange]

On Mon, Jul 28, 2008 at 09:37:01AM -0500, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >Hi Chris,
> >
> >On Mon, Jul 28, 2008 at 03:25:06PM +0200, Chris Lalancette wrote:
> >  
> >>All,
> >>     Attached is a three part patch series to implement a "-uuid" 
> >>     command-line
> >>option to qemu.  The original work for this was all done by Gleb Natapov; 
> >>since
> >>there hadn't seemed to be any activity on this since June, I picked up his
> >>patches and ran with them (original posting:
> >>http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00167.html).  
> >>These
> >>patches are basically the same as his, just cleaned up according to 
> >>Anthony
> >>Liguori's feedback.
> >>    
> >Actually there was activity on this. I addressed Anthony's feedback and
> >reposted the patch series (I think even twice). Here is the last one:
> >http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00448.html
> >http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00442.html
> >http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00443.html
> >http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00444.html
> >http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00445.html
> >http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00446.html
> >
> >Fabrice said that he doesn't like vmware backdoor interface though
> >(http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00487.html)
> >I asked what interface he wants to use for qemu/guest communication, but
> >he never replied to this :(
> >  
> 
> 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 
> 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'd really welcome addition of SMBIOS support too - for x86 the UUID
in the SMBIOS tables, is the most effective way for a guest admin to
find their machine identify in a format that can be correlated with
the host machine by external admin tools. Xen has code for doing SMBIOS
tables that could be useful to anyone wanting to work on this. Though it
won't be a straight port since they integrate it with the HVM loader
firmware, the general data table setup code ought to be reusable, only
leaving the BIOS integration part.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

[Chris Lalancette]

Daniel P. Berrange wrote:
> I'd really welcome addition of SMBIOS support too - for x86 the UUID
> in the SMBIOS tables, is the most effective way for a guest admin to
> find their machine identify in a format that can be correlated with
> the host machine by external admin tools. Xen has code for doing SMBIOS
> tables that could be useful to anyone wanting to work on this. Though it
> won't be a straight port since they integrate it with the HVM loader
> firmware, the general data table setup code ought to be reusable, only
> leaving the BIOS integration part.

Again, just to be clear; SMBIOS support is already there today in Bochs BIOS
(you can see this by doing "dmidecode" inside a guest).  The only real thing
this patchset was changing was plumbing it through to get the UUID from the Qemu
device model through the VMware back door.  Since there seems to be aversion to
the VMware back door, however, the only real question is how we pass UUID
information from the Qemu device model through to the Boch BIOS, so it can place
the UUID in the SMBIOS tables that it is already building.  Suggestions so far
have been:

1)  Patch the UUID directly into the Bochs BIOS when the Qemu process is loading
it.  This is pretty straightforward, but not very extensible.
2)  Find or come up with a "standard" backdoor mechanism.  I would think this
would be quite similar to the VMware one, but wouldn't be subject to VMware's
whims on it.

Chris Lalancette

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

[Jamie Lokier]

Gleb Natapov wrote:
> Fabrice said that he doesn't like vmware backdoor interface though
> (http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00487.html)

Regardless of whether anyone likes the backdoor interface, it ought at
least fix the IN/OUT bug (where OUT needs to do the same as IN), if
the interface stays.

-- Jamie