Re: [Xen-devel] per-domain passthrough/iommu options

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich <JBeulich@xxxxxxxx>
> Sent: 26 July 2019 13:57
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel (xen-devel@xxxxxxxxxxxxxxxxxxxx) 
> <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] per-domain passthrough/iommu options
> 
> On 26.07.2019 14:29, Paul Durrant wrote:
> >    I sent a previous email [1] about enabling use of the IOMMU on a 
> > per-domain basis and am now a
> reasonable way into my patch series, which also allows for IOMMU 
> option-setting (specifically shared
> EPT use) on a per-domain basis too. Before I post v1 I'd like to get some 
> opinion on the what the
> xl.cfg options should look like.
> >    The simplest way for me to do things would be to have two new boolean 
> > options; something like:
> >
> > 'passthrough' - enable/disable pass-through support (i.e. use of the 
> > IOMMU)... can be implicitly
> enabled if there are pci or dt devices specified in the xl.cfg.
> > 'no-sharept' - named to match the xen-cmdline option for turning off shared 
> > EPT. (EPT sharing
> currently defaults on globally).
> >
> >    I think the former is probably ok, but thinking forward to a time where 
> > we might have vIOMMU (PV
> or emulated) the latter is probably not the right thing to use. So, another 
> way might be to have an
> IOMMU page-table option... something like:
> >
> > 'iommu-pt = shared|sync'
> >
> >    where 'shared' means use EPT mappings, and 'sync' means keep the P2M in 
> > sync. This could then be
> extended with 'viommu' later, meaning that there would be some form of vIOMMU 
> exposed to the guest, be
> it emulated, PV or both. One drawback with this mechanism is that 'shared' is 
> not always possible
> (e.g. on AMD h/w) so what should be done in that case? Should selecting that 
> option be considered an
> error, or should there be a fall-back to 'sync'? The fall-back would be 
> easier to deal with as then
> the option could just default to 'sync' if it was not specified.
> 
> The fall-back sounds reasonable to me (as long as that's properly
> described in documentation). What I'm less happy with is the idea
> of having two options instead of just one. But of course this may
> be a result of how libxl wants to organize options. If there's no
> restriction at that end, then how about
> 
> passthrough = off|sync|share-pt|viommu
> 
> ? It would default to off when there are no devices listed in the
> config, and to share-pt (with the fall-back to sync) when there is
> at least one.

Yes, that sounds like it would work.

> 
> As to "sync" - how did you come to use this as the "opposite" of
> "share-pt"?

Oh, that's just adopting the general naming used in Xen. For a domU it is 
either going to have 'need_sync' set in its domain_iommu structure, or EPT 
sharing will be active.
 
> There's nothing asynchronous with shared page tables,
> is there? Maybe "private-pt" or "separate-pt"? The option wouldn't
> be used typically anyway, especially if alongside "off" there was
> also an "on" variant, meaning the same as "share-pt".

Not sure how 'on' would co-exist with 'viommu'... the crucial difference is 
whether the p2m is shared or not and the currently the only option in the 
non-shared case, because we lack a viommu, is to keep the IOMMU mappings in 
sync with the P2M whenever the latter is updated. So, how about:

passthrough = off|sync-pt|share-pt|viommu

? I don't think 'private-pt' or 'separate-pt' really capture the fact that the 
page tables match the P2M. They could just as easily be taken to mean that they 
are populated using some other policy.

  Paul

> 
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel