xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Huang Rui" <ray.huang@amd.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Stewart Hildebrand" <Stewart.Hildebrand@amd.com>,
	"Xenia Ragiadakou" <burzalodowa@gmail.com>,
	"Honglei Huang" <honglei1.huang@amd.com>,
	"Julia Zhang" <julia.zhang@amd.com>,
	"Chen Jiqian" <Jiqian.Chen@amd.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Oleksandr Tyshchenko" <oleksandr_tyshchenko@epam.com>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh
Date: Wed, 15 Mar 2023 16:25:06 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2303151616200.3462@ubuntu-linux-20-04-desktop> (raw)
In-Reply-To: <f5e03f2a-8176-528f-e885-9a97940367c0@suse.com>

On Wed, 15 Mar 2023, Jan Beulich wrote:
> On 15.03.2023 01:52, Stefano Stabellini wrote:
> > On Mon, 13 Mar 2023, Jan Beulich wrote:
> >> On 12.03.2023 13:01, Huang Rui wrote:
> >>> Xen PVH is the paravirtualized mode and takes advantage of hardware
> >>> virtualization support when possible. It will using the hardware IOMMU
> >>> support instead of xen-swiotlb, so disable swiotlb if current domain is
> >>> Xen PVH.
> >>
> >> But the kernel has no way (yet) to drive the IOMMU, so how can it get
> >> away without resorting to swiotlb in certain cases (like I/O to an
> >> address-restricted device)?
> > 
> > I think Ray meant that, thanks to the IOMMU setup by Xen, there is no
> > need for swiotlb-xen in Dom0. Address translations are done by the IOMMU
> > so we can use guest physical addresses instead of machine addresses for
> > DMA. This is a similar case to Dom0 on ARM when the IOMMU is available
> > (see include/xen/arm/swiotlb-xen.h:xen_swiotlb_detect, the corresponding
> > case is XENFEAT_not_direct_mapped).
> 
> But how does Xen using an IOMMU help with, as said, address-restricted
> devices? They may still need e.g. a 32-bit address to be programmed in,
> and if the kernel has memory beyond the 4G boundary not all I/O buffers
> may fulfill this requirement.

In short, it is going to work as long as Linux has guest physical
addresses (not machine addresses, those could be anything) lower than
4GB.

If the address-restricted device does DMA via an IOMMU, then the device
gets programmed by Linux using its guest physical addresses (not machine
addresses).

The 32-bit restriction would be applied by Linux to its choice of guest
physical address to use to program the device, the same way it does on
native. The device would be fine as it always uses Linux-provided <4GB
addresses. After the IOMMU translation (pagetable setup by Xen), we
could get any address, including >4GB addresses, and that is expected to
work.


  reply	other threads:[~2023-03-15 23:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-12 12:01 [RFC PATCH 0/5] Add Xen PVH dom0 support for GPU Huang Rui
2023-03-12 12:01 ` [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh Huang Rui
2023-03-13  8:56   ` Jan Beulich
2023-03-15  0:52     ` Stefano Stabellini
2023-03-15  4:14       ` Huang Rui
2023-03-15  6:52         ` Jan Beulich
2023-03-15  6:49       ` Jan Beulich
2023-03-15 23:25         ` Stefano Stabellini [this message]
2023-03-16  7:50           ` Jan Beulich
2023-03-16 13:45             ` Alex Deucher
2023-03-16 13:48               ` Juergen Gross
2023-03-16 13:53                 ` Alex Deucher
2023-03-16 13:58                   ` Jan Beulich
2023-03-16 14:20                   ` Juergen Gross
2023-03-16 23:09                     ` Stefano Stabellini
2023-03-17 10:19                       ` Roger Pau Monné
2023-03-17 14:45                       ` Alex Deucher
2023-03-21 18:55                         ` Christian König
2023-03-16 16:28   ` Roger Pau Monné
2023-03-12 12:01 ` [RFC PATCH 2/5] xen/grants: update initialization order of xen grant table Huang Rui
2023-03-15 12:31   ` Roger Pau Monné
2023-03-12 12:01 ` [RFC PATCH 3/5] drm/amdgpu: set passthrough mode for xen pvh/hvm Huang Rui
2023-03-15 12:42   ` Roger Pau Monné
2023-03-12 12:01 ` [RFC PATCH 4/5] x86/xen: acpi registers gsi for xen pvh Huang Rui
2023-03-15 14:00   ` Roger Pau Monné
2023-03-12 12:01 ` [RFC PATCH 5/5] xen/privcmd: add IOCTL_PRIVCMD_GSI_FROM_IRQ Huang Rui
2023-03-15 14:26   ` Roger Pau Monné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.22.394.2303151616200.3462@ubuntu-linux-20-04-desktop \
    --to=sstabellini@kernel.org \
    --cc=Jiqian.Chen@amd.com \
    --cc=Stewart.Hildebrand@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=burzalodowa@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=honglei1.huang@amd.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=julia.zhang@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=ray.huang@amd.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).