search for: pviommu

...scribe an SMMU\n", type); return false; @@ -1062,6 +1065,48 @@ static bool __init arm_smmu_is_coherent(struct acpi_iort_node *node) return smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK; } +static int __init paravirt_count_resources(struct acpi_iort_node *node) +{ + struct acpi_iort_pviommu *pviommu; + + pviommu = (struct acpi_iort_pviommu *)node->node_data; + + /* Mem + IRQs */ + return 1 + pviommu->interrupt_count; +} + +static void __init paravirt_init_resources(struct resource *res, + struct acpi_iort_node *node) +{ + int i; + int num_res = 0; + int hw_irq, trigger; +...

...of in-kernel emulation. > > I like the idea. Consider the complexity of IOMMU hardware. I believe we > don't want to have and fight for bugs of three or more different IOMMU > implementations in either userspace or kernel. > Though there are definitely positive things around pvIOMMU approach, it also has some limitations: - Existing IOMMU implementations have been in old distros for quite some time, while pvIOMMU driver will only land in future distros. Doing pvIOMMU only means we completely drop support of old distros in VM; - Similar situation on supporting other guest OSe...

...of in-kernel emulation. > > I like the idea. Consider the complexity of IOMMU hardware. I believe we > don't want to have and fight for bugs of three or more different IOMMU > implementations in either userspace or kernel. > Though there are definitely positive things around pvIOMMU approach, it also has some limitations: - Existing IOMMU implementations have been in old distros for quite some time, while pvIOMMU driver will only land in future distros. Doing pvIOMMU only means we completely drop support of old distros in VM; - Similar situation on supporting other guest OSe...

...requires that the page-table code is reasonably > abstracted from the architecture, as is done with drivers/iommu/io-pgtable > (an x86 guest could use any format implement by io-pgtable for example.) So essentially you need modify all existing IOMMU drivers to support page table sharing in pvIOMMU. After abstraction is done the core pvIOMMU files can be kept vendor agnostic. But if we talk about the whole pvIOMMU module, it actually includes vendor specific logic thus unlike typical para-virtualized virtio drivers being completely vendor agnostic. Is this understanding accurate? It also...

...requires that the page-table code is reasonably > abstracted from the architecture, as is done with drivers/iommu/io-pgtable > (an x86 guest could use any format implement by io-pgtable for example.) So essentially you need modify all existing IOMMU drivers to support page table sharing in pvIOMMU. After abstraction is done the core pvIOMMU files can be kept vendor agnostic. But if we talk about the whole pvIOMMU module, it actually includes vendor specific logic thus unlike typical para-virtualized virtio drivers being completely vendor agnostic. Is this understanding accurate? It also...

Implement the virtio-iommu driver following version 0.5 of the specification [1]. Previous version of this code was sent back in April [2], implementing the first public RFC. Since then there has been lots of progress and discussion on the specification side, and I think the driver is in a good shape now. The reason patches 1-3 are only RFC is that I'm waiting on feedback from the Virtio TC

Implement the virtio-iommu driver following version 0.5 of the specification [1]. Previous version of this code was sent back in April [2], implementing the first public RFC. Since then there has been lots of progress and discussion on the specification side, and I think the driver is in a good shape now. The reason patches 1-3 are only RFC is that I'm waiting on feedback from the Virtio TC

...ma_ops properly. >> >> Thanks, >> Jean > > OK so IIUC you are looking into Christoph's suggestions to fix that up? Eventually yes. I'll give it a try next year, once the dma-iommu changes are on the list. It's not a priority for me, given that x86 already has a pvIOMMU with VT-d, and that Arm still needs one. It shouldn't block this series. > There's still a bit of time left before the merge window, > maybe you can make above changes. I'll wait to see if Joerg has other concerns about the design or the code, and resend in January. I think that...

...hem > itself. I guess that the host could find out the DMA mask of devices one > way or another, but it is tricky to enforce, so I didn't make this a hard > requirement. Although I should probably add a few words about it. If there is no such communication on bare metal, then same for pvIOMMU. > > > [...] > >> 1. Attach device > >> ---------------- > >> > >> struct virtio_iommu_req_attach { > >> le32 address_space; > >> le32 device; > >> le32 flags/reserved; > >> }; > >> > >> Atta...

...hem > itself. I guess that the host could find out the DMA mask of devices one > way or another, but it is tricky to enforce, so I didn't make this a hard > requirement. Although I should probably add a few words about it. If there is no such communication on bare metal, then same for pvIOMMU. > > > [...] > >> 1. Attach device > >> ---------------- > >> > >> struct virtio_iommu_req_attach { > >> le32 address_space; > >> le32 device; > >> le32 flags/reserved; > >> }; > >> > >> Atta...

Hi Joerg, On 12/12/2018 10:35, Joerg Roedel wrote: > Hi, > > to make progress on this, we should first agree on the protocol used > between guest and host. I have a few points to discuss on the protocol > first. > > On Tue, Dec 11, 2018 at 06:20:57PM +0000, Jean-Philippe Brucker wrote: >> [1] Virtio-iommu specification v0.9, sources and pdf >>????

Hi Joerg, On 12/12/2018 10:35, Joerg Roedel wrote: > Hi, > > to make progress on this, we should first agree on the protocol used > between guest and host. I have a few points to discuss on the protocol > first. > > On Tue, Dec 11, 2018 at 06:20:57PM +0000, Jean-Philippe Brucker wrote: >> [1] Virtio-iommu specification v0.9, sources and pdf >>????

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > [...] > II. Feature bits > ================ > > VIRTIO_IOMMU_F_INPUT_RANGE (0) > Available range of virtual addresses is described in input_range Usually only the maximum supported address bits are important. Curious do you see such situation where low end of the address space is not usable

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > [...] > II. Feature bits > ================ > > VIRTIO_IOMMU_F_INPUT_RANGE (0) > Available range of virtual addresses is described in input_range Usually only the maximum supported address bits are important. Curious do you see such situation where low end of the address space is not usable

This is the initial proposal for a paravirtualized IOMMU device using virtio transport. It contains a description of the device, a Linux driver, and a toy implementation in kvmtool. With this prototype, you can translate DMA to guest memory from emulated (virtio), or passed-through (VFIO) devices. In its simplest form, implemented here, the device handles map/unmap requests from the guest. Future

This is the initial proposal for a paravirtualized IOMMU device using virtio transport. It contains a description of the device, a Linux driver, and a toy implementation in kvmtool. With this prototype, you can translate DMA to guest memory from emulated (virtio), or passed-through (VFIO) devices. In its simplest form, implemented here, the device handles map/unmap requests from the guest. Future