search for: attach_table

...F_NATIVE | F_FAULT). The > page table format is implicit, so the pg_format array can be empty (unless > the guest wants to query some specific property, e.g. number of levels > supported by the pIOMMU?). If the host answers with success, guest can > send its MMU page table details with ATTACH_TABLE and (F_NATIVE | > F_INDIRECT | F_FAULT) flags. > > F_FAULT means that the host communicates page requests from device to > the > guest, and the guest can handle them by mapping virtual address in the > fault to pages. It is only available with VIRTIO_IOMMU_F_FAULT_QUEUE (see >...

...F_NATIVE | F_FAULT). The > page table format is implicit, so the pg_format array can be empty (unless > the guest wants to query some specific property, e.g. number of levels > supported by the pIOMMU?). If the host answers with success, guest can > send its MMU page table details with ATTACH_TABLE and (F_NATIVE | > F_INDIRECT | F_FAULT) flags. > > F_FAULT means that the host communicates page requests from device to > the > guest, and the guest can handle them by mapping virtual address in the > fault to pages. It is only available with VIRTIO_IOMMU_F_FAULT_QUEUE (see >...

...VIRTIO_F_VERSION_1) || > >> + !virtio_has_feature(vdev, VIRTIO_IOMMU_F_MAP_UNMAP)) > > > > Why bother with a feature bit for this then btw? > > We'll need a new feature bit for sharing page tables with the hardware, > because they require different requests (attach_table/invalidate instead > of map/unmap.) A future device supporting page table sharing won't > necessarily need to support map/unmap. > > Thanks, > Jean I don't see virtio iommu being extended to support ARM specific requests. This just won't scale, too many different descri...

...!virtio_has_feature(vdev, VIRTIO_IOMMU_F_MAP_UNMAP)) > >>> > >>> Why bother with a feature bit for this then btw? > >> > >> We'll need a new feature bit for sharing page tables with the hardware, > >> because they require different requests (attach_table/invalidate instead > >> of map/unmap.) A future device supporting page table sharing won't > >> necessarily need to support map/unmap. > >> > > I don't see virtio iommu being extended to support ARM specific > > requests. This just won't scale, too...

...) || >>>> + !virtio_has_feature(vdev, VIRTIO_IOMMU_F_MAP_UNMAP)) >>> >>> Why bother with a feature bit for this then btw? >> >> We'll need a new feature bit for sharing page tables with the hardware, >> because they require different requests (attach_table/invalidate instead >> of map/unmap.) A future device supporting page table sharing won't >> necessarily need to support map/unmap. >> > I don't see virtio iommu being extended to support ARM specific > requests. This just won't scale, too many different > desc...

..._IOMMU_F_MAP_UNMAP)) >>>>>> >>>>>> Why bother with a feature bit for this then btw? >>>>> >>>>> We'll need a new feature bit for sharing page tables with the hardware, >>>>> because they require different requests (attach_table/invalidate instead >>>>> of map/unmap.) A future device supporting page table sharing won't >>>>> necessarily need to support map/unmap. >>>>> >>>> I don't see virtio iommu being extended to support ARM specific >>>> reque...

...feature(vdev, VIRTIO_IOMMU_F_MAP_UNMAP)) >>>>> >>>>> Why bother with a feature bit for this then btw? >>>> >>>> We'll need a new feature bit for sharing page tables with the hardware, >>>> because they require different requests (attach_table/invalidate instead >>>> of map/unmap.) A future device supporting page table sharing won't >>>> necessarily need to support map/unmap. >>>> >>> I don't see virtio iommu being extended to support ARM specific >>> requests. This just won...

...if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1) || >> + !virtio_has_feature(vdev, VIRTIO_IOMMU_F_MAP_UNMAP)) > > Why bother with a feature bit for this then btw? We'll need a new feature bit for sharing page tables with the hardware, because they require different requests (attach_table/invalidate instead of map/unmap.) A future device supporting page table sharing won't necessarily need to support map/unmap. Thanks, Jean

...mappings, hidden behind the IOMMU API. This 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.) (4) If the driver is able to use this format, it sends the ATTACH_TABLE request. VIRTIO_IOMMU_T_ATTACH_TABLE struct virtio_iommu_req_attach_table { le32 address_space; le32 flags; le64 table; le32 nr_contexts; /* Page-table format description */ le32 model; u8 config[64] }; 'table' is a pointer to the page directory. 'nr_con...

On Thu, Nov 22, 2018 at 07:37:59PM +0000, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio transport without emulating page > tables. This implementation handles ATTACH, DETACH, MAP and UNMAP > requests. > > The bulk of the code transforms calls coming from the IOMMU API into >

On Thu, Nov 22, 2018 at 07:37:59PM +0000, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio transport without emulating page > tables. This implementation handles ATTACH, DETACH, MAP and UNMAP > requests. > > The bulk of the code transforms calls coming from the IOMMU API into >

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