[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(-)
>>
>
>
- [Qemu-devel] [RFC 0/4] AMBA platform device passthrough, Alvise Rigo, 2014/04/17
- [Qemu-devel] [RFC 1/4] Allocate non-RAM MemoryRegion from user pointer, Alvise Rigo, 2014/04/17
- [Qemu-devel] [RFC 2/4] Add EXEC_FLAG to VFIO DMA mappings, Alvise Rigo, 2014/04/17
- [Qemu-devel] [RFC 3/4] Add AMBA devices support to VFIO, Alvise Rigo, 2014/04/17
- [Qemu-devel] [RFC 4/4] MemoryRegion with EOI callbacks for VFIO Platform devices, Alvise Rigo, 2014/04/17
- Re: [Qemu-devel] [RFC 0/4] AMBA platform device passthrough, Eric Auger, 2014/04/23