From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZIGJY-0007On-HJ for qemu-devel@nongnu.org; Thu, 23 Jul 2015 09:13:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZIGJS-0003z8-IN for qemu-devel@nongnu.org; Thu, 23 Jul 2015 09:13:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55638) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZIGJS-0003z1-AX for qemu-devel@nongnu.org; Thu, 23 Jul 2015 09:13:26 -0400 References: <1437494626-3773-1-git-send-email-markmb@redhat.com> <1437494626-3773-3-git-send-email-markmb@redhat.com> <20150722042434.GB27877@morn.localdomain> <20150722103112.1d97386b@markmb_rh> <20150722171804.GA2717@morn.localdomain> From: Laszlo Ersek Message-ID: <55B0E86E.2030209@redhat.com> Date: Thu, 23 Jul 2015 15:13:18 +0200 MIME-Version: 1.0 In-Reply-To: <20150722171804.GA2717@morn.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC 2/7] fw_cfg dma interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor , =?UTF-8?Q?Marc_Mar=c3=ad?= Cc: qemu-devel@nongnu.org, Stefan Hajnoczi , "Richard W.M. Jones" , Gerd Hoffmann , Paolo Bonzini On 07/22/15 19:18, Kevin O'Connor wrote: > On Wed, Jul 22, 2015 at 10:31:12AM +0200, Marc Mar=ED wrote: >> On Wed, 22 Jul 2015 00:24:34 -0400 >> "Kevin O'Connor" wrote: >>> On Tue, Jul 21, 2015 at 06:03:41PM +0200, Marc Mar=ED wrote: >>>> From: Gerd Hoffmann >>>> >>>> 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 registe= r >>> 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? >=20 > 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