[PATCH 10/12] swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction

[Michael Kelley (LINUX)]

From: Dongli Zhang <dongli.zhang at oracle.com> Sent: Friday, March 4, 2022 10:28 AM
> 
> Hi Michael,
> 
> On 3/4/22 10:12 AM, Michael Kelley (LINUX) wrote:
> > From: Christoph Hellwig <hch at lst.de> Sent: Tuesday, March 1, 2022 2:53 AM
> >>
> >> Power SVM wants to allocate a swiotlb buffer that is not restricted to low memory for
> >> the trusted hypervisor scheme.  Consolidate the support for this into the swiotlb_init
> >> interface by adding a new flag.
> >
> > Hyper-V Isolated VMs want to do the same thing of not restricting the swiotlb
> > buffer to low memory.  That's what Tianyu Lan's patch set[1] is proposing.
> > Hyper-V synthetic devices have no DMA addressing limitations, and the
> > likelihood of using a PCI pass-thru device with addressing limitations in an
> > Isolated VM seems vanishingly small.
> >
> > So could use of the SWIOTLB_ANY flag be generalized?  Let Hyper-V init
> > code set the flag before swiotlb_init() is called.  Or provide a CONFIG
> > variable that Hyper-V Isolated VMs could set.
> 
> I used to send 64-bit swiotlb, while at that time people thought it was the same
> as Restricted DMA patchset.
> 
> https://lore.kernel.org/all/20210203233709.19819-1-dongli.zhang@oracle.com/
> 
> However, I do not think Restricted DMA patchset is going to supports 64-bit (or
> high memory) DMA. Is this what you are looking for?

Yes, it looks like your patchset would do what we want for Hyper-V Isolated
VMs, but it is a more complex solution than is needed.  My assertion is that
in some environments, such as Hyper-V Isolated VMs, we're willing to assume
all devices are 64-bit DMA capable, and to stop carrying the legacy baggage.
Bounce buffering is used for a different scenario (memory encryption), and
the bounce buffers can be allocated in high memory.   There's no need for a
2nd swiotlb buffer.

Michael