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

["Marc Marí" <markmb@redhat.com>]

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, if a transfer descriptor was defined with something like:
> 
> struct fwcfg_dma {
>     u16 command;
>     u16 select;
>     u32 transfer_length;
>     u64 target_addr;
> } PACKED;
> 
> and QEMU was informed of the transfer descriptor address (one fault on
> 32bit addresses; two faults on 64bit addresses) then QEMU could read
> the transfer descriptor, perform the requested operation, and then
> update the transfer descriptor on completion.  This would reduce the
> total number of faults between QEMU and the firmware, and allow for a
> more flexible interface for future growth.
> 
> -Kevin
> 

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?

Thanks
Marc