Agreed -- making the area uncached outright is not the preferred solution. For drivers that don't use a bus protocol like PCI_IO, you can use the edk2 DmaLib ( https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmbeddedPkg/Include/Library/DmaLib.h ) which provides functions for mapping buffers which in turn will perform the proper flushing and invalidation (if aligned), double-buffering (if unaligned), or uncached mapping (for common buffers requiring simultaneous HW and driver access).
Eugene -----Original Message----- From: Paolo Bonzini [mailto:pbonz...@redhat.com] Sent: Thursday, January 23, 2014 10:25 AM To: Laszlo Ersek; Michael Casadevall; Leif Lindholm; Olivier Martin Cc: Rusty Russell; edk2-devel@lists.sourceforge.net; virtio-comm...@lists.oasis-open.org; Fu Wei Subject: Re: [edk2] [virtio-comment] virtio-blk vs. caching on FVP Base Il 23/01/2014 18:09, Laszlo Ersek ha scritto: > > They both worked in the sense that each got me over the immediate FVP > Base model warning, and *something* was loaded from the virtio-blk disk. > However that "something" (which should have been a grub2 binary) could > not be executed, implying that further corruption was happening. > > The straightforward idea is that it's not enough to make the ring area > itself uncacheable: the scatter-gather memory areas *referenced* by > the descriptors located inside the ring have to be uncacheable too. I think making any of these uncacheable is wrong, for two reasons. First, the solution to this would be to force a dcache writeback after writing, before kicking the vring; and flushing the dcache and icache before reading. This is different from memory barriers, and is true for all DMA-capable devices. How to do this is probably somewhere in the ARM docs but UEFI ought to provide generic primitives already. Uncacheable memory should only be used if the cost of the dcache flushes exceeds the cost of sacrificing caching for all accesses. As you guessed this is not the case. Second, because virtio should not require any dcache flushing. Icache, yes (just like any other case of self-modifying code in a guest; in this case the "modification" is done by reading from disk), but ISTR that the device reads and writes should be considered cache-coherent. So an icache flush might be missing in TianoCore, but not in the virtio drivers (rather the loader should do it just after loading executable code into memory). And any requirement on the dcache is likely an emulator bug. Thanks! Paolo > This would be very inconvenient, however, because the "scatter-gather > memory areas" in question are almost always local variables, of which > are many, and whose size is mostly smaller than a page. ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
