All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien.Grall@arm.com
Subject: Re: [Xen-devel] [PATCH v2] xen/swiotlb: don't initialize swiotlb twice on arm64
Date: Thu, 13 Jun 2019 10:23:45 -0400	[thread overview]
Message-ID: <20190613142345.GC456@char.us.oracle.com> (raw)
In-Reply-To: <9d5a5e02-842f-fd2e-1b85-dd8a68600704@suse.com>

On Wed, Jun 05, 2019 at 04:24:06PM +0200, Juergen Gross wrote:
> On 05.06.19 16:13, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 04, 2019 at 03:41:40PM -0400, Boris Ostrovsky wrote:
> > > On 6/4/19 12:51 PM, Stefano Stabellini wrote:
> > > > On Mon, 3 Jun 2019, Boris Ostrovsky wrote:
> > > > > On 6/3/19 2:25 PM, Stefano Stabellini wrote:
> > > > > > On Tue, 28 May 2019, Boris Ostrovsky wrote:
> > > > > > > On 5/28/19 6:48 PM, Stefano Stabellini wrote:
> > > > > > > > From: Stefano Stabellini <stefanos@xilinx.com>
> > > > > > > > 
> > > > > > > > On arm64 swiotlb is often (not always) already initialized by mem_init.
> > > > > > > > We don't want to initialize it twice, which would trigger a second
> > > > > > > > memory allocation. Moreover, the second memory pool is typically made of
> > > > > > > > high pages and ends up replacing the original memory pool of low pages.
> > > > > > > > As a side effect of this change, it is possible to have low pages in
> > > > > > > > swiotlb-xen on arm64.
> > > > > > > > 
> > > > > > > > Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
> > > > > > > Has this been tested on x86?
> > > > > > Yes, I managed to test it using QEMU. There are no effects on x86, as
> > > > > > the check io_tlb_start != 0 returns false.
> > > > > I wonder though whether this is always the case.  When we are called
> > > > > from pci_xen_swiotlb_init_late() for example.
> > > > In that case, pci_xen_swiotlb_init_late() is called by
> > > > pcifront_connect_and_init_dma, which does:
> > > > 
> > > > 	if (!err && !swiotlb_nr_tbl()) {
> > > > 		err = pci_xen_swiotlb_init_late();
> > > > 		if (err)
> > > > 			dev_err(&pdev->xdev->dev, "Could not setup SWIOTLB!\n");
> > > > 	}
> > > > 
> > > > pci_xen_swiotlb_init_late() is only called when swiotlb_nr_tbl() returns
> > > > 0. If swiotlb_nr_tbl() returns 0, certainly the swiotlb has not been
> > > > allocated yet, and the io_tlb_start != 0 check at the beginning of
> > > > xen_swiotlb_init will also fail. The code will take the normal
> > > > route, same as today. In short, there should be no effects on x86.
> > > 
> > > 
> > > OK, thanks.
> > > 
> > > Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > 
> > Pushed in devel/for-linus-5.2 and will eventually move it to stable and push to Linus next-week.
> > 
> > Are there any other patches I should pick up?
> > 
> 
> I think at least the first two patches from my series:
> 
> https://patchew.org/Xen/20190529090407.1225-1-jgross@suse.com/
> 
> are ready to go in.

#2 patch says:

	"> To be symmetric with setting the flag only after having made the region                                                                                              
	> contiguous, and to avoid (perhaps just theoretical) races, wouldn't it be                                                                                            
	> better to clear the flag before calling xen_destroy_contiguous_region()?                                                                                             
	> Even better would be a TestAndClear...() operation.                                                                                                                  

	I like that idea.
"
?

> 
> 
> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-06-13 14:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 22:48 [PATCH v2] xen/swiotlb: don't initialize swiotlb twice on arm64 Stefano Stabellini
2019-05-28 22:48 ` [Xen-devel] " Stefano Stabellini
2019-05-28 23:50 ` Boris Ostrovsky
2019-05-28 23:50   ` [Xen-devel] " Boris Ostrovsky
2019-06-03 18:25   ` Stefano Stabellini
2019-06-03 18:25     ` [Xen-devel] " Stefano Stabellini
2019-06-03 23:16     ` Boris Ostrovsky
2019-06-03 23:16       ` [Xen-devel] " Boris Ostrovsky
2019-06-04 16:51       ` Stefano Stabellini
2019-06-04 19:41         ` Boris Ostrovsky
2019-06-05 14:13           ` Konrad Rzeszutek Wilk
2019-06-05 14:24             ` Juergen Gross
2019-06-13 14:23               ` Konrad Rzeszutek Wilk [this message]
2019-06-13 15:04                 ` Juergen Gross
2019-06-13 21:00                   ` Konrad Rzeszutek Wilk
2019-06-17  8:21                     ` Christoph Hellwig

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=20190613142345.GC456@char.us.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=Julien.Grall@arm.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jgross@suse.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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.