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

[Blue Swirl]

On 8/25/08, Gleb Natapov <address@hidden> wrote:
> On Mon, Aug 25, 2008 at 09:24:33AM -0500, Anthony Liguori wrote:
>  > Gleb Natapov wrote:
>  >> Use PIO to get configuration info between qemu process and guest BIOS.
>  >>
>  >> Signed-off-by: Gleb Natapov <address@hidden>
>  >> ---
>  >>
>  >>  hw/pc.c |   59 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  >>  1 files changed, 59 insertions(+), 0 deletions(-)
>  >>
>  >> diff --git a/hw/pc.c b/hw/pc.c
>  >> index 213ead8..8caa48f 100644
>  >> --- a/hw/pc.c
>  >> +++ b/hw/pc.c
>  >> @@ -44,6 +44,7 @@
>  >>   /* Leave a chunk of memory at the top of RAM for the BIOS ACPI
>  >> tables.  */
>  >>  #define ACPI_DATA_SIZE       0x10000
>  >> +#define BIOS_CFG_IOPORT 0x1234
>  >>   #define MAX_IDE_BUS 2
>  >>  @@ -53,6 +54,26 @@ static PITState *pit;
>  >>  static IOAPICState *ioapic;
>  >>  static PCIDevice *i440fx_state;
>  >>  +typedef struct _BIOSCfgEntry {
>  >> +    uint16_t len;
>  >> +    uint8_t *data;
>  >> +} BIOSCfgEntry;
>  >>
>  >
>  > So why aren't we using the ROM mechanism suggested by Blue Swirl?
>  > Unless we're switching other firmwares to use this mechanism, I think it
>  > would be better to have a single QEMU<->firmware interface that we could
>  > support for all architectures.
>  >
>
> There was a long discussion about this. Have you read it already? 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.

>  Note that all current users of firmware ABI uses memory mapped access to
>  firmware structure and you proposed to use port IO for PC.

On other machines, the IO port would be replaced with MMIO if we want
to use the same mechanism.