[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111216145353.GA29877@amd.com>
Date: Fri, 16 Dec 2011 15:53:53 +0100
From: Joerg Roedel <joerg.roedel@....com>
To: Alex Williamson <alex.williamson@...hat.com>
CC: David Gibson <david@...son.dropbear.id.au>, <aik@...abs.ru>,
<benh@...nel.crashing.org>, <dwmw2@...radead.org>,
<chrisw@...hat.com>, <agraf@...e.de>, <scottwood@...escale.com>,
<B08248@...escale.com>, <rusty@...tcorp.com.au>,
<iommu@...ts.linux-foundation.org>, <qemu-devel@...gnu.org>,
<linux-kernel@...r.kernel.org>, <joro@...tes.org>
Subject: Re: [RFC] Device isolation infrastructure v2
On Thu, Dec 15, 2011 at 11:05:07AM -0700, Alex Williamson wrote:
> Starting with it in the core and hand waving some future use that we
> don't plan to implement right now seems like the wrong direction.
I agree with Alex. First of all, I havn't seen any real vfio problem
that can't be solved with the current approach, and it has the great
advantage of simplicity. It doesn't require a re-implementation of the
driver-core based on groups. I agree that we need some improvements to
Alex' code for the dma-api layer to solve the problem with broken devices
using the wrong requestor-id. But that can be done incrementally with
the current (current == in the iommu-tree) approach implemented by Alex.
I also think that all this does not belong into the driver core for two
reasons:
1) The information for building the device groups is provided
by the iommu-layer
2) The group information is provided to vfio by the iommu-api
This makes the iommu-layer the logical point to place the grouping code.
There are some sources outside of the iommu-layer that may influence
grouping (like pci-quirks), but most of the job is done by the
iommu-drivers.
Thanks,
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
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