RE: [PATCH 10/12] swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Dongli Zhang <dongli.zhang@xxxxxxxxxx>, Christoph Hellwig <hch@xxxxxx>, "iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx" <iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Subject: RE: [PATCH 10/12] swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction
- From: "Michael Kelley (LINUX)" <mikelley@xxxxxxxxxxxxx>
- Date: Sun, 6 Mar 2022 17:01:27 +0000
- Accept-language: en-US
- Cc: "x86@xxxxxxxxxx" <x86@xxxxxxxxxx>, Anshuman Khandual <anshuman.khandual@xxxxxxx>, Tom Lendacky <thomas.lendacky@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Joerg Roedel <joro@xxxxxxxxxx>, David Woodhouse <dwmw2@xxxxxxxxxxxxx>, Lu Baolu <baolu.lu@xxxxxxxxxxxxxxx>, Robin Murphy <robin.murphy@xxxxxxx>, "linux-arm-kernel@xxxxxxxxxxxxxxxxxxx" <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "linux-ia64@xxxxxxxxxxxxxxx" <linux-ia64@xxxxxxxxxxxxxxx>, "linux-mips@xxxxxxxxxxxxxxx" <linux-mips@xxxxxxxxxxxxxxx>, "linuxppc-dev@xxxxxxxxxxxxxxxx" <linuxppc-dev@xxxxxxxxxxxxxxxx>, "linux-riscv@xxxxxxxxxxxxxxxxxxx" <linux-riscv@xxxxxxxxxxxxxxxxxxx>, "linux-s390@xxxxxxxxxxxxxxx" <linux-s390@xxxxxxxxxxxxxxx>, "linux-hyperv@xxxxxxxxxxxxxxx" <linux-hyperv@xxxxxxxxxxxxxxx>, "tboot-devel@xxxxxxxxxxxxxxxxxxxxx" <tboot-devel@xxxxxxxxxxxxxxxxxxxxx>, "linux-pci@xxxxxxxxxxxxxxx" <linux-pci@xxxxxxxxxxxxxxx>
- In-reply-to: <556312e4-da86-b980-475c-1cfd7818ffdc@oracle.com>
- Msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=433969a6-4cde-4cdd-a529-34a7717de2f8;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-03-06T16:49:10Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
- References: <20220301105311.885699-1-hch@lst.de> <20220301105311.885699-11-hch@lst.de> <MN0PR21MB3098F7AFC85BE5D83B0E64E5D7059@MN0PR21MB3098.namprd21.prod.outlook.com> <556312e4-da86-b980-475c-1cfd7818ffdc@oracle.com>
From: Dongli Zhang <dongli.zhang@xxxxxxxxxx> 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@xxxxxx> 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@xxxxxxxxxx/
>
> 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
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]