Re: [Qemu-devel] [RFC 2/7] fw_cfg dma interface

[Laszlo Ersek <lersek@redhat.com>]

On 07/22/15 19:18, Kevin O'Connor wrote:
> On Wed, Jul 22, 2015 at 10:31:12AM +0200, Marc Marí wrote:
>> On Wed, 22 Jul 2015 00:24:34 -0400
>> "Kevin O'Connor" <kevin@koconnor.net> wrote:
>>> On Tue, Jul 21, 2015 at 06:03:41PM +0200, Marc Marí wrote:
>>>> From: Gerd Hoffmann <kraxel@redhat.com>
>>>>
>>>> First draft of a fw_cfg dma interface.  Designed as add-on to the
>>>> extisting fw_cfg interface, i.e. there is no select register.  There
>>>> are four 32bit registers:  Target address (low and high bits),
>>>> transfer length, control register.
>>>
>>> If I read this interface correctly, a guest will have at least six
>>> faults to complete a typical fw_cfg dma transfer (select, target low,
>>> target high, transfer length, control register write, control register
>>> read).  I wonder if using a DMA transfer descriptor might be more
>>> efficient.
> [...]
>> That is probably faster and more flexible. I think it's a good step
>> forward. But, on the other side, is this a too big break of what is
>> actually implemented in MMIO?
>>
>> At the end we will have MMIO version, with a select and a data
>> register, and DMA version, with a 64 bit address register. How can we
>> differentiate between versions? Laszlo talks about the ID, but this is
>> already in one of the fields (so you need to know the protocol to get
>> the protocol). How could we do this transition more seamless?
> 
> Well, one way would be to place a 64bit MMIO (or IO) register at a
> magic address.  The firmware could then read the magic address and
> check it against a signature (eg, "QEMU CFG").  If the signature
> matches then it would know it could use the DMA version of the fw_cfg
> interface (by issuing writes, instead of reads, to the magic address).
> The firmware would then not have to use the older select/data fw_cfg
> interface at all.

So, with regard to this patchset, I guess I'm in the position of the
"hateful reviewer". I cannot give constructive ideas simply because I'm
not knowledgeable enough about "anything DMA" in QEMU. I can only
express my negative thoughs, whenever I have such. :)

In any case, I wouldn't recommend a signature check -- the fw-cfg
interface already has a signature mechanism (independently of DMA -- see
FW_CFG_SIGNATURE in docs/specs/fw_cfg.txt). Adding another signature
(for a sub-feature) feels unclean, especially since we have a feature
bitmap already, in one of the preexistent fw_cfg keys. (See FW_CFG_ID.)

So, the "slow" mechanism could be used to retrieve FW_CFG_ID. Then,
based on bit #1 (value 2), presence of he DMA interface could be deduced.

> Another possibility would be to place the new fw_cfg dma register
> address into a named fw_cfg "file" (eg, "fw_cfg_dma").  The firmware
> could then use the existing select/data fw_cfg interface to check if
> the new dma interface is available by scanning for that "fw_cfg_dma"
> file.  This has the advantage of not requiring a new "magic address",
> but has the disadvantage of a more complex probe.

I like this one so much that I'm worried I'm missing some details. :)

The more complex probe shouldn't be an issue. The DMA interface would
bring such huge savings (*) that the probe's cost would be "amortized".

(*) ... at least in the environment where I really care about this: on
Aarch64 KVM, libguestfs loads a kernel and an initrd through *extremely*
slow MMIO.

Shaving off a few milliseconds for x86 SeaBIOS, so that this stack can
"compete" with Docker (or whatever) for short-lived containers, is
perhaps a valid goal, but personally, meh. :) I intend to write client
code for this DMA interface only in AAVMF, and not in OVMF -- OVMF is
unavoidably too "busy" to be considered for containers, so the DMA
interface would just be a complication. But, for libguestfs on Aarch64
KVM, it is a game changer.

Thanks
Laszlo