Re: [Qemu-devel] [5323] Implement an fd pool to get real AIO with posix-aio

[Gerd Hoffmann <kraxel@redhat.com>]

Anthony Liguori wrote:
> Gerd Hoffmann wrote:
>> Anthony Liguori wrote:
>>  
>>>> Are there plans to support vectored block requests with the thread pool
>>>> implementation?
>>>>         
>>> Yes, that's the primary reason for doing a new thread pool
>>> implementation.
>>>     
>>
>> Cool.
>>
>>  
>>> Of course, we need a zero-copy DMA API before such a
>>> thing would make sense.
>>>     
>>
>> Hmm, quick check of the IDE code indeed shows a copy happening there.
>> Why is it needed?  My xen disk backend doesn't copy data.  Does that
>> mean might have done something wrong?  Does the virtio backend copy data
>> too?
> 
> It does now, because the cost of splitting up the AIO request for each
> element of the scatter/gather list was considerably higher than the cost
> of copying the data to a linear buffer.

Ok, so virtio will likely stop doing that soon I guess?  With the aio
thread pool and even more with a vectored aio api the need for that
should go away ...

> You can only avoid doing a copy if you do something like phys_ram_base +
> PA.

I actually do this ...

void *xenner_mfn_to_ptr(xen_pfn_t pfn)
{
    ram_addr_t offset;

    offset = cpu_get_physical_page_desc(pfn << PAGE_SHIFT);
    return (void*)phys_ram_base + offset;
}

... which should keep working even in case there are holes in the guest
PA address space and thus guest_pa != phys_ram_base offset.

> From an architectural perspective, this is not ideal since it
> doesn't allow for things like IOMMU emulation.  What we need, is a
> zero-copy API at the PCI level.

Sure, for IDE+SCSI emulation.  For paravirtual drivers it shouldn't be
an issue.

cheers,
  Gerd