similar to: [RFC] virtio-iommu version 0.4

> From: Jean-Philippe Brucker > Sent: Wednesday, September 6, 2017 7:55 PM > > Hi Kevin, > > On 28/08/17 08:39, Tian, Kevin wrote: > > Here comes some comments: > > > > 1.1 Motivation > > > > You describe I/O page faults handling as future work. Seems you > considered > > only recoverable fault (since "aka. PCI PRI" being used).

Hi Kevin, Thanks for the comments On 19/03/18 10:03, Tian, Kevin wrote: > BYPASS feature bit is not covered in "2.3.1/2.3.2/2.3.3"". Is it > intended? In my opinion BYPASS is a bit different from the other features: while the others are needed for correctness, this one is optional and even if the guest supports BYPASS, it should be allowed not to accept it. For security

Hi Kevin, Thanks for the comments On 19/03/18 10:03, Tian, Kevin wrote: > BYPASS feature bit is not covered in "2.3.1/2.3.2/2.3.3"". Is it > intended? In my opinion BYPASS is a bit different from the other features: while the others are needed for correctness, this one is optional and even if the guest supports BYPASS, it should be allowed not to accept it. For security

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > Here I propose a few ideas for extensions and optimizations. This is all > very exploratory, feel free to correct mistakes and suggest more things. [...] > > II. Page table sharing > ====================== > > 1. Sharing IOMMU page tables > ---------------------------- > >

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > Here I propose a few ideas for extensions and optimizations. This is all > very exploratory, feel free to correct mistakes and suggest more things. [...] > > II. Page table sharing > ====================== > > 1. Sharing IOMMU page tables > ---------------------------- > >

> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker at arm.com] > Sent: Wednesday, February 14, 2018 10:54 PM > > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio-mmio transport without > emulating > page tables. This implementation handles ATTACH, DETACH, MAP and > UNMAP > requests. > > The

> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker at arm.com] > Sent: Wednesday, February 14, 2018 10:54 PM > > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio-mmio transport without > emulating > page tables. This implementation handles ATTACH, DETACH, MAP and > UNMAP > requests. > > 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

Please find version 0.6 of the virtio-iommu specification at the following locations. Document: http://jpbrucker.net/virtio-iommu/spec/virtio-iommu.pdf http://jpbrucker.net/virtio-iommu/spec/virtio-iommu.html Sources: git://linux-arm.org/virtio-iommu.git viommu/v0.6 I didn't receive any comment for v0.5 [1], so this update is fairly light: * Changed range definition in map and

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:

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 addresses feedback from v0.4 and adds an event virtqueue. > Please find the specification, LaTeX sources and pdf, at: > git://linux-arm.org/virtio-iommu.git viommu/v0.5 >

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

On Mon, Dec 24, 2018 at 11:43:31AM +0800, Jason Wang wrote: > > On 2018/12/14 ??9:20, Michael S. Tsirkin wrote: > > On Fri, Dec 14, 2018 at 10:43:03AM +0800, Jason Wang wrote: > > > On 2018/12/13 ??10:31, Michael S. Tsirkin wrote: > > > > > Just to make sure I understand this. It looks to me we should: > > > > > > > > > > - allow

On Mon, Dec 24, 2018 at 11:43:31AM +0800, Jason Wang wrote: > > On 2018/12/14 ??9:20, Michael S. Tsirkin wrote: > > On Fri, Dec 14, 2018 at 10:43:03AM +0800, Jason Wang wrote: > > > On 2018/12/13 ??10:31, Michael S. Tsirkin wrote: > > > > > Just to make sure I understand this. It looks to me we should: > > > > > > > > > > - allow

On 2020/2/5 ??10:05, Tiwei Bie wrote: > On Tue, Feb 04, 2020 at 02:46:16PM +0800, Jason Wang wrote: >> On 2020/2/4 ??2:01, Michael S. Tsirkin wrote: >>> On Tue, Feb 04, 2020 at 11:30:11AM +0800, Jason Wang wrote: >>>> 5) generate diffs of memory table and using IOMMU API to setup the dma >>>> mapping in this method >>> Frankly I think that's a

On 2020/2/5 ??10:05, Tiwei Bie wrote: > On Tue, Feb 04, 2020 at 02:46:16PM +0800, Jason Wang wrote: >> On 2020/2/4 ??2:01, Michael S. Tsirkin wrote: >>> On Tue, Feb 04, 2020 at 11:30:11AM +0800, Jason Wang wrote: >>>> 5) generate diffs of memory table and using IOMMU API to setup the dma >>>> mapping in this method >>> Frankly I think that's a

This patch maps RMRR in intel_iommu_add_device() if the device has RMRR; move domain_context_mapping() to be in front of list_move() in reassign_device_ownership(). Currently, hypervisor sets up devices and RMRR for dom0, and dom0 also adds devices for itself via hypercall. This is obviously duplicate. In order to allow old dom0 kernels to work with iommu-capable platforms, maybe it cannot be

On Tue, Dec 25, 2018 at 05:43:25PM +0800, Jason Wang wrote: > > On 2018/12/25 ??1:41, Michael S. Tsirkin wrote: > > On Mon, Dec 24, 2018 at 11:43:31AM +0800, Jason Wang wrote: > > > On 2018/12/14 ??9:20, Michael S. Tsirkin wrote: > > > > On Fri, Dec 14, 2018 at 10:43:03AM +0800, Jason Wang wrote: > > > > > On 2018/12/13 ??10:31, Michael S. Tsirkin