All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ashish Kalra <ashish.kalra@amd.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	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,
	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, 3 Mar 2020 12:03:53 -0500	[thread overview]
Message-ID: <20200303170353.GC31627@char.us.oracle.com> (raw)
In-Reply-To: <20200204193500.GA15564@ashkalra_ubuntu_server>

On Tue, Feb 04, 2020 at 07:35:00PM +0000, Ashish Kalra wrote:
> Hello Konrad,
> 
> Looking fwd. to your feedback regarding support of other memory
> encryption architectures such as Power, S390, etc.
> 
> Thanks,
> Ashish
> 
> On Fri, Jan 24, 2020 at 11:00:08PM +0000, Ashish Kalra wrote:
> > On Tue, Jan 21, 2020 at 03:54:03PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > 
> > > > 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.
> > >> 
> > >> Please rework the patch to:
> > >> 
> > >>  - Use a log solution instead of the multiplication.
> > >>    Feel free to cap it at a sensible value.
> > 
> > Ok.
> > 
> > >> 
> > >>  - Also the code depends on SWIOTLB calling in to the
> > >>    adjust_swiotlb_default_size which looks wrong.
> > >> 
> > >>    You should not adjust io_tlb_nslabs from swiotlb_size_or_default.
> > 
> > >>    That function's purpose is to report a value.
> > >> 
> > >>  - Make io_tlb_nslabs be visible outside of the SWIOTLB code.
> > >> 
> > >>  - Can you utilize the IOMMU_INIT APIs and have your own detect which would
> > >>    modify the io_tlb_nslabs (and set swiotbl=1?).
> > 
> > This seems to be a nice option, but then IOMMU_INIT APIs are
> > x86-specific and this swiotlb buffer size adjustment is also needed
> > for other memory encryption architectures like Power, S390, etc.

Oh dear. That I hadn't considered.
> > 
> > >> 
> > >>    Actually you seem to be piggybacking on pci_swiotlb_detect_4gb - so
> > >>    perhaps add in this code ? Albeit it really should be in it's own
> > >>    file, not in arch/x86/kernel/pci-swiotlb.c
> > 
> > Actually, we piggyback on pci_swiotlb_detect_override which sets
> > swiotlb=1 as x86_64_start_kernel() and invocation of sme_early_init()
> > forces swiotlb on, but again this is all x86 architecture specific.

Then it looks like the best bet is to do it from within swiotlb_init?
We really can't do it from swiotlb_size_or_default - that function
should just return a value and nothing else.

> > 
> > Thanks,
> > Ashish

WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ashish Kalra <ashish.kalra@amd.com>
Cc: Thomas.Lendacky@amd.com, brijesh.singh@amd.com,
	dave.hansen@linux-intel.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,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	tglx@linutronix.de, hch@lst.de
Subject: Re: [PATCH v2] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.
Date: Tue, 3 Mar 2020 12:03:53 -0500	[thread overview]
Message-ID: <20200303170353.GC31627@char.us.oracle.com> (raw)
In-Reply-To: <20200204193500.GA15564@ashkalra_ubuntu_server>

On Tue, Feb 04, 2020 at 07:35:00PM +0000, Ashish Kalra wrote:
> Hello Konrad,
> 
> Looking fwd. to your feedback regarding support of other memory
> encryption architectures such as Power, S390, etc.
> 
> Thanks,
> Ashish
> 
> On Fri, Jan 24, 2020 at 11:00:08PM +0000, Ashish Kalra wrote:
> > On Tue, Jan 21, 2020 at 03:54:03PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > 
> > > > 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.
> > >> 
> > >> Please rework the patch to:
> > >> 
> > >>  - Use a log solution instead of the multiplication.
> > >>    Feel free to cap it at a sensible value.
> > 
> > Ok.
> > 
> > >> 
> > >>  - Also the code depends on SWIOTLB calling in to the
> > >>    adjust_swiotlb_default_size which looks wrong.
> > >> 
> > >>    You should not adjust io_tlb_nslabs from swiotlb_size_or_default.
> > 
> > >>    That function's purpose is to report a value.
> > >> 
> > >>  - Make io_tlb_nslabs be visible outside of the SWIOTLB code.
> > >> 
> > >>  - Can you utilize the IOMMU_INIT APIs and have your own detect which would
> > >>    modify the io_tlb_nslabs (and set swiotbl=1?).
> > 
> > This seems to be a nice option, but then IOMMU_INIT APIs are
> > x86-specific and this swiotlb buffer size adjustment is also needed
> > for other memory encryption architectures like Power, S390, etc.

Oh dear. That I hadn't considered.
> > 
> > >> 
> > >>    Actually you seem to be piggybacking on pci_swiotlb_detect_4gb - so
> > >>    perhaps add in this code ? Albeit it really should be in it's own
> > >>    file, not in arch/x86/kernel/pci-swiotlb.c
> > 
> > Actually, we piggyback on pci_swiotlb_detect_override which sets
> > swiotlb=1 as x86_64_start_kernel() and invocation of sme_early_init()
> > forces swiotlb on, but again this is all x86 architecture specific.

Then it looks like the best bet is to do it from within swiotlb_init?
We really can't do it from swiotlb_size_or_default - that function
should just return a value and nothing else.

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

  reply	other threads:[~2020-03-03 17:01 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
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 [this message]
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=20200303170353.GC31627@char.us.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=ashish.kalra@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@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.