On 11/20/14 21:10, Peter Maydell wrote: > On 20 November 2014 19:49, Jon Masters <jcm@xxxxxxxxxx> wrote: >> On 11/20/2014 01:40 PM, Peter Maydell wrote: >>> The situation is not so bleak as this. See section B2.9 "Mismatched >>> memory attributes" in the ARMv8 ARM ARM (DDI0487A.d), which lays >>> out in some detail what the results of mismatched attributes are >>> (generally, you lose ordering or coherency guarantees you might >>> have hoped to have). They're not pretty, but it's not as bad >>> as completely UNPREDICTABLE behaviour. >> >> Quick side note that I did raise exactly this issue with the ARM >> Architecture team several years ago (that of missmatched memory >> attributes between a guest and hypervisor) and it is a known concern. > > I think in practice for a well-behaved guest we can arrange > that everything is fine (roughly, the guest has to treat > DMA-capable devices as doing coherent-dma, which we can tell > them to do via DT bindings or ACPI[*], plus the special > case handling we already have for bootup), and naughty guests > will only confuse themselves. But I need to think a bit more > about it (and we should probably write down how it works > somewhere :-)). > > [*] We should be able to emulate non-coherent-DMA devices but > would need an extra API from KVM so userspace can do "clean > dcache to point of coherency". And in practice I'm not sure > we need to emulate those devices... This basically means that virtio transfers should just use normal memory in the guest (treating virtio transfers as "coherent DMA"), right? We're actually doing that in the ArmVirtualizationQemu.dsc build of edk2, and Things Work Great (TM) in guests on the Mustang. Thanks Laszlo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
