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....