On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those lines or just scrap the default assignment entirely, so since I hadn't got round to saying that I've gone ahead and hacked up the alternative (similarly untested) for comparison :)
TBH I'm still not sure which one I prefer...
Claire did implement something like your suggestion originally, but I don't really like it as it doesn't scale for adding multiple global pools, e.g. for the 64-bit addressable one for the various encrypted secure guest schemes.
Couple of things: - I am not pushing to Linus the Claire's patchset until we have a resolution on this. I hope you all agree that is a sensible way forward as much as I hate doing that.
- I like Robin's fix as it is simplest looking. Would love to see if it does fix the problem.
- Christopher - we can always add multiple pools as the next milestone and just focus on this feature getting tested extensively during this release.
- Would it be worth (for future or maybe in another tiny fix) to also add a printk in swiotlb when we de-allocate the buffer so when someone looks through the `dmesg` it becomes much easier to diagnose issues?
On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those lines or just scrap the default assignment entirely, so since I hadn't got round to saying that I've gone ahead and hacked up the alternative (similarly untested) for comparison :)
TBH I'm still not sure which one I prefer...
Claire did implement something like your suggestion originally, but I don't really like it as it doesn't scale for adding multiple global pools, e.g. for the 64-bit addressable one for the various encrypted secure guest schemes.
Couple of things:
- I am not pushing to Linus the Claire's patchset until we have a resolution on this. I hope you all agree that is a sensible way forward as much as I hate doing that.
Sure, it's a pity but we could clearly use a bit more time to get these just right and we've run out of time for 5.14.
I think the main question I have is how would you like to see patches for 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
Cheers,
Will
On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote:
On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those lines or just scrap the default assignment entirely, so since I hadn't got round to saying that I've gone ahead and hacked up the alternative (similarly untested) for comparison :)
TBH I'm still not sure which one I prefer...
Claire did implement something like your suggestion originally, but I don't really like it as it doesn't scale for adding multiple global pools, e.g. for the 64-bit addressable one for the various encrypted secure guest schemes.
Couple of things:
- I am not pushing to Linus the Claire's patchset until we have a resolution on this. I hope you all agree that is a sensible way forward as much as I hate doing that.
Sure, it's a pity but we could clearly use a bit more time to get these just right and we've run out of time for 5.14.
I think the main question I have is how would you like to see patches for 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
Yes that would be perfect. If there are any dependencies on the rc1, I can rebase it on top of that.
Cheers,
Will
On Tue, Jul 06, 2021 at 12:59:57PM -0400, Konrad Rzeszutek Wilk wrote:
On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote:
On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those lines or just scrap the default assignment entirely, so since I hadn't got round to saying that I've gone ahead and hacked up the alternative (similarly untested) for comparison :)
TBH I'm still not sure which one I prefer...
Claire did implement something like your suggestion originally, but I don't really like it as it doesn't scale for adding multiple global pools, e.g. for the 64-bit addressable one for the various encrypted secure guest schemes.
Couple of things:
- I am not pushing to Linus the Claire's patchset until we have a resolution on this. I hope you all agree that is a sensible way forward as much as I hate doing that.
Sure, it's a pity but we could clearly use a bit more time to get these just right and we've run out of time for 5.14.
I think the main question I have is how would you like to see patches for 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
Yes that would be perfect. If there are any dependencies on the rc1, I can rebase it on top of that.
Yes, please, rebasing would be very helpful. The broader rework of 'io_tlb_default_mem' is going to conflict quite badly otherwise.
Cheers,
Will
..snip..
I think the main question I have is how would you like to see patches for 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
Yes that would be perfect. If there are any dependencies on the rc1, I can rebase it on top of that.
Yes, please, rebasing would be very helpful. The broader rework of 'io_tlb_default_mem' is going to conflict quite badly otherwise.
There is a devel/for-linus-5.15 (based on v5.14-rc1) now.
Thank you!
Cheers,
Will
dri-devel@lists.freedesktop.org
-
Konrad Rzeszutek Wilk -
Konrad Rzeszutek Wilk -
Will Deacon