[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200331014632.GA81569@dhcp-128-65.nay.redhat.com>
Date: Tue, 31 Mar 2020 09:46:32 +0800
From: Dave Young <dyoung@...hat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Kairui Song <kasong@...hat.com>, anthony.yznaga@...cle.com,
Jan Setje-Eilers <jan.setjeeilers@...cle.com>,
Alexander Graf <graf@...zon.com>,
iommu@...ts.linux-foundation.org,
the arch/x86 maintainers <x86@...nel.org>,
Christoph Hellwig <hch@....de>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Robin Murphy <robin.murphy@....com>, linux-doc@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Mark Rutland <mark.rutland@....com>, dwmw@...zon.com,
benh@...zon.com, Jan Kiszka <jan.kiszka@...mens.com>,
alcioa@...zon.com, aggh@...zon.com, aagch@...zon.com,
dhr@...zon.com, Laszlo Ersek <lersek@...hat.com>,
Baoquan He <bhe@...hat.com>, Lianbo Jiang <lijiang@...hat.com>,
brijesh.singh@....com,
"Lendacky, Thomas" <thomas.lendacky@....com>,
kexec@...ts.infradead.org
Subject: Re: [PATCH] swiotlb: Allow swiotlb to live at pre-defined address
On 03/30/20 at 09:40am, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 30, 2020 at 02:06:01PM +0800, Kairui Song wrote:
> > On Sat, Mar 28, 2020 at 7:57 PM Dave Young <dyoung@...hat.com> wrote:
> > >
> > > On 03/26/20 at 05:29pm, Alexander Graf wrote:
> > > > The swiotlb is a very convenient fallback mechanism for bounce buffering of
> > > > DMAable data. It is usually used for the compatibility case where devices
> > > > can only DMA to a "low region".
> > > >
> > > > However, in some scenarios this "low region" may be bound even more
> > > > heavily. For example, there are embedded system where only an SRAM region
> > > > is shared between device and CPU. There are also heterogeneous computing
> > > > scenarios where only a subset of RAM is cache coherent between the
> > > > components of the system. There are partitioning hypervisors, where
> > > > a "control VM" that implements device emulation has limited view into a
> > > > partition's memory for DMA capabilities due to safety concerns.
> > > >
> > > > This patch adds a command line driven mechanism to move all DMA memory into
> > > > a predefined shared memory region which may or may not be part of the
> > > > physical address layout of the Operating System.
> > > >
> > > > Ideally, the typical path to set this configuration would be through Device
> > > > Tree or ACPI, but neither of the two mechanisms is standardized yet. Also,
> > > > in the x86 MicroVM use case, we have neither ACPI nor Device Tree, but
> > > > instead configure the system purely through kernel command line options.
> > > >
> > > > I'm sure other people will find the functionality useful going forward
> > > > though and extend it to be triggered by DT/ACPI in the future.
> > >
> > > Hmm, we have a use case for kdump, this maybe useful. For example
> > > swiotlb is enabled by default if AMD SME/SEV is active, and in kdump
> > > kernel we have to increase the crashkernel reserved size for the extra
> > > swiotlb requirement. I wonder if we can just reuse the old kernel's
> > > swiotlb region and pass the addr to kdump kernel.
> > >
> >
> > Yes, definitely helpful for kdump kernel. This can help reduce the
> > crashkernel value.
> >
> > Previously I was thinking about something similar, play around the
> > e820 entry passed to kdump and let it place swiotlb in wanted region.
> > Simply remap it like in this patch looks much cleaner.
> >
> > If this patch is acceptable, one more patch is needed to expose the
> > swiotlb in iomem, so kexec-tools can pass the right kernel cmdline to
> > second kernel.
>
> We seem to be passsing a lot of data to kexec.. Perhaps something
> of a unified way since we seem to have a lot of things to pass - disabling
> IOMMU, ACPI RSDT address, and then this.
acpi_rsdp kernel cmdline is not useful anymore. The initial purpose is
for kexec-rebooting in efi system. But now we have supported efi boot
across kexec reboot thus that is useless now.
Thanks
Dave
Powered by blists - more mailing lists