On 07/22/15 13:30, Andrew Jones wrote:
> On Tue, Jul 21, 2015 at 09:44:49PM +0200, Laszlo Ersek wrote:
>> On 07/21/15 18:03, Marc Marí wrote:
>>> +static void fw_cfg_dma_transfer(FWCfgState *s)
>>> +{
>>> + dma_addr_t len;
>>> + uint8_t *ptr;
>>> + uint32_t i;
>>> +
>>> + if (s->dma_ctl & FW_CFG_DMA_CTL_ERROR) {
>>> + return;
>>> + }
>>> + if (!(s->dma_ctl & FW_CFG_DMA_CTL_READ)) {
>>> + return;
>>> + }
>>> +
>>> + while (s->dma_len > 0) {
>>> + len = s->dma_len;
>>> + ptr = dma_memory_map(s->dma_as, s->dma_addr, &len,
>>> + DMA_DIRECTION_FROM_DEVICE);
>>> + if (!ptr || !len) {
>>> + s->dma_ctl |= FW_CFG_DMA_CTL_ERROR;
>>> + return;
>>> + }
>>> +
>>> + for (i = 0; i < len; i++) {
>>> + ptr[i] = fw_cfg_read(s);
>>> + }
>>> +
>>> + s->dma_addr += i;
>>> + s->dma_len -= i;
>>> + dma_memory_unmap(s->dma_as, ptr, len,
>>> + DMA_DIRECTION_FROM_DEVICE, i);
>>> + }
>>> + s->dma_ctl = 0;
>>> +}
>>
>> On Aarch64 KVM, is this going to show the same cache coherence problems
>> as VGA memory access?
>>
>
> Does the guest (AAVMF) need to map all regions it DMAs to/from as
> noncacheable? If so, then yes. If not, then I don't think it should
> map fw-cfg DMA regions that way. fw-cfg is a paravirt device, so I
> don't think we should have to treat it like a real one.
I'd just point the address registers (or the address fields in the
descriptor structure) to a block of normal guest RAM, before flipping
the appropriate bit in the MMIO register that actually fires off the
transfer.
... Seems like that should work, then. Thanks!
Laszlo
