> -----Original Message-----
> From: Tian, Kevin [mailto:[email protected]]
> Sent: 23 February 2018 05:17
> To: Paul Durrant <[email protected]>; [email protected]
> Cc: Stefano Stabellini <[email protected]>; Wei Liu
> <[email protected]>; George Dunlap <[email protected]>;
> Andrew Cooper <[email protected]>; Ian Jackson
> <[email protected]>; Tim (Xen.org) <[email protected]>; Jan Beulich
> <[email protected]>; Daniel De Graaf <[email protected]>
> Subject: RE: [Xen-devel] [PATCH 5/7] public / x86: introduce
> __HYPERCALL_iommu_op
>
> > From: Paul Durrant [mailto:[email protected]]
> > Sent: Tuesday, February 13, 2018 5:23 PM
> >
> > > -----Original Message-----
> > > From: Tian, Kevin [mailto:[email protected]]
> > > Sent: 13 February 2018 06:43
> > > To: Paul Durrant <[email protected]>; xen-
> > [email protected]
> > > Cc: Stefano Stabellini <[email protected]>; Wei Liu
> > > <[email protected]>; George Dunlap <[email protected]>;
> > > Andrew Cooper <[email protected]>; Ian Jackson
> > > <[email protected]>; Tim (Xen.org) <[email protected]>; Jan Beulich
> > > <[email protected]>; Daniel De Graaf <[email protected]>
> > > Subject: RE: [Xen-devel] [PATCH 5/7] public / x86: introduce
> > > __HYPERCALL_iommu_op
> > >
> > > > From: Paul Durrant
> > > > Sent: Monday, February 12, 2018 6:47 PM
> > > >
> > > > This patch introduces the boilerplate for a new hypercall to allow a
> > > > domain to control IOMMU mappings for its own pages.
> > > > Whilst there is duplication of code between the native and compat
> > entry
> > > > points which appears ripe for some form of combination, I think it is
> > > > better to maintain the separation as-is because the compat entry point
> > > > will necessarily gain complexity in subsequent patches.
> > > >
> > > > NOTE: This hypercall is only implemented for x86 and is currently
> > > > restricted by XSM to dom0 since it could be used to cause IOMMU
> > > > faults which may bring down a host.
> > > >
> > > > Signed-off-by: Paul Durrant <[email protected]>
> > > [...]
> > > > +
> > > > +
> > > > +static bool can_control_iommu(void)
> > > > +{
> > > > + struct domain *currd = current->domain;
> > > > +
> > > > + /*
> > > > + * IOMMU mappings cannot be manipulated if:
> > > > + * - the IOMMU is not enabled or,
> > > > + * - the IOMMU is passed through or,
> > > > + * - shared EPT configured or,
> > > > + * - Xen is maintaining an identity map.
> > >
> > > "for dom0"
> > >
> > > > + */
> > > > + if ( !iommu_enabled || iommu_passthrough ||
> > > > + iommu_use_hap_pt(currd) || need_iommu(currd) )
> > >
> > > I guess it's clearer to directly check iommu_dom0_strict here
> >
> > Well, the problem with that is that it totally ties this interface to dom0.
> > Whilst, in practice, that is the case at the moment (because of the xsm
> > check) I do want to leave the potential to allow other PV domains to control
> > their IOMMU mappings, if that make sense in future.
> >
>
> first it's inconsistent from the comments - "Xen is maintaining
> an identity map" which only applies to dom0.
That's not true. If I assign a PCI device to an HVM domain, for instance, then
need_iommu() is true for that domain and indeed Xen maintains a 1:1 BFN:GFN map
for that domain.
>
> second I'm afraid !need_iommu is not an accurate condition to represent
> PV domain. what about iommu also enabled for future PV domains?
>
I don't quite follow... need_iommu is a per-domain flag, set for dom0 when in
strict mode, set for others when passing through a device. Either way, if Xen
is maintaining the IOMMU pagetables then it is clearly unsafe for the domain to
also be messing with them.
Cheers,
Paul
> Thanks
> Kevin
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
