qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC 0/4] AMBA platform device passthrough
Date: Thu, 24 Apr 2014 10:16:00 +1000

On Thu, Apr 24, 2014 at 1:21 AM, Eric Auger <address@hidden> 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?
>

I think its probably best taken as a squash to your series.

Regards,
Peter

> 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? Is it something that can be
> generalized to other devices?
>
> 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.
>
> 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(-)
>>
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]