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

[Anthony Liguori <anthony@codemonkey.ws>]

Blue Swirl wrote:
> On 8/25/08, Gleb Natapov <gleb@qumranet.com> 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.

Regards,

Anthony Liguori