[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230607131257.GB19206@lst.de>
Date: Wed, 7 Jun 2023 15:12:57 +0200
From: Christoph Hellwig <hch@....de>
To: Juergen Gross <jgross@...e.com>
Cc: Marek Marczykowski-Górecki
<marmarek@...isiblethingslab.com>, Christoph Hellwig <hch@....de>,
Stefano Stabellini <sstabellini@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, Ben Skeggs <bskeggs@...hat.com>,
Karol Herbst <kherbst@...hat.com>,
Lyude Paul <lyude@...hat.com>, xen-devel@...ts.xenproject.org,
iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
nouveau@...ts.freedesktop.org
Subject: Re: [PATCH 2/4] x86: always initialize xen-swiotlb when
xen-pcifront is enabling
On Mon, May 22, 2023 at 10:37:09AM +0200, Juergen Gross wrote:
> In normal cases PCI passthrough in PV guests requires to start the guest
> with e820_host=1. So it should be rather easy to limit allocating the
> 64MB in PV guests to the cases where the memory map has non-RAM regions
> especially in the first 1MB of the memory.
>
> This will cover even hotplug cases. The only case not covered would be a
> guest started with e820_host=1 even if no PCI passthrough was planned.
> But this should be rather rare (at least I hope so).
So is this an ACK for the patch and can we go ahead with it?
(I'd still like to merge swiotlb-xen into swiotlb eventually, but it's
probably not going to happen this merge window)
Powered by blists - more mailing lists