[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC v1 5/6] xen-swiotlb: convert variables to arrays
- To: Christoph Hellwig <hch@xxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, jgross@xxxxxxxx
- From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
- Date: Fri, 19 Feb 2021 15:32:15 -0500
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q+tlPGJKqF6UYVHJtf4RiU4j3D0HGkZd1GdqLyhGl5k=; b=Ld4ESsnTlUH2IkkNza53+IbGAgGHaPJeYH9fktWs41vjynoJKfwrL6UESpbkf32rqtcpn2ZLZgTE1Af7r5IglEeGhNRYYhj+VtX7jZ6PJSJ+lACZVLEP6W0LpvNQV6UOa7W12GukpzMz7BYCboUt91Mf6IH25VTO5W1bRfMgPbAAnq0urCVvyYOflMsJ2eeiFpcSRVqzoUW9HtR7q90JyioiJiXgZ+KaeRf44blAJAaWy3Qgplp2I/z7msFr/Ofgri3wWlCOFIydrFoNl8pAhTvCCkFrLRLOmI7FVQAMSzAFbg++ouoLQMvdZGofr5TVDmhRCPi94+/Udr7rf/s4hQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cilLbaU5P1EZKHhQFZ/tXoZgv5UWAMFelQ7A/weacmzr72UFTnUSEeSa9kbGIBPRfw+6dJkNoCJu/MPdyLRkSaeodwlghJ3gpIx2a5Q6Yps8t9IsmyODpIogyhDzB2KcPigx1t/PLQjQ0aY9BV2YOwMmp9HQ6YsPHvYjtLbQFQ3feLnZ8Oq18m9XCdU7miOfErH1S1+Jiupd7/6I3LF/Tx21dshT7ObtSCxkmD0/yYxFZyIp1NJMRAOd6BN9oqOUdO0mN+Lf41BrXyMtnu4Z4QuZg7LYxa9iIoc+Ik+Te2TTm46doh2faynP3k5BQa8PFLS3OG4xcS3kzxunHTzp5w==
- Authentication-results: lst.de; dkim=none (message not signed) header.d=none;lst.de; dmarc=none action=none header.from=oracle.com;
- Cc: Dongli Zhang <dongli.zhang@xxxxxxxxxx>, dri-devel@xxxxxxxxxxxxxxxxxxxxx, intel-gfx@xxxxxxxxxxxxxxxxxxxxx, iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx, linux-mips@xxxxxxxxxxxxxxx, linux-mmc@xxxxxxxxxxxxxxx, linux-pci@xxxxxxxxxxxxxxx, linuxppc-dev@xxxxxxxxxxxxxxxx, nouveau@xxxxxxxxxxxxxxxxxxxxx, x86@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, adrian.hunter@xxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, benh@xxxxxxxxxxxxxxxxxxx, bskeggs@xxxxxxxxxx, bhelgaas@xxxxxxxxxx, bp@xxxxxxxxx, boris.ostrovsky@xxxxxxxxxx, chris@xxxxxxxxxxxxxxxxxx, daniel@xxxxxxxx, airlied@xxxxxxxx, hpa@xxxxxxxxx, mingo@xxxxxxxxxx, mingo@xxxxxxxxxx, jani.nikula@xxxxxxxxxxxxxxx, joonas.lahtinen@xxxxxxxxxxxxxxx, jgross@xxxxxxxx, m.szyprowski@xxxxxxxxxxx, matthew.auld@xxxxxxxxx, mpe@xxxxxxxxxxxxxx, rppt@xxxxxxxxxx, paulus@xxxxxxxxx, peterz@xxxxxxxxxxxxx, robin.murphy@xxxxxxx, rodrigo.vivi@xxxxxxxxx, sstabellini@xxxxxxxxxx, bauerman@xxxxxxxxxxxxx, tsbogend@xxxxxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx, ulf.hansson@xxxxxxxxxx, joe.jin@xxxxxxxxxx, thomas.lendacky@xxxxxxx
- Delivery-date: Fri, 19 Feb 2021 20:33:45 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
> On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
> > So one thing that has been on my mind for a while: I'd really like
> > to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb
> > to swiotlb the main difference seems to be:
> >
> > - additional reasons to bounce I/O vs the plain DMA capable
> > - the possibility to do a hypercall on arm/arm64
> > - an extra translation layer before doing the phys_to_dma and vice
> > versa
> > - an special memory allocator
> >
> > I wonder if inbetween a few jump labels or other no overhead enablement
> > options and possibly better use of the dma_range_map we could kill
> > off most of swiotlb-xen instead of maintaining all this code duplication?
>
> So I looked at this a bit more.
>
> For x86 with XENFEAT_auto_translated_physmap (how common is that?)
Juergen, Boris please correct me if I am wrong, but that
XENFEAT_auto_translated_physmap
only works for PVH guests?
> pfn_to_gfn is a nop, so plain phys_to_dma/dma_to_phys do work as-is.
>
> xen_arch_need_swiotlb always returns true for x86, and
> range_straddles_page_boundary should never be true for the
> XENFEAT_auto_translated_physmap case.
Correct. The kernel should have no clue of what the real MFNs are
for PFNs.
>
> So as far as I can tell the mapping fast path for the
> XENFEAT_auto_translated_physmap can be trivially reused from swiotlb.
>
> That leaves us with the next more complicated case, x86 or fully cache
> coherent arm{,64} without XENFEAT_auto_translated_physmap. In that case
> we need to patch in a phys_to_dma/dma_to_phys that performs the MFN
> lookup, which could be done using alternatives or jump labels.
> I think if that is done right we should also be able to let that cover
> the foreign pages in is_xen_swiotlb_buffer/is_swiotlb_buffer, but
> in that worst case that would need another alternative / jump label.
>
> For non-coherent arm{,64} we'd also need to use alternatives or jump
> labels to for the cache maintainance ops, but that isn't a hard problem
> either.
>
>
|