[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] per-domain passthrough/iommu options
> -----Original Message----- > From: Jan Beulich <JBeulich@xxxxxxxx> > Sent: 26 July 2019 15:34 > 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 16:26, Paul Durrant wrote: > >> From: Jan Beulich <JBeulich@xxxxxxxx> > >> Sent: 26 July 2019 15:02 > >> > >> On 26.07.2019 15:39, Paul Durrant wrote: > >>> ? 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. > >> > >> But haven't we recently seen that this fully lock-step population > >> of page tables isn't always correct (or at least desirable)? I > >> vaguely recall other comments to that effect too, from long ago. > >> I'd specifically want to avoid encoding into the interface here > >> that the two are exact mirrors of one another, now and forever. > > > > How do you think we should express it. I agree that it's a bit awkward > > because of the difference > between HVM and PV domains, but all we can do there really is document it I > think, so perhaps the > manpage could have something like: > > Sounds reasonable - it at least avoids making the behavior too > much spelled out with regard to the similarity of mappings between > IOMMU page tables and P2M. There's one issue though: > > > 'off' > > > > IOMMU mappings are disabled for the domain and so hardware may not be > > passed through. > > > > 'sync-pt' > > > > For a PV domain, all writable pages assigned to the domain are identity > > mapped by MFN in the IOMMU > page tables. Thus a device driver running in the domain may program > passthrough hardware for DMA using > MFN values (i.e. host/machine frame numbers) looked up in its P2M. > > For an HVM domain, all non-foreign RAM pages present in the P2M will be > > identity mapped by GFN > > Why "identity mapped" here? It's a GFN -> MFN mappingm, isn't it? Yes... it's hard to express. What I want to say, of course, is that device drivers can use GFNs. Can you think of any other form of words that might be better? Paul > > Jan > > > in the IOMMU page tables. Thus a device driver running in the domain may > > program passthrough > hardware using GFN values (i.e. guest physical frame numbers) without any > further translation. > > > > 'share-pt' > > > > This is unavailable for a PV domain. For an HVM domain, this option means > > that the IOMMU will be > programmed to directly reference the P2M as its page tables. This > availability of this option is > hardware specific and thus, if it is specified for a domain running on > hardware that does not allow > it, 'sync-pt' will be used instead. > > > > ? > > > > Paul > > > >> > >> Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |