qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gleb Natapov
Subject: Re: [Qemu-devel] [PATCH 0/6] Add UUID command-line option
Date: Sun, 24 Aug 2008 15:24:23 +0300

On Sun, Aug 24, 2008 at 03:01:22PM +0300, Blue Swirl wrote:
> On 8/24/08, Gleb Natapov <address@hidden> 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.

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

--
                        Gleb.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]