Re: [virtio-comment] virtio-blk vs. caching on FVP Base

[Paolo Bonzini <pbonzini@redhat.com>]

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.