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

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



On Thu, 2012-05-10 at 11:17 +0100, George Dunlap wrote:
> On Wed, May 9, 2012 at 2:45 PM, George Dunlap
> <george.dunlap@xxxxxxxxxxxxx> wrote:
> > On 09/05/12 12:59, Ian Campbell wrote:
> >>
> >> 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.
> 
> And, I realize that at some point all of the deadlines are going to be
> arbitrary; but I have always felt this is important enough to get an
> exception.  I consider having to muck about with sysfs to be basically
> a UI bug that really needs fixing.  I have a lot of other things that
> I would like to get done for the 4.2 release; but I thought this was
> important enough to get priority (above the PoD patch series, for
> instance).  NB I'm not saying that you should accept it because I
> worked on it; I only bring it up to demonstrate how important I think
> the feature is.

OK, given that the code is basically self contained and shouldn't effect
anything unless a user "opts-in" to using it I think you've convinced
me. Lets take this (I'll review the actual patches shortly).

BTW, IMHO it is preferable for actual deployments to use the kernel
command line options to hide devices rather than either this feature or
sysfs.

Fully hiding the device from dom0 drivers generally seems like it is
always better. That way the first driver to try and touch the hardware
is the one inside the domU. This avoids issues with dom0 drivers setting
stuff up but not tearing it down in a way that domU can cope with and
makes the use of hardware which doesn't support FLR more reliable etc.

Ian.



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


 


Rackspace

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