Re: [Qemu-devel] [RFC 0/4] AMBA platform device passthrough

[Alvise Rigo]

On 23/04/2014 17:21, Eric Auger wrote:
> On 04/17/2014 07:29 PM, Alvise Rigo wrote:
>> These patches were born after trying the current work on device
>> passthrough (see thread "[Qemu-devel] [RFC v2 0/6] KVM platform device
>> passthrough") with a DMA330 and FastModels.  This work want to be the
>> starting point for dicussion on some aspects related to the next VFIO
>> platform development:
>>
>> - [PATCH 1/4] Add a way to allocate memory region from a user pointer
>>   for devices, and not exclusively for RAM. This is useful to exclude
>>   the devices bound to VFIO from being DMA mapped by the VFIO memory
>>   listener.
>>
>> - [PATCH 2/4] Addition of the exec flag to the DMA mappings. This is
>>   mandatory only for the ARM SMMU: in its next version VFIO will be able
>>   to tell if the flag is supported.
>>
>> - [PATCH 3/4] Possibility to bind a wider class of devices. In
>>   particular the patch proposes a solution to enhance a bit the device
>>   tree nodes generation, allowing to specify more than one compatibility
>>   property (handy for AMBA devices). 
> 
> I Alvise,
> 
> This improvement was indeed needed. Do you want me to integrate that one
> on next RFC version or do you maintain it on your side?
> 
> This was required by the DMA330
>>   that needs “arm,pl330”,”arm,primecell” as compatibility string,
>>   together with a clock source defined in the device tree. In the future
>>   VFIO will be able to tell if we are dealing with an AMBA device; 
> 
> Any idea of how you want to achieve this?

The VFIO API at some point will be able to tell if we are dealing with
an AMBA device. In general these devices still need some work from the
VFIO API side to be properly supported.

Is it something that can be
> generalized to other devices?

Yes, it will be a matter of checking the flags returned by the VFIO API.

> 
> before
>>   that, we have to rely on the compatibility string to state that.
> 
>>
>> - [PATCH 4/4] Another approach to handle the EOI, starting from the
>>   assumption that we know in advance the location of the interrupt clear
>>   register of the device. Testing the reference patches I was noticing
>>   that the EOI mechanism was disabling the interrupt three times,
>>   because the kernel driver was reading some registers in the timer
>>   window before actually clearing the interrupt. 
> 
> 
> can you elaborate on the last sentence and especially "EOI mechanism was
> disabling the interrupt 3 times". I do not get what you mean here.

I should have said that after clearing the interrupt, there are two more
accesses in the timer window that check for a pending interrupt.
More on this in the [RFC 4/4] thread.

Best regards,
alvise

> 
> Best Regards
> 
> Eric
> 
>> This is of course
>>   another workaround and not the definitive solution until we can rely
>>   on a proper callback from the VGIC (something that we will see in a
>>   future version of VFIO for platform devices).
>>
>> These patches are based on the QEMU branch mentioned in the original
>> thread ("[Qemu-devel] [RFC v2 0/6] KVM platform device passthrough").
>>
>> Alvise Rigo (4):
>>   Allocate non-RAM MemoryRegion from user pointer
>>   Add EXEC_FLAG to VFIO DMA mappings
>>   Add AMBA devices support to VFIO
>>   MemoryRegion with EOI callbacks for VFIO Platform devices
>>
>>  exec.c                     |   2 +-
>>  hw/arm/virt.c              |  39 +++++++++--
>>  hw/vfio/common.c           |   3 +
>>  hw/vfio/platform.c         | 158 
>> ++++++++++++++++++++++++++++++++++++++++++---
>>  include/exec/memory.h      |  16 +++++
>>  linux-headers/linux/vfio.h |   1 +
>>  memory.c                   |  14 ++++
>>  memory_mapping.c           |   2 +-
>>  8 files changed, 220 insertions(+), 15 deletions(-)
>>
>