From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Ram Pai <linuxram@us.ibm.com>,
Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Subject: Re: [PATCH v2] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory
Date: Tue, 18 Aug 2020 16:51:52 -0300 [thread overview]
Message-ID: <877dtvn353.fsf@morokweng.localdomain> (raw)
In-Reply-To: <20200818065911.GA2324@lst.de>
Christoph Hellwig <hch@lst.de> writes:
> On Mon, Aug 17, 2020 at 06:46:58PM -0300, Thiago Jung Bauermann wrote:
>> POWER secure guests (i.e., guests which use the Protection Execution
>> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
>> they don't need the SWIOTLB memory to be in low addresses since the
>> hypervisor doesn't have any addressing limitation.
>>
>> This solves a SWIOTLB initialization problem we are seeing in secure guests
>> with 128 GB of RAM: they are configured with 4 GB of crashkernel reserved
>> memory, which leaves no space for SWIOTLB in low addresses.
>>
>> To do this, we use mostly the same code as swiotlb_init(), but allocate the
>> buffer using memblock_alloc() instead of memblock_alloc_low().
>>
>> We also need to add swiotlb_set_no_iotlb_memory() in order to set the
>> no_iotlb_memory flag if initialization fails.
>
> Do you really need the helper? As far as I can tell the secure guests
> very much rely on swiotlb for all I/O, so you might as well panic if
> you fail to allocate it.
That is true. Ok, I will do that.
--
Thiago Jung Bauermann
IBM Linux Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
linuxppc-dev@lists.ozlabs.org, Ram Pai <linuxram@us.ibm.com>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>,
Robin Murphy <robin.murphy@arm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v2] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory
Date: Tue, 18 Aug 2020 16:51:52 -0300 [thread overview]
Message-ID: <877dtvn353.fsf@morokweng.localdomain> (raw)
In-Reply-To: <20200818065911.GA2324@lst.de>
Christoph Hellwig <hch@lst.de> writes:
> On Mon, Aug 17, 2020 at 06:46:58PM -0300, Thiago Jung Bauermann wrote:
>> POWER secure guests (i.e., guests which use the Protection Execution
>> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
>> they don't need the SWIOTLB memory to be in low addresses since the
>> hypervisor doesn't have any addressing limitation.
>>
>> This solves a SWIOTLB initialization problem we are seeing in secure guests
>> with 128 GB of RAM: they are configured with 4 GB of crashkernel reserved
>> memory, which leaves no space for SWIOTLB in low addresses.
>>
>> To do this, we use mostly the same code as swiotlb_init(), but allocate the
>> buffer using memblock_alloc() instead of memblock_alloc_low().
>>
>> We also need to add swiotlb_set_no_iotlb_memory() in order to set the
>> no_iotlb_memory flag if initialization fails.
>
> Do you really need the helper? As far as I can tell the secure guests
> very much rely on swiotlb for all I/O, so you might as well panic if
> you fail to allocate it.
That is true. Ok, I will do that.
--
Thiago Jung Bauermann
IBM Linux Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
linuxppc-dev@lists.ozlabs.org, Ram Pai <linuxram@us.ibm.com>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v2] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory
Date: Tue, 18 Aug 2020 16:51:52 -0300 [thread overview]
Message-ID: <877dtvn353.fsf@morokweng.localdomain> (raw)
In-Reply-To: <20200818065911.GA2324@lst.de>
Christoph Hellwig <hch@lst.de> writes:
> On Mon, Aug 17, 2020 at 06:46:58PM -0300, Thiago Jung Bauermann wrote:
>> POWER secure guests (i.e., guests which use the Protection Execution
>> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
>> they don't need the SWIOTLB memory to be in low addresses since the
>> hypervisor doesn't have any addressing limitation.
>>
>> This solves a SWIOTLB initialization problem we are seeing in secure guests
>> with 128 GB of RAM: they are configured with 4 GB of crashkernel reserved
>> memory, which leaves no space for SWIOTLB in low addresses.
>>
>> To do this, we use mostly the same code as swiotlb_init(), but allocate the
>> buffer using memblock_alloc() instead of memblock_alloc_low().
>>
>> We also need to add swiotlb_set_no_iotlb_memory() in order to set the
>> no_iotlb_memory flag if initialization fails.
>
> Do you really need the helper? As far as I can tell the secure guests
> very much rely on swiotlb for all I/O, so you might as well panic if
> you fail to allocate it.
That is true. Ok, I will do that.
--
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-08-18 19:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-17 21:46 [PATCH v2] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory Thiago Jung Bauermann
2020-08-17 21:46 ` Thiago Jung Bauermann
2020-08-17 21:46 ` Thiago Jung Bauermann
2020-08-18 6:59 ` Christoph Hellwig
2020-08-18 6:59 ` Christoph Hellwig
2020-08-18 6:59 ` Christoph Hellwig
2020-08-18 19:51 ` Thiago Jung Bauermann [this message]
2020-08-18 19:51 ` Thiago Jung Bauermann
2020-08-18 19:51 ` Thiago Jung Bauermann
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=877dtvn353.fsf@morokweng.localdomain \
--to=bauerman@linux.ibm.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=linuxram@us.ibm.com \
--cc=m.szyprowski@samsung.com \
--cc=mpe@ellerman.id.au \
--cc=robin.murphy@arm.com \
--cc=sathnaga@linux.vnet.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.