Re: [Xen-devel] [PATCH 0 of 4] Add commands to automatically prep devices for pass-through

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-05-09 at 12:03 +0100, George Dunlap wrote:
> On 09/05/12 11:49, Ian Campbell wrote:
> > On Wed, 2012-05-09 at 11:28 +0100, George Dunlap wrote:
> >> The current method for passing through devices requires users to
> >> either modify cryptic Linux boot parameters and reboot, or do a lot of
> >> manual reads and writes into sysfs nodes.
> >>
> >> This set of patches introduces commands to make this easier.
> > Is this intended for 4.2 or an RFC for 4.3?
> Well, I would really like it to go in to 4.2 -- it's been on my to-do 
> list for a month at least, and it will make doing pci pass-through, and 
> thus driver domains, a lot more straightforward.

Right, however it is strictly speaking a new feature which is not
mentioned on the TODO list and has not previously been posted (AFAIK,
please correct me if not) and we are currently supposed to be in feature
freeze (and have been for several weeks, if not a month).

IIRC this functionality was mooted when the pci permissive patch was
being done as something which would be a 4.3 feature.

We need to decide if we want to make an exception for this new feature
or not. Although I'm sure this feature is very nice and handy, we've
lived without it for years and people seem to be able to use the
existing scheme.

Ian.

> 
>   -George
> 
> 
> >
> >>    It expands
> >> on the concept of "assignable" (from the list_assignable_devices command).
> >>
> >> The new xl commands are:
> >>
> >> pci_assignable_add: Make a device assignable to guests.  This involves
> >> unbinding the device from its old driver, creating a slot for it in
> >> pciback (if necessary), and binding it to pciback.
> >>
> >> pci_assignable_list: List devices assignable to guests.  Just renamed
> >> from pci_list_assignable.
> >>
> >> pci_assignable_remove: Make the device no longer assignable to guests.
> >> This involves unbinding the device from pciback and removing the slot.  It
> >> optionally involves rebinding the device to the driver from which we stole
> >> it.
> >>
> >> Signed-off-by: George Dunlap<george.dunlap@xxxxxxxxxxxxx>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxx
> >> http://lists.xen.org/xen-devel
> >
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel