[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111208001645.GJ2395@x200.localdomain>
Date: Wed, 7 Dec 2011 16:16:45 -0800
From: Chris Wright <chrisw@...hat.com>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Alex Williamson <alex.williamson@...hat.com>,
David Gibson <dwg@....ibm.com>, joerg.roedel@....com,
dwmw2@...radead.org, iommu@...ts.linux-foundation.org,
aik@....ibm.com, linux-kernel@...r.kernel.org, chrisw@...hat.com,
agraf@...e.de, scottwood@...escale.com, B08248@...escale.com
Subject: Re: RFC: Device isolation infrastructure
* Benjamin Herrenschmidt (benh@...nel.crashing.org) wrote:
> After much thinking, I believe that the driver ownership model is the
> right one. However, we could still use the work David did here. IE. I
> _do_ think that exposing groups as the individual unit of ownership to
> user space is the right thing to do.
OK, I think I agree at least w/ the ownership model...
> That means that instead of that current detached flag alone, what we
> could do instead is have an in-kernel mechanism to request isolation
> which works by having the isolation group kernel code perform:
>
> - Rename the detached flag to "exclusive". This flag prevents automatic
> & user driven attachment of a driver by the generic code. Set that flag
> on all devices in the group (need a hook for hotplug).
>
> - Detach existing drivers.
>
> - Once everything is detached, attach the requested client driver (vfio
> being the one we initially provide, maybe uio could use that framework
> as well). This can be done using an explicit in-kernel attach API that
> can be used even when the exclusive flag is set.
Since users will want to drive devices, not groups, how would you
enumerate and expose devices here if the user visible construct exposed
is groups?
thanks,
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists