search for: mem_t_direct

Displaying 3 results from an estimated 3 matches for "mem_t_direct".

2018 Mar 21
4
[PATCH 1/4] iommu: Add virtio-iommu driver
> 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
2018 Mar 21
4
[PATCH 1/4] iommu: Add virtio-iommu driver
> 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
2018 Mar 23
0
[PATCH 1/4] iommu: Add virtio-iommu driver
...both stage-1 and stage-2, while host kernel is only responsible for stage-2: 1) if we expect to keep same isolation policy (i.e. host MSI fully managed by host kernel), then an identity mapping for host-reported MSI range is expected in stage-1. In such case we need a new type VIRTIO_IOMMU_RESV_ MEM_T_DIRECT to teach guest setup identity mapping. it should be the right thing to add since anyway there might be true IOMMU_RESV_DIRECT range reported from host which also should be handled. 2) Alternatively we could instead allow Qemu to request dynamic change of physical doorbell mapping in stage2, e.g....