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" <ke...@koconnor.net> wrote: >>> On Tue, Jul 21, 2015 at 06:03:41PM +0200, Marc Marí wrote: >>>> From: Gerd Hoffmann <kra...@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
