All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ashish Kalra <ashish.kalra@amd.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: hch@lst.de, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	hpa@zytor.com, x86@kernel.org, luto@kernel.org,
	peterz@infradead.org, dave.hansen@linux-intel.com,
	konrad.wilk@oracle.com, iommu@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, brijesh.singh@amd.com,
	Thomas.Lendacky@amd.com
Subject: Re: [PATCH v2] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.
Date: Tue, 21 Jan 2020 20:09:47 +0000	[thread overview]
Message-ID: <20200121200947.GA24884@ashkalra_ubuntu_server> (raw)
In-Reply-To: <20191220015245.GA7010@localhost.localdomain>

On Thu, Dec 19, 2019 at 08:52:45PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 09, 2019 at 11:13:46PM +0000, Ashish Kalra wrote:
> > From: Ashish Kalra <ashish.kalra@amd.com>
> > 
> > For SEV, all DMA to and from guest has to use shared
> > (un-encrypted) pages. SEV uses SWIOTLB to make this happen
> > without requiring changes to device drivers. However,
> > depending on workload being run, the default 64MB of SWIOTLB
> > might not be enough and SWIOTLB may run out of buffers to
> > use for DMA, resulting in I/O errors.
> > 
> > Increase the default size of SWIOTLB for SEV guests using
> > a minimum value of 128MB and a maximum value of 512MB,
> > determining on amount of provisioned guest memory.
> > 
> > The SWIOTLB default size adjustment is added as an
> > architecture specific interface/callback to allow
> > architectures such as those supporting memory encryption
> > to adjust/expand SWIOTLB size for their use.
> 
> What if this was made dynamic? That is if there is a memory
> pressure you end up expanding the SWIOTLB dynamically?

As of now we want to keep it as simple as possible and more
like a stop-gap arrangement till something more elegant is
available.

> 
>> Also is it worth doing this calculation based on memory or
>> more on the # of PCI devices + their MMIO ranges size?

Additional memory calculations based on # of PCI devices and
their memory ranges will make it more complicated with so
many other permutations and combinations to explore, it is
essential to keep this patch as simple as possible by 
adjusting the bounce buffer size simply by determining it
from the amount of provisioned guest memory.

Thanks,
Ashish

WARNING: multiple messages have this Message-ID (diff)
From: Ashish Kalra <ashish.kalra@amd.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Thomas.Lendacky@amd.com, brijesh.singh@amd.com,
	dave.hansen@linux-intel.com, konrad.wilk@oracle.com,
	peterz@infradead.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	mingo@redhat.com, bp@alien8.de, luto@kernel.org, hpa@zytor.com,
	tglx@linutronix.de, hch@lst.de
Subject: Re: [PATCH v2] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.
Date: Tue, 21 Jan 2020 20:09:47 +0000	[thread overview]
Message-ID: <20200121200947.GA24884@ashkalra_ubuntu_server> (raw)
In-Reply-To: <20191220015245.GA7010@localhost.localdomain>

On Thu, Dec 19, 2019 at 08:52:45PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 09, 2019 at 11:13:46PM +0000, Ashish Kalra wrote:
> > From: Ashish Kalra <ashish.kalra@amd.com>
> > 
> > For SEV, all DMA to and from guest has to use shared
> > (un-encrypted) pages. SEV uses SWIOTLB to make this happen
> > without requiring changes to device drivers. However,
> > depending on workload being run, the default 64MB of SWIOTLB
> > might not be enough and SWIOTLB may run out of buffers to
> > use for DMA, resulting in I/O errors.
> > 
> > Increase the default size of SWIOTLB for SEV guests using
> > a minimum value of 128MB and a maximum value of 512MB,
> > determining on amount of provisioned guest memory.
> > 
> > The SWIOTLB default size adjustment is added as an
> > architecture specific interface/callback to allow
> > architectures such as those supporting memory encryption
> > to adjust/expand SWIOTLB size for their use.
> 
> What if this was made dynamic? That is if there is a memory
> pressure you end up expanding the SWIOTLB dynamically?

As of now we want to keep it as simple as possible and more
like a stop-gap arrangement till something more elegant is
available.

> 
>> Also is it worth doing this calculation based on memory or
>> more on the # of PCI devices + their MMIO ranges size?

Additional memory calculations based on # of PCI devices and
their memory ranges will make it more complicated with so
many other permutations and combinations to explore, it is
essential to keep this patch as simple as possible by 
adjusting the bounce buffer size simply by determining it
from the amount of provisioned guest memory.

Thanks,
Ashish
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2020-01-21 20:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-09 23:13 [PATCH v2] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests Ashish Kalra
2019-12-09 23:13 ` Ashish Kalra
2019-12-20  1:52 ` Konrad Rzeszutek Wilk
2019-12-20  1:52   ` Konrad Rzeszutek Wilk
2020-01-21 20:09   ` Ashish Kalra [this message]
2020-01-21 20:09     ` Ashish Kalra
2020-01-21 20:54     ` Konrad Rzeszutek Wilk
2020-01-21 20:54       ` Konrad Rzeszutek Wilk
2020-01-24 23:00       ` Ashish Kalra
2020-01-24 23:00         ` Ashish Kalra
2020-02-04 19:35         ` Ashish Kalra
2020-02-04 19:35           ` Ashish Kalra
2020-03-03 17:03           ` Konrad Rzeszutek Wilk
2020-03-03 17:03             ` Konrad Rzeszutek Wilk
2020-03-12  0:43             ` Ashish Kalra
2020-03-12  0:43               ` Ashish Kalra
2020-03-30 22:25             ` Ashish Kalra
2020-03-30 22:25               ` Ashish Kalra
2020-04-27 18:53               ` Ashish Kalra
2020-04-27 18:53                 ` Ashish Kalra
2020-06-23 13:38                 ` Konrad Rzeszutek Wilk
2020-06-23 13:38                   ` Konrad Rzeszutek Wilk
2020-06-24  0:23                   ` Ashish Kalra
2020-06-24  0:23                     ` Ashish Kalra
2020-06-24  7:05                     ` Ashish Kalra
2020-06-24  7:05                       ` Ashish Kalra
2020-06-24 21:11                       ` Konrad Rzeszutek Wilk
2020-06-24 21:11                         ` Konrad Rzeszutek Wilk

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=20200121200947.GA24884@ashkalra_ubuntu_server \
    --to=ashish.kalra@amd.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=dave.hansen@linux-intel.com \
    --cc=hch@lst.de \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=konrad.wilk@oracle.com \
    --cc=konrad@darnok.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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 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.