search for: piommu

...one 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 means in the host-side pIOMMU driver needs to propagate all supported formats through VFIO to Qemu vIOMMU, meaning such format definitions need be consistently agreed across all those components. [...] > > 2. Sharing MMU page tables > -------------------------- > > The guest can share process page-tables...

...one 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 means in the host-side pIOMMU driver needs to propagate all supported formats through VFIO to Qemu vIOMMU, meaning such format definitions need be consistently agreed across all those components. [...] > > 2. Sharing MMU page tables > -------------------------- > > The guest can share process page-tables...

..., with less context switches to > the host and the possibility of in-kernel emulation. > > When designing it and writing the kvmtool device, I considered two main > scenarios, illustrated below. > > Scenario 1: a hardware device passed through twice via VFIO > > MEM____pIOMMU________PCI device________________________ > HARDWARE > | (2b) \ > ----------|-------------+-------------+------------------\------------- > | : KVM : \ > | :...

...ing to userspace for each request. The mainline kernel already implements vhost-net, vhost-scsi and vhost-vsock, and a lot of core code could be reused. Introducing vhost in a simplified scenario 1 (removed guest userspace pass-through, irrelevant to this example) gives us the following: MEM____pIOMMU________PCI device____________ HARDWARE | \ ----------|-------------+-------------+-----\-------------------------- | : KVM : \ pIOMMU drv : : \ KERN...

...s of three or more different IOMMU implementations in either userspace or kernel. Thanks > > When designing it and writing the kvmtool device, I considered two main > scenarios, illustrated below. > > Scenario 1: a hardware device passed through twice via VFIO > > MEM____pIOMMU________PCI device________________________ HARDWARE > | (2b) \ > ----------|-------------+-------------+------------------\------------- > | : KVM : \ > |...

...peration right? > > MAP/UNMAP and page-table sharing should have different ID spaces... > > I think it's simpler if we keep a single IOASID space per virtio-iommu > device, because the maximum number of address spaces (described by > ioasid_bits) might be a restriction of the pIOMMU. For page-table sharing > you still need to define which devices will share a page directory using > ATTACH requests, though that interface is not set in stone. got you. yes VM is supposed to consume less IOASIDs than physically available. It doesn?t hurt to have one IOASID space for both IO...

...peration right? > > MAP/UNMAP and page-table sharing should have different ID spaces... > > I think it's simpler if we keep a single IOASID space per virtio-iommu > device, because the maximum number of address spaces (described by > ioasid_bits) might be a restriction of the pIOMMU. For page-table sharing > you still need to define which devices will share a page directory using > ATTACH requests, though that interface is not set in stone. got you. yes VM is supposed to consume less IOASIDs than physically available. It doesn?t hurt to have one IOASID space for both IO...

...> field for this. We can add the same to the VIOT virtio-iommu nodes > > later, since the structures are extensible. > > > I think there the proximity domain is more for each assigned device > than vIOMMU. vIOMMU in the guest can have assigned devices belong to > different pIOMMU and proximity domains. If the guest owns the first > level page tables (gIOVA or SVA), we want to make sure page tables are > allocated from the close proximity domain. > > My understanding is virtio IOMMU supports both virtio devices and > assigned devices. we could care less about...

...d to be resolved >> by guest itself. Supporting PCI PRI is a separate problem, that will be implemented by extending the event queue proposed in v0.5. Once the guest bound the PASID table and created the page tables, it will start some DMA job in the device. If a page isn't mapped, the pIOMMU sends a PRI Request (a page fault) to its driver, which is relayed to userspace by VFIO, then to the guest via virtio-iommu. The guest handles the fault, then sends a PRI response on the virtio-iommu request queue, relayed to the pIOMMU driver via VFIO and the device retries the access. >>...

Hi Jean, On Tue Oct 24, 2017 at 10:28:59PM +0530, Linu Cherian wrote: > Hi Jean, > Thanks for your reply. > > On Tue Oct 24, 2017 at 09:37:12AM +0100, Jean-Philippe Brucker wrote: > > Hi Linu, > > > > On 24/10/17 07:27, Linu Cherian wrote: > > > Hi Jean, > > > > > > On Mon Oct 23, 2017 at 10:32:41AM +0100, Jean-Philippe Brucker wrote:

...It might be more efficient in some cases, with less context switches to the host and the possibility of in-kernel emulation. When designing it and writing the kvmtool device, I considered two main scenarios, illustrated below. Scenario 1: a hardware device passed through twice via VFIO MEM____pIOMMU________PCI device________________________ HARDWARE | (2b) \ ----------|-------------+-------------+------------------\------------- | : KVM : \ | : :...

...It might be more efficient in some cases, with less context switches to the host and the possibility of in-kernel emulation. When designing it and writing the kvmtool device, I considered two main scenarios, illustrated below. Scenario 1: a hardware device passed through twice via VFIO MEM____pIOMMU________PCI device________________________ HARDWARE | (2b) \ ----------|-------------+-------------+------------------\------------- | : KVM : \ | : :...

> 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

...by guest itself. > > Supporting PCI PRI is a separate problem, that will be implemented by > extending the event queue proposed in v0.5. Once the guest bound the PASID > table and created the page tables, it will start some DMA job in the > device. If a page isn't mapped, the pIOMMU sends a PRI Request (a page > fault) to its driver, which is relayed to userspace by VFIO, then to the > guest via virtio-iommu. The guest handles the fault, then sends a PRI > response on the virtio-iommu request queue, relayed to the pIOMMU driver > via VFIO and the device retries the...

...by guest itself. > > Supporting PCI PRI is a separate problem, that will be implemented by > extending the event queue proposed in v0.5. Once the guest bound the PASID > table and created the page tables, it will start some DMA job in the > device. If a page isn't mapped, the pIOMMU sends a PRI Request (a page > fault) to its driver, which is relayed to userspace by VFIO, then to the > guest via virtio-iommu. The guest handles the fault, then sends a PRI > response on the virtio-iommu request queue, relayed to the pIOMMU driver > via VFIO and the device retries the...

On Wed, Mar 04, 2020 at 07:48:54AM -0800, Jacob Pan wrote: > For emulated VT-d IOMMU, GIOVA can also be build as first level page > tables then pass to the host IOMMU to bind. There is no need to shadow > in this case, pIOMMU will do nested translation and walk guest page > tables. Right, but that requires hardware support. A pure software emulation of VT-d requires the full shadow of the guest io-page-table. > I thought we have the universal device properties to abstract DT and > ACPI (via _DSD). Is that an...

...address space ID is per operation right? > MAP/UNMAP and page-table sharing should have different ID spaces... I think it's simpler if we keep a single IOASID space per virtio-iommu device, because the maximum number of address spaces (described by ioasid_bits) might be a restriction of the pIOMMU. For page-table sharing you still need to define which devices will share a page directory using ATTACH requests, though that interface is not set in stone. >> device, it is created. 'device' is an identifier unique to the IOMMU. The >> host communicates unique device ID to the...

Hi Jean, Thanks for your reply. On Tue Oct 24, 2017 at 09:37:12AM +0100, Jean-Philippe Brucker wrote: > Hi Linu, > > On 24/10/17 07:27, Linu Cherian wrote: > > Hi Jean, > > > > On Mon Oct 23, 2017 at 10:32:41AM +0100, Jean-Philippe Brucker wrote: > >> This is version 0.5 of the virtio-iommu specification, the paravirtualized > >> IOMMU. This version

Hi Jean, Thanks for your reply. On Tue Oct 24, 2017 at 09:37:12AM +0100, Jean-Philippe Brucker wrote: > Hi Linu, > > On 24/10/17 07:27, Linu Cherian wrote: > > Hi Jean, > > > > On Mon Oct 23, 2017 at 10:32:41AM +0100, Jean-Philippe Brucker wrote: > >> This is version 0.5 of the virtio-iommu specification, the paravirtualized > >> IOMMU. This version