[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] vfio for platform devices - 9/5/2012 - minutes
From: |
Sethi Varun-B16395 |
Subject: |
Re: [Qemu-devel] vfio for platform devices - 9/5/2012 - minutes |
Date: |
Fri, 6 Sep 2013 16:56:10 +0000 |
I have a query about the ARM SMMU driver. In the ARM smmu driver I see, that
bus notifiers are registered for both amba and platform bus. Amba is the I/O
interconnect, right? Why is bus notifier required for the amba bus?
-Varun
> -----Original Message-----
> From: Yoder Stuart-B08248
> Sent: Thursday, September 05, 2013 11:21 PM
> To: Wood Scott-B07421; Sethi Varun-B16395; Bhushan Bharat-R65777; 'Peter
> Maydell'; 'Santosh Shukla'; 'Alex Williamson'; 'Alexander Graf';
> 'Antonios Motakis'; 'Christoffer Dall'; 'address@hidden'
> Cc: address@hidden; address@hidden; qemu-
> address@hidden
> Subject: vfio for platform devices - 9/5/2012 - minutes
>
> We had a call with those interested and/or working on vfio for platform
> devices.
>
> Participants: Scott Wood, Varun Sethi, Bharat Bhushan, Peter Maydell,
> Santosh Shukla, Alex Williamson, Alexander Graf,
> Antonios Motakis, Christoffer Dall, Kim Phillips,
> Stuart Yoder
>
> Several aspects to vfio for platform devices:
>
> 1. IOMMU groups
>
> -iommu driver needs to register a bus notifier for the platform bus
> and create groups for relevant platform devices -Antonios is looking
> at this for several ARM IOMMUs -PAMU (Freescale) driver already does
> this
>
> 2. unbinding device from host
>
> PCI:
> echo 0000:06:0d.0 > /sys/bus/pci/devices/0000:06:0d.0/driver/unbind
> Platform:
> echo ffe101300.dma >
> /sys/bus/platform/devices/ffe101300.dma/driver/unbind
>
> -don't believe there are issues or work to do here
>
> 3. binding device to vfio-platform driver
>
> PCI:
> echo 1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id
>
> -this is probably the least understood issue-- platform drivers
> register themselves with the bus for a specific "name"
> string. That is matched with device tree "compatible" strings
> later to bind a device to a driver
> -we want is to have the vfio-platform driver to dynamically bind
> to a variety of platform devices previously unknown to
> vfio-platform
> -ideally unbinding and binding could be an atomic operation -Alex W
> pointed out that x86 could leverage this work so
> keep that in mind in what we design
> -Kim Phillips (Linaro) will start working on this
>
> 4. vfio kernel interface
>
> -exposes regions and interrupts to user space via FDs -there are 'info'
> ioctls that allow getting info about
> regions/interrupts such as size and type of interrupt -there is a
> proposed extension to the 'info' ioctls that
> provides device tree paths, allowing user space to coorelate
> resources with the device tree
> (https://lists.cs.columbia.edu/pipermail/kvmarm/2013-July/006237.html)
>
> 5. QEMU
> -some key tasks
> -interacts with vfio kernel interface
> -registers memslots
> -needs to dynamically get device hooked up to VM's
> platform bus, including IRQs
> -needs to generate device tree node
> -a key point: we don't believe that platform device passthru
> in QEMU can be solved in a completely generic way. There will
> need to be device specific code for each device type being passed
> through...to do things like generate device tree nodes -in general we
> expect a relatively small number of device types
> to be passed through to VMs
> -Alex Graf is working on dynamic creation of platform devices
> for the PPC e500 paravirt machine
> -see: http://lists.nongnu.org/archive/html/qemu-devel/2013-
> 07/msg03614.html
> -first step is dynamically generating a virtual UART -that sets the
> stage to create and create vfio devices backed
> by real hardware
>
> There is a session at Linux Plumbers in a couple of weeks and further
> discussions will happen there.
>
> Regards,
> Stuart