: Add UUID command-line option
cover : Add UUID command-line option
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/[email protected]/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.
Hi Chris,
Quoted 8 lines · 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/[email protected]/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.
Quoted 22 lines · Gleb Natapov
Hi Chris,
Quoted 9 lines · 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/[email protected]/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
Quoted 5 lines
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
Quoted 6 lines
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.
Quoted 6 lines · Anthony Liguori
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
Quoted 10 lines · Chris Lalancette
Quoted 2 lines · Anthony Liguori
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
Quoted 7 lines
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
Quoted 8 lines · Anthony Liguori
Quoted 5 lines
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
Quoted 32 lines · Chris Lalancette
Quoted 8 lines · Anthony Liguori
Quoted 6 lines
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;
Quoted 9 lines
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
Quoted 5 lines
Later on in the rombios32 code the bios_uuid[] is used to build up the SMBIOS tables.
Chris Lalancette
Quoted 3 lines · Anthony Liguori
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
Quoted 5 lines · Chris Lalancette
Quoted 3 lines · Anthony Liguori
That makes me sad that they merged that. What a terribly complicated way to do something that's relatively simple.
Quoted 8 lines
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.
Quoted 4 lines · Gleb Natapov
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.
Quoted 2 lines
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.
Quoted 7 lines
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
Quoted 3 lines
--
Gleb.
Quoted 9 lines · Anthony Liguori
Quoted 4 lines · Gleb Natapov
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 7 lines
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 :)
Quoted 5 lines
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.
Quoted 32 lines · Gleb Natapov
Quoted 9 lines · Anthony Liguori
Quoted 4 lines · Gleb Natapov
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.
Quoted 5 lines
Quoted 2 lines
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.Quoted 8 lines
Quoted 7 lines
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 :)
Quoted 8 lines
Quoted 5 lines
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.
Quoted 6 lines · Anthony Liguori
Quoted 3 lines
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.
Quoted 4 lines
Quoted 2 lines
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? :-)
Quoted 4 lines
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
Quoted 6 lines · Jamie Lokier
Quoted 4 lines · Anthony Liguori
Quoted 4 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 2 lines
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
Quoted 13 lines
Quoted 2 lines
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
Quoted 8 lines · Anthony Liguori
Quoted 8 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 3 lines
Quoted 1 line
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 :-)
Quoted 2 lines
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
Quoted 11 lines · Jamie Lokier
Quoted 2 lines
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
Quoted 4 lines
-- Jamie
Quoted 12 lines · Anthony Liguori
Quoted 10 lines · Jamie Lokier
Quoted 2 lines
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.
Quoted 4 lines
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
Quoted 4 lines · Paul Brook
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
Quoted 2 lines
Paul
Quoted 14 lines · Anthony Liguori
Quoted 4 lines · Jamie Lokier
Quoted 3 lines
If you care to do this sort of work, you can certainly recompile the BIOS. The source is there afterall.
Quoted 8 lines
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.
Quoted 5 lines
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.
Quoted 10 lines · Anthony Liguori
Quoted 10 lines
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
Quoted 16 lines · Jamie Lokier
Quoted 10 lines
Quoted 10 lines
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.
Quoted 8 lines
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
Quoted 2 lines · Anthony Liguori
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
Quoted 8 lines · Jamie Lokier
Quoted 2 lines · Anthony Liguori
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
Quoted 4 lines
-- Jamie
Quoted 29 lines · Anthony Liguori
Quoted 22 lines · Gleb Natapov
Hi Chris,
Quoted 9 lines · 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/[email protected]/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.htmlQuoted 5 lines
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 :(
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 6 lines · Gleb Natapov
Quoted 2 lines · Anthony Liguori
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.
Quoted 5 lines
Quoted 2 lines
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
Quoted 3 lines
--
Gleb.
Quoted 7 lines · Anthony Liguori
Quoted 6 lines · Gleb Natapov
Quoted 4 lines · Anthony Liguori
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
Quoted 6 lines
Quoted 2 lines
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 :)
Quoted 9 lines
Quoted 8 lines
Quoted 5 lines
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.
Quoted 7 lines
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.
Quoted 32 lines · Gleb Natapov
Quoted 7 lines · Anthony Liguori
Quoted 6 lines · Gleb Natapov
Quoted 4 lines · Anthony Liguori
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
Quoted 6 lines
Quoted 2 lines
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 :)Quoted 13 lines
Quoted 8 lines
Quoted 5 lines
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:
Quoted 7 lines
Quoted 3 lines
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.
hw/pc.c +61 -0
@@ -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)
hw/firmware_abi.h +10 -2
@@ -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 */
hw/sun4m.c +2 -0
@@ -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
hw/sun4u.c +2 -0
@@ -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
Quoted 3 lines
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?
Quoted 148 lines
Index:
qemu/hw/pc.c
===================================================================hw/pc.c +61
-0@@ -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
===================================================================hw/firmware_abi.h +10
-2@@ -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
===================================================================hw/sun4m.c +2
-0@@ -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
===================================================================
hw/sun4u.c line 151
Quoted 8 lines
hw/sun4u.c +2
-0@@ -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.
Quoted 7 lines · Gleb Natapov
Quoted 4 lines
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
Quoted 2 lines
Gleb.
Quoted 13 lines · Anthony Liguori
Quoted 10 lines · Gleb Natapov
Quoted 6 lines
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?
Quoted 4 lines
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?
hw/pc.c +93 -0
@@ -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_PORT 0x1234 +#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,86 @@ nb_ne2k++; } +typedef struct CfgROMState { +uint8_t cfg_rom[PC_CFG_ROM_SIZE ]; +uint16_t curr_addr; +}CfgROMState ; + +static int pc_cfg_rom_set_params (CfgROMState *s, +const char *arch, +ram_addr_t below_4g_mem_size, +ram_addr_t above_4g_mem_size, +const char *boot_devices) +{ +uint32_t start; +ohwcfg_v3_t *header = (ohwcfg_v3_t *)s->cfg_rom; +struct pc_arch_cfg *pc_header; +extern int nographic; + +memset (s->cfg_rom,'\0' ,PC_CFG_ROM_SIZE ); + +// 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 *)&s->cfg_rom[start]; + pc_header->valid =1 ; + +return 0 ; +} + +static uint32_t pc_cfg_rom_readw (void *opaque,uint32_t addr) +{ +CfgROMState *s = (CfgROMState *)opaque; + +if (s->curr_addr <PC_CFG_ROM_SIZE ) +return s->cfg_rom[s->curr_addr]; +return 0 ; +} + +static void pc_cfg_rom_writew (void *opaque,uint32_t addr,uint32_t value) +{ +CfgROMState *s = (CfgROMState *)opaque; + + s->curr_addr = value; +} + +static void *pc_cfg_rom_map (uint32_t addr) +{ +CfgROMState *s; + + s =qemu_mallocz (sizeof (CfgROMState)); +if (!s) +return NULL ; + +register_ioport_read (addr,2 ,2 , pc_cfg_rom_readw, s); +register_ioport_write (addr,2 ,2 , pc_cfg_rom_writew, s); + +return s; +} +/* PC hardware initialisation */ static void pc_init1(ram_addr_t ram_size, int vga_ram_size, const char *boot_device, DisplayState *ds,
@@ -867,6 +950,16 @@cpu_register_physical_memory ((uint32_t )(-bios_size), bios_size, bios_offset |IO_MEM_ROM ); + { +CfgROMState *cfg_rom; + +/* map configuration ROM */ + cfg_rom =pc_cfg_rom_map (PC_CFG_ROM_PORT ); +pc_cfg_rom_set_params (cfg_rom, pci_enabled?"pc" :"isapc" , + below_4g_mem_size, above_4g_mem_size, + boot_device); + } +bochs_bios_init ();if (linux_boot)
hw/firmware_abi.h +10 -2
@@ -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 */
hw/sun4m.c +2 -0
@@ -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
hw/sun4u.c +2 -0
@@ -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
Quoted 11 lines · Blue Swirl
Quoted 5 lines · Anthony Liguori
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
Quoted 11 lines · Anthony Liguori
Quoted 9 lines
Quoted 5 lines
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
Quoted 8 lines · Sebastian Herbszt
Quoted 7 lines · Anthony Liguori
Quoted 7 lines
Quoted 6 lines
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.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
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
0xe000segment, e.g. 4kb below rombios16.bin at0xf000.
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
Quoted 2 lines
- Sebastian
Quoted 33 lines · Anthony Liguori
Quoted 26 lines · Gleb Natapov
Hi Chris,
Quoted 4 lines · 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;Quoted 9 lines
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/[email protected]/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.htmlQuoted 5 lines
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 :(
Quoted 6 lines
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
Signature · 4 lines
|: 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 :|
Quoted 8 lines · Daniel P. Berrange
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
Quoted 2 lines · Gleb Natapov
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