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: Alvise Rigo
Subject: Re: [Qemu-devel] [RFC 0/4] AMBA platform device passthrough
Date: Fri, 25 Apr 2014 11:17:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

Il 24/04/2014 02:16, Peter Crosthwaite ha scritto:
> 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.

Agreed.

Regards,
alvise

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