Skip to contentSkip to conversation

KVM call agenda for 2013-06-25

DISCUSSION Michael S. Tsirkin 3 participants 4 messages Jun 20, 2013 – Jun 25, 2013 KVM

lore
Share & tools
lore
#0 lore raw

Please, send any topic that you are interested in covering.

Thanks, MST

Signature · 1 line
MST
#1 lore raw
Quoted 1 line · Michael S. Tsirkin

Please, send any topic that you are interested in covering.

VFIO with platform devices

Alex

#2 lore raw

Hello,

How can one follow those calls? We are especially interested in VFIO with platform/device tree based devices.

Quoted 12 lines · Alexander Graf
Quoted 1 line · Michael S. Tsirkin

Please, send any topic that you are interested in covering.

VFIO with platform devices

Alex

#3 lore raw
In reply to Alexander Graf
Quoted 6 lines · Alexander Graf
Quoted 1 line · Michael S. Tsirkin

Please, send any topic that you are interested in covering.

VFIO with platform devices

A few notes ahead of the discussion:

-problem we are trying to solve is:
1. how the kernel can expose device tree based platform devices to user space
2. how QEMU exposes these devices in virtual machines

-general
-this is not just a QEMU/KVM issue, we have other user space
drivers that should use the same framework (e.g. USDPAA)
-acpi/dsdt based device discovery is on the horizon, but this
should be treated separately
-we want the same linux drivers to be used in host and
guest...don't want 'paravirt' drivers in guest

-3 aspects to this

1. kernel side
-a device must be able to be unbound from the host
and bound to vfio
-vfio can determine the mappable register regions and
interrupts from the associated device tree node and expose these to user space...details TBD
-keep it simple: expose register regions and interrupts

2. user-space/QEMU - device tree

     -there is potentially a large variety of devices, the
      simplest are represented by a simple self-contained
      node, others get complicated and could have phandles to
      other nodes (e.g. etsec has phandle to phy node).  Some
      devices may need device tree tweaks.

     -think what we need is custom handling in QEMU for
      each type of device.  QEMU uses what the kernel 
      exposed via vfio to pass the device through and
     For example to pass through
      a SATA controller something like:

          -device platfom-vfio-sata,dev=/soc/sata@221000,bus=platform.0

     -the device specific support in QEMU knows how to
      create a device tree node for the given device type

     -it is up to user space to deal with device inter-
      relationships if they exist

     -SEC engine job ring example-- what we want ideally is a 
      Linux driver that can operate on plain job rings
      so we don't need the complexity of dealing with the
      main SEC node:

        [cut]
        crypto@300000 {
           compatible = "fsl,sec-v4.0";
           #address-cells = <0x1>;
           #size-cells = <0x1>;
           reg = <0x300000 0x10000>;
           ranges = <0x0 0x300000 0x10000>;
           interrupts = <0x5c 0x2 0x0 0x0>;

           jr@1000 {
              compatible = "fsl,sec-v4.0-job-ring";
              reg = <0x1000 0x1000>;
              interrupts = <0x58 0x2 0x0 0x0>;
           };

           jr@2000 {
              compatible = "fsl,sec-v4.0-job-ring";
              reg = <0x2000 0x1000>;
              interrupts = <0x59 0x2 0x0 0x0>;
           };
        [cut]

3. user-space/QEMU - dynamic interrupt allocation

-currently devices and interrupts on our system/platform
bus are statically allocated. We need a way to dynamically get devices added

-simple example would be adding a virtual UART via -device

-it would be nice to solve this generally for both
ARM and Power