qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v2 1/6] Use IO port for qemu<->guest BIOS communication.
Date: Mon, 25 Aug 2008 13:01:23 -0500
User-agent: Thunderbird 2.0.0.16 (X11/20080723)

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.

Regards,

Anthony Liguori






reply via email to

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