[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [rfc 0/8] xen-qemu: multi-function VT-d device pass-through



This series of patches cleans up various aspects of the PCI pass-through
code. This is working towards multi-function pass-through devices in
guests.  But most of these changes are useful in their own right, so I am
posting this batch without the rest of the multi-function changes.

This series of patches extends VT-d pass-through to allow multi-function
devices to appear in guests as multi-function devices.

The interface for this is a new extension to BDF notation that
can be used in configuration files for boot-time (static) assignment
and on the xm command like with pci-attach and pci-detach for hot-plug
and hot-unplug respectively.

If the existing BDF notation, which only specifies a single function, is
used then the existing single-function pass-through scheme is used.
That is, when a function is passed-through its will appear as function zero
of a vslot in the guest.

For example, the following physical to virtual mapping may occur. The
critical part is the treatment of the function numbers which will always be
consistent. That is, the virtual function number is always zero.

  Physical   | Virtual
  -----------+--------
  00:1d.0    | 00:06.0
  00:1d.1    | 00:07.0
  00:1d.7    | 00:08.0

If the new extensions to BDF notation are used, thereby specifying multiple
functions of a device, then a multi-function scheme is used. Two
such schemes are proposed:

1. Identity mapping, whereby physical function numbers are
   identity mapped into virtual functions.

   For example the following physical to virtual mapping may occur. Again,
   the treatment of the function numbers is critical and will always be
   consistent. That is it is the virtual function number is always the same
   as the physical function number. It is also important that both the
   physical and virtual device numbers are the same.

     Physical   | Virtual
     -----------+--------
     00:1d.0    | 00:07.0
     00:1d.1    | 00:07.1
     00:1d.7    | 00:07.7

2. Least mapping, whereby the lowest available virtual function is used.
   The example above would become:

     Physical   | Virtual
     -----------+--------
     00:1d.0    | 00:07.0
     00:1d.1    | 00:07.1
     00:1d.7    | 00:07.2

  Unlike identity mapping, this scheme is dependant on the order
  that functions are supplied. So if the order in the above
  example was reversed, then the result would be:

     Physical   | Virtual
     -----------+--------
     00:1d.7    | 00:07.0
     00:1d.1    | 00:07.1
     00:1d.0    | 00:07.1

  As physical function 0 need not be present, this scheme allows multiple
  virtual multi-function devices to be formed from functions of the same
  physical multi-function device.

  It is not known if this scheme violates hardware restrictions.

  This scheme is activated by applying the last patch in this series.
  There is no mechanism to switch schemes at this time.

  Least mapping was proposed by Masaki Kanno.

The above multi-function mappings will occur when the following extension to
the BDF notation is used. In the case of unplug the VSLOT and OPT must be
omitted.

  Existing: SEQ:BUS:DEV.FUNC[@VSLOT][,OPT...]
  New:      SEQ:BUS:DEV.FUNC0-FUNCN[@VSLOT][,OPT...]
            SEQ:BUS:DEV.FUNC0,FUNCM,FUNCN[@VSLOT][,OPT...]
            SEQ:BUS:DEV.*[@VSLOT][,OPT...]

  This notation is expanded into more conventional parameters
  which are passed to qemu-xen.

  E.g:
       0000:00:1d.0-2 becomes:
         0000:00:1d.0
         0000:00:1d.1
         0000:00:1d.2

       0000:00:1d.0,3,5,7 becomes:
         0000:00:0d.0
         0000:00:0d.3
         0000:00:0d.5
         0000:00:0d.7

       For a device that has functions 0, 1, 2, 3, 5 and 7,
       0000:00:1d.* becomes:
         0000:00:1d.00
         0000:00:1d.01
         0000:00:1d.02
         0000:00:1d.03
         0000:00:1d.05
         0000:00:1d.07

Limitation:

* This scheme does not allow for the physical and virtual function
  to be specified..

Bugs:

* Suspended domains with PCI pass-through devices may not
  be restored correctly because the vslot field is no
  longer honoured after these patches. This needs
  further investigation.

I will post a document that includes a fuller description of this
code as a follow-up.

This patch series applies against:

    http://xenbits.xensource.com/git-http/staging/qemu-xen-unstable.git/

    commit e0bb6b8df60863bca0163a1688baf4854e931e55
    Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Date:   Mon Jun 8 17:45:42 2009 +0100
    Subject: stdvga + videoram config option

Please apply the patches in order, many of the patches in
this series depend on previous patches in the series to
function correctly.

There are both xen and xen-qemu patch series relating to this change.
Where they depend on each other this is noted in the patch's comment.
Only applying one series will break pass-through.

I will be taking a holiday from the 24th June - 8th July.
I will not be able to make any fixes or answer email during that time.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.