qemu-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC 2/7] fw_cfg dma interface
Date: Wed, 22 Jul 2015 10:31:20 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Jul 22, 2015 at 12:24:34AM -0400, Kevin O'Connor wrote:
> On Tue, Jul 21, 2015 at 06:03:41PM +0200, Marc Marí wrote:
> > From: Gerd Hoffmann <address@hidden>
> > 
> > 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.

I like the idea.

In Marc's case of benchmarking -kernel/-initrd times it may not make a
big difference, but if we're going to add a new interface it might as
well be optimal.

Attachment: pgpg4dv5NyBk6.pgp
Description: PGP signature


reply via email to

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