similar to: [RFC 00/13] virtio-iommu on non-devicetree platforms

On Tue, Dec 03, 2019 at 07:01:36PM -0800, Jacob Pan (Jun) wrote: > Hi Jean, > > Sorry for the delay, I was out last week. Comments inline below. > > On Mon, 25 Nov 2019 19:02:47 +0100 > Jean-Philippe Brucker <jean-philippe at linaro.org> wrote: > > > On Fri, Nov 22, 2019 at 04:01:02PM -0800, Jacob Pan (Jun) wrote: > > > > (1) ACPI has one table per

On Fri, Nov 22, 2019 at 11:49:47AM +0100, Jean-Philippe Brucker wrote: > I'm seeking feedback on multi-platform support for virtio-iommu. At the > moment only devicetree (DT) is supported and we don't have a pleasant > solution for other platforms. Once we figure out the topology > description, x86 support is trivial. > > Since the IOMMU manages memory accesses from

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.

Hi Eric, On Tue, Mar 03, 2020 at 11:19:20AM +0100, Auger Eric wrote: > Michael has pushed this solution (putting the "configuration in the PCI > config space"), I think for those main reasons: > - ACPI may not be supported on some archs/hyps But on those there is device-tree, right? > - the virtio-iommu is a PCIe device so binding should not need ACPI > description The

Hi Eric, On Tue, Mar 03, 2020 at 11:19:20AM +0100, Auger Eric wrote: > Michael has pushed this solution (putting the "configuration in the PCI > config space"), I think for those main reasons: > - ACPI may not be supported on some archs/hyps But on those there is device-tree, right? > - the virtio-iommu is a PCIe device so binding should not need ACPI > description The

On Tue, Mar 03, 2020 at 02:01:56PM +0100, Joerg Roedel wrote: > Hi Eric, > > On Tue, Mar 03, 2020 at 11:19:20AM +0100, Auger Eric wrote: > > Michael has pushed this solution (putting the "configuration in the PCI > > config space"), I think for those main reasons: > > - ACPI may not be supported on some archs/hyps > > But on those there is device-tree,

Hi Joerg, On 3/2/20 5:16 PM, Joerg Roedel wrote: > On Fri, Feb 28, 2020 at 06:25:36PM +0100, Jean-Philippe Brucker wrote: >> This solution isn't elegant nor foolproof, but is the best we can do at >> the moment and works with existing virtio-iommu implementations. It also >> enables an IOMMU for lightweight hypervisors that do not rely on >> firmware methods for

On 18/04/17 10:51, Tian, Kevin wrote: >> From: Jean-Philippe Brucker >> Sent: Saturday, April 8, 2017 3:18 AM >> >> Unlike other virtio devices, the virtio-iommu doesn't work independently, >> it is linked to other virtual or assigned devices. So before jumping into >> device operations, we need to define a way for the guest to discover the >> virtual

> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker at arm.com] > Sent: Wednesday, April 19, 2017 2:41 AM > > On 18/04/17 10:51, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Saturday, April 8, 2017 3:18 AM > >> > >> Unlike other virtio devices, the virtio-iommu doesn't work independently, > >> it is linked to

> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker at arm.com] > Sent: Wednesday, April 19, 2017 2:41 AM > > On 18/04/17 10:51, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Saturday, April 8, 2017 3:18 AM > >> > >> Unlike other virtio devices, the virtio-iommu doesn't work independently, > >> it is linked to

Hi, On 12/12/18 3:56 PM, Michael S. Tsirkin wrote: > On Fri, Dec 07, 2018 at 06:52:31PM +0000, Jean-Philippe Brucker wrote: >> Sorry for the delay, I wanted to do a little more performance analysis >> before continuing. >> >> On 27/11/2018 18:10, Michael S. Tsirkin wrote: >>> On Tue, Nov 27, 2018 at 05:55:20PM +0000, Jean-Philippe Brucker wrote:

Unlike other virtio devices, the virtio-iommu doesn't work independently, it is linked to other virtual or assigned devices. So before jumping into device operations, we need to define a way for the guest to discover the virtual IOMMU and the devices it translates. The host must describe the relation between IOMMU and devices to the guest using either device-tree or ACPI. The virtual IOMMU

On 2018-12-12 3:27 pm, Auger Eric wrote: > Hi, > > On 12/12/18 3:56 PM, Michael S. Tsirkin wrote: >> On Fri, Dec 07, 2018 at 06:52:31PM +0000, Jean-Philippe Brucker wrote: >>> Sorry for the delay, I wanted to do a little more performance analysis >>> before continuing. >>> >>> On 27/11/2018 18:10, Michael S. Tsirkin wrote: >>>> On

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > Unlike other virtio devices, the virtio-iommu doesn't work independently, > it is linked to other virtual or assigned devices. So before jumping into > device operations, we need to define a way for the guest to discover the > virtual IOMMU and the devices it translates. > > The host must

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > Unlike other virtio devices, the virtio-iommu doesn't work independently, > it is linked to other virtual or assigned devices. So before jumping into > device operations, we need to define a way for the guest to discover the > virtual IOMMU and the devices it translates. > > The host must

When virtio-iommu uses the PCI transport, IORT doesn't instantiate the device and doesn't create a fwnode. They will be created later by the PCI subsystem. Store the information needed to identify the IOMMU in iort_fwnode_list. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at arm.com> --- drivers/acpi/iort.c | 117 +++++++++++++++++++++++++++++++++++--------- 1 file

Sorry for the delay, I wanted to do a little more performance analysis before continuing. On 27/11/2018 18:10, Michael S. Tsirkin wrote: > On Tue, Nov 27, 2018 at 05:55:20PM +0000, Jean-Philippe Brucker wrote: >>>> + if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1) || >>>> + !virtio_has_feature(vdev, VIRTIO_IOMMU_F_MAP_UNMAP)) >>> >>> Why bother

On Tue, Nov 27, 2018 at 06:09:25PM +0100, Auger Eric wrote: > Hi Michael, > > On 11/27/18 5:53 PM, Michael S. Tsirkin wrote: > > On Thu, Nov 22, 2018 at 07:37:54PM +0000, Jean-Philippe Brucker wrote: > >> Implement the virtio-iommu driver, following specification v0.9 [1]. > >> > >> Since v4 [2] I fixed the issues reported by Eric, and added Reviewed-by

On Fri, Dec 07, 2018 at 06:52:31PM +0000, Jean-Philippe Brucker wrote: > Sorry for the delay, I wanted to do a little more performance analysis > before continuing. > > On 27/11/2018 18:10, Michael S. Tsirkin wrote: > > On Tue, Nov 27, 2018 at 05:55:20PM +0000, Jean-Philippe Brucker wrote: > >>>> + if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1) || >