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

["Blue Swirl" <blauwirbel@gmail.com>]

On 8/24/08, Gleb Natapov <gleb@qumranet.com> wrote:
> On Sun, Aug 24, 2008 at 03:01:22PM +0300, Blue Swirl wrote:
>  > On 8/24/08, Gleb Natapov <gleb@qumranet.com> wrote:
>  > > Hello,
>  > >
>  > >   This is one more try to push this patch series into qemu. This time
>  > >  I don't use vmport interface. Instead I implemented simple communication
>  > >  channel between  qemu and BIOS using IO port.  I decided not to  use
>  > >  firmware interface since current users of the interface may depend on
>  > >  exact structure layout, so it doesn't look like a good idea to add
>  > >  arbitrary fields there. Also I don't want to copy the whole ROM into BIOS
>  > >  just to access one field of it. IO channel is implemented by the first
>  > >  patch of the series. Patches 2-5 implement UUID related stuff. Patch 6
>  > >  passes host CPU frequency to fill in SM BIOS table.
>  > >
>  > >  Please comment.
>  >
>  > I disagree about not using the firmware interface. The structure can
>  > be extended and even new versions defined, all structure users are
>  > open source.
>
> It is hard enough to change interface between qemu and bochs BIOS. How
>  complex it will be to simultaneously change interface for several boot
>  loaders.

This is because no Qemu developer has commit rights to Bochs, and
Bochs releases too infrequently. With commit rights, synchronizing a
commit would not be too difficult. And this should be needed only if
the common interface changes incompatibly.

>  >               UUID is not architecture specific, so it should use the
>  > main structure instead if the architecture specific substructure
>  > (nvram_arch*). Adding UUID to unused fields will not break anything.
>
> Most info in ohwcfg_v3_t are not needed (or can be obtained by other
>  means) by PC BIOS, so there is no point in coping the whole structure
>  into BIOS. Of cause BIOS don't have to copy entire ohwcfg_v3_t, but

For example, Bochs seems to use i440fx registers to determine the
available physical memory. This could be changed to use the
configuration structure instead. It's a matter of taste, but I would
find this an improvement.

>  access only required fields by reading only specific offsets, but then the
>  interface will be exactly like the one I proposed with only difference
>  that instead of specifying magic value (like 1 for reading UUID in my
>  patch series), BIOS will have to specify magic offset (like 0xE0).

There is no need for a magic offset, ohwcfg_v3_t is designed to be
included even from asm.