[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 12/12] swiotlb-xen: this is PV-only on x86

  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 13 Sep 2021 09:28:39 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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; bh=hwD0t7QtOjKdwm4YKCqr7HJsRnUZs/jS/v3G2iEWAa8=; b=OtQ9DRXvc5RNt1cf3iwJUrakR6XcLKtgHOR5bDSDkmid+QylMRZ+CE/lhH0YR+uMAYQKUqo2fGYEfZKsVzyVxCVrpwFoka9X8iMWowSIPtU4rcG94R9+kNFMkyRukOwDxIjX2gwijmxsI5OzK3ihnxPHcAw0IzivkXHwySs6D0y46dwkNIryxeDuDNjSdF4zvZDYnEFbivDcdxB10X5JoI7vW4VTKg5oVyEhqXecqhdfUGItKXlbUDhHxvLnohCH9hAPl1oBJu0V/7i4IPr5AfNgrjl1G4fXDQi0HhJ52LSOzoRf4FBoWJNsUGyXku08AaMKW3oFV6IxsEhiWh4hjA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HetmQA6G6KQc0Ars8sFJcEgeKzVb+mUw4CCId6XhJzXN4XWw3LyXFEGzISJoIPM3yG7Fz8mPRmA5RAziqWKKtYWMK6z3czxj+5PNJ0bxax+3yDorLrhNETR9oh/ITNgolQuXxgemKrfabs7jeC99f4VJjwATHSHYY1KBXpcfmgYD0tqrXAGD+rwGioNnIgy3QgTU4ir87LDovPLVsG4d1wc3tBWSkR5FDyCOWzmZaU2DY/lHDyWRGCX1lRGIP/RC+AJZkc0PGKxPb7bU9k/QZUI3ERFOi/phZt5LBjTG7DOBc0TaHqovNxuV8dPLBhCveRMnPRY9gV/7M868B6Hr+g==
  • Authentication-results: infradead.org; dkim=none (message not signed) header.d=none;infradead.org; dmarc=none action=none header.from=suse.com;
  • Cc: Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, lkml <linux-kernel@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 13 Sep 2021 07:28:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 11.09.2021 01:48, Stefano Stabellini wrote:
> On Wed, 8 Sep 2021, Christoph Hellwig wrote:
>> On Tue, Sep 07, 2021 at 02:13:21PM +0200, Jan Beulich wrote:
>>> The code is unreachable for HVM or PVH, and it also makes little sense
>>> in auto-translated environments. On Arm, with
>>> xen_{create,destroy}_contiguous_region() both being stubs, I have a hard
>>> time seeing what good the Xen specific variant does - the generic one
>>> ought to be fine for all purposes there. Still Arm code explicitly
>>> references symbols here, so the code will continue to be included there.
>> Can the Xen/arm folks look into that?  Getting ARM out of using
>> swiotlb-xen would be a huge step forward cleaning up some DMA APIs.
> On ARM swiotlb-xen is used for a different purpose compared to x86.
> Many ARM SoCs still don't have an IOMMU covering all DMA-mastering
> devices (e.g. Raspberry Pi 4). As a consequence we map Dom0 1:1 (guest
> physical == physical address).
> Now if it was just for Dom0, thanks to the 1:1 mapping, we wouldn't need
> swiotlb-xen. But when we start using PV drivers to share the network or
> disk between Dom0 and DomU we are going to get DomU pages mapped in
> Dom0, we call them "foreign pages".  They are not mapped 1:1. It can
> happen that one of these foreign pages are used for DMA operations
> (e.g. related to the NIC). swiotlb-xen is used to detect these
> situations and translate the guest physical address to physical address
> of foreign pages appropriately.

Hmm, you say "translate", which isn't my understanding of swiotlb's
purpose. As per my understanding swiotlb instead double buffers data
such that is becomes accessible, or suitably arranges underlying
machine addresses. The latter part is clearly a PV-only thing, unused
by Arm as can be seen by there not being any use of XENMEM_exchange.
So it must be the former part that you're talking about, but that's
also the purpose of the non-Xen swiotlb code. If only for my own
education and understanding, could you point me at the difference
between swiotlb-xen and generic swiotlb which addresses this specific
aspect of Arm behavior?




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.