Re: [Xen-devel] [RFC] Dom0 PV IOMMU control design (draft A)

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.04.14 at 19:28, <malcolm.crossley@xxxxxxxxxx> wrote:
> Purpose
> =======
> 
> Allow Xen Domain 0 PV guests to create/modify/destroy IOMMU mappings for
> hardware devices that Domain 0 has access to. This enables Domain 0 to 
> program
> a bus address space mapping which matches it's GPFN mapping. Once a 1-1
> mapping of GPFN to bus address space is created then a bounce buffer
> region is not required for the IO devices connected to the IOMMU.

So the idea then is for the domain to
- create this 1:1 mapping once at boot, and update it as pages get
  ballooned int/out, or
- zap the entire IOMMU mapping at boot, and establish individual
  mappings as needed based on the driver's use of the DMA map ops?

> IOMMUOP_unmap_page
> ----------------
> First argument, pointer to array of `struct iommu_map_op`
> Second argument, integer count of `struct iommu_map_op` elements in array
> 
> This subop will attempt to unmap each element in the `struct 
> iommu_map_op` array
> and record the mapping status back into the array itself. If an 

unmapping?

> unmapping fault

mapping?

> occurs then the hypercall stop processing the array and return with an 
> EFAULT;

-EFAULT.

> The IOMMU TLB will only be flushed when the hypercall completes or a 
> hypercall
> continuation is created.
> 
>      struct iommu_map_op {
>          uint64_t bfn;
>          uint64_t mfn;
>          uint32_t flags;
>          int32_t status;
>      };
> 
> --------------------------------------------------------------------
> Field          Purpose
> -----          -----------------------------------------------------
> `bfn`          [in] Bus address frame number to be unmapped
> 
> `mfn`          [in] This field is ignored for unmap subop
> 
> `flags`        [in] This field is ignored for unmap subop
> 
> `status`       [out] Mapping status of this unmap operation, 0 indicates 
> success

Hmm, bfn and flags ignored would call for an abbreviated interface
structure. Or how about IOMMU_MAP_OP_{readable,writeable}
implying unmap, in which case for now you'd need only one op. And
with that I wonder whether this shouldn't simply be a new
PHYSDEVOP_iommu_map.

> Security Implications of allowing Domain 0 IOMMU control
> ========================================================
> 
> Xen currently allows IO devices attached to Domain 0 to have direct 
> access to
> the all of the MFN address space (except Xen hypervisor memory regions),
> provided the Xen IOMMU option dom0-strict is not enabled.
> 
> The PV IOMMU feature provides the same level of access to MFN address space
> and the feature is not enabled when the Xen IOMMU option dom0-strict is
> enabled. Therefore security is not affected by the PV IOMMU feature.

While I was about to reply with the same request to extend this to
driver domains, this last section pretty much excludes such an
extension. I guess that would benefit from revisiting.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel