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: Eric Auger
Subject: Re: [Qemu-devel] [RFC 0/4] AMBA platform device passthrough
Date: Wed, 23 Apr 2014 17:21:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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? 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]