Re: [Qemu-devel] [PATCH v2 1/6] Use IO port for qemu<->guest BIOS communication.

[Blue Swirl]

On 8/25/08, Anthony Liguori <address@hidden> wrote:
> Blue Swirl wrote:
>
> > On 8/25/08, Gleb Natapov <address@hidden> wrote:
> >
> > >
> > > There was a long discussion about this. Have you read it already?
> > >
> >
>
>  Yes, but it wasn't clear to me that there was a consensus in that
> discussion.  Since the code isn't structured for reuse either, that raised a
> flag.  I think it would be pretty useful to have a standard mechanism that
> worked across architectures to query QEMU-specific information.
>
>
> >
> > >  My reasoning is
> > >  that firmware structure mostly provides information that PC bios
> doesn't
> > >  need and don't provides info that PC bios needs. Nobody showed what is
> > >  the benefit of using firmware interface for communicating with PC bios
> > >  yet. Because firmware interface contains mostly unneeded info there is
> > >  no point in copying the whole structure into the bios, only specific
> > >  fields will be copied and to do that bios will have to know magic value
> > >  (offset of the field). So just instead of pretending we are using
> firmware
> > >  interface we can simply define magic values for each parameter we want
> > >  to pass from qemu to bios and use them instead of structure offsets.
> > >
> > >
> >
> > This has the advantage that the sizes of the fields are not fixed by
> > the structure layout. On the other hand, same can be achieved with ROM
> > by using an index, which lists the offsets and sizes in the beginning
> > of the ROM for each magic parameter. If some parameter is not used
> > (for that architecture or because a newer version has suppressed it),
> > size and index can be zero.
> >
> > A more important benefit is in my view that the whole protocol can be
> > extended, whereas a ROM will always be a ROM. But then taking a
> > security angle, that could be an advantage too. I don't know which is
> > more important.
> >
> >
>
>  Blue Swirl: What do you think of switching sparc to use a structure more
> like this?  I do prefer a key-value mechanism verses a blob.  Even with pure
> MMIO, the same results could be achieved by treating the MMIO region as
> registers and using a selector.

I could switch Sparc to something like this, if the goal is that it
will be used by all targets.

There should be a .h file which lists the keys and which can be
included from C and asm, like current firmware_abi.h. I'd define an
offset (0x8000?) for architecture-specific keys which need not be in
the same .h file.