On Wed, Jun 01, 2022 at 02:52:05PM +0100, Joao Martins wrote:
> On 6/1/22 13:33, Jason Gunthorpe wrote:
> > On Wed, Jun 01, 2022 at 01:18:52PM +0100, Joao Martins wrote:
> >
> >>> So having safe racy reading in the kernel is probably best, and so RCU
> >>> would be good here too.
> >>
> >>
On 6/1/22 13:33, Jason Gunthorpe wrote:
> On Wed, Jun 01, 2022 at 01:18:52PM +0100, Joao Martins wrote:
>
>>> So having safe racy reading in the kernel is probably best, and so RCU
>>> would be good here too.
>>
>> Reading dirties ought to be similar to map/unmap but slightly simpler as
>> I
On Wed, Jun 01, 2022 at 01:18:52PM +0100, Joao Martins wrote:
> > So having safe racy reading in the kernel is probably best, and so RCU
> > would be good here too.
>
> Reading dirties ought to be similar to map/unmap but slightly simpler as
> I supposedly don't need to care about the pte
On 6/1/22 00:10, Jason Gunthorpe wrote:
> On Tue, May 31, 2022 at 10:22:32PM +0100, Robin Murphy wrote:
>> There are only 3 instances where we'll free a table while the domain is
>> live. The first is the one legitimate race condition, where two map requests
>> targeting relatively nearby PTEs
> From: Jason Gunthorpe
> Sent: Wednesday, June 1, 2022 7:11 AM
>
> On Tue, May 31, 2022 at 10:22:32PM +0100, Robin Murphy wrote:
>
> > There are only 3 instances where we'll free a table while the domain is
> > live. The first is the one legitimate race condition, where two map requests
> >
On 2022/6/1 02:51, Jason Gunthorpe wrote:
Oh, I've spent the last couple of weeks hacking up horrible things
manipulating entries in init_mm, and never realised that that was actually
the special case. Oh well, live and learn.
The init_mm is sort of different, it doesn't have zap in quite the
On 2022/5/31 23:59, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 02:52:28PM +0100, Robin Murphy wrote:
+ break;
+ pgtable_walk_level(m, phys_to_virt(phys_addr),
Also, obligatory reminder that pfn_valid() only means that pfn_to_page()
gets you a valid struct page.
Hi Robin,
Thank you for the comments.
On 2022/5/31 21:52, Robin Murphy wrote:
On 2022-05-31 04:02, Baolu Lu wrote:
On 2022/5/30 20:14, Jason Gunthorpe wrote:
On Sun, May 29, 2022 at 01:14:46PM +0800, Baolu Lu wrote:
[--snip--]
diff --git a/drivers/iommu/intel/debugfs.c
On Tue, May 31, 2022 at 10:22:32PM +0100, Robin Murphy wrote:
> There are only 3 instances where we'll free a table while the domain is
> live. The first is the one legitimate race condition, where two map requests
> targeting relatively nearby PTEs both go to fill in an intermediate level of
>
On 2022-05-31 19:51, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 07:07:32PM +0100, Robin Murphy wrote:
And we expect the iommu driver to be unable to free page table levels
that have IOVA boundaries in them?
I'm not entirely sure what you mean there, but in general an unmap request
is
On Tue, May 31, 2022 at 07:07:32PM +0100, Robin Murphy wrote:
> > And we expect the iommu driver to be unable to free page table levels
> > that have IOVA boundaries in them?
>
> I'm not entirely sure what you mean there, but in general an unmap request
> is expected to match some previous map
On 2022-05-31 17:21, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 05:01:46PM +0100, Robin Murphy wrote:
The DMA API doesn't need locking, partly since it can trust itself not to do
stupid things, and mostly because it's DMA API performance that's
fundamentally incompatible with serialisation
On 2022-05-31 16:59, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 02:52:28PM +0100, Robin Murphy wrote:
+ break;
+ pgtable_walk_level(m, phys_to_virt(phys_addr),
Also, obligatory reminder that pfn_valid() only means that pfn_to_page()
gets you a valid struct page.
On Tue, May 31, 2022 at 05:01:46PM +0100, Robin Murphy wrote:
> The DMA API doesn't need locking, partly since it can trust itself not to do
> stupid things, and mostly because it's DMA API performance that's
> fundamentally incompatible with serialisation anyway. Why do you think we
> have a
On 2022-05-31 16:13, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 04:01:04PM +0100, Robin Murphy wrote:
On 2022-05-31 15:53, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 10:11:18PM +0800, Baolu Lu wrote:
On 2022/5/31 21:10, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 11:02:06AM +0800,
On Tue, May 31, 2022 at 02:52:28PM +0100, Robin Murphy wrote:
> > + break;
> > + pgtable_walk_level(m, phys_to_virt(phys_addr),
>
> Also, obligatory reminder that pfn_valid() only means that pfn_to_page()
> gets you a valid struct page. Whether that page is
On Tue, May 31, 2022 at 04:01:04PM +0100, Robin Murphy wrote:
> On 2022-05-31 15:53, Jason Gunthorpe wrote:
> > On Tue, May 31, 2022 at 10:11:18PM +0800, Baolu Lu wrote:
> > > On 2022/5/31 21:10, Jason Gunthorpe wrote:
> > > > On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
> > > >
> >
On 2022-05-31 15:53, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 10:11:18PM +0800, Baolu Lu wrote:
On 2022/5/31 21:10, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
For case 2, it is a bit weird. I tried to add a rwsem lock to make the
iommu_unmap() and
On Tue, May 31, 2022 at 10:11:18PM +0800, Baolu Lu wrote:
> On 2022/5/31 21:10, Jason Gunthorpe wrote:
> > On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
> >
> > > For case 2, it is a bit weird. I tried to add a rwsem lock to make the
> > > iommu_unmap() and dumping tables in debugfs
On 2022/5/31 21:10, Jason Gunthorpe wrote:
On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
For case 2, it is a bit weird. I tried to add a rwsem lock to make the
iommu_unmap() and dumping tables in debugfs exclusive. This does not
work because debugfs may depend on the DMA of the
On 2022-05-31 04:02, Baolu Lu wrote:
On 2022/5/30 20:14, Jason Gunthorpe wrote:
On Sun, May 29, 2022 at 01:14:46PM +0800, Baolu Lu wrote:
From 1e87b5df40c6ce9414cdd03988c3b52bfb17af5f Mon Sep 17 00:00:00 2001
From: Lu Baolu
Date: Sun, 29 May 2022 10:18:56 +0800
Subject: [PATCH 1/1]
On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
> For case 2, it is a bit weird. I tried to add a rwsem lock to make the
> iommu_unmap() and dumping tables in debugfs exclusive. This does not
> work because debugfs may depend on the DMA of the devices to work. It
> seems that what we
On 2022/5/30 20:14, Jason Gunthorpe wrote:
On Sun, May 29, 2022 at 01:14:46PM +0800, Baolu Lu wrote:
From 1e87b5df40c6ce9414cdd03988c3b52bfb17af5f Mon Sep 17 00:00:00 2001
From: Lu Baolu
Date: Sun, 29 May 2022 10:18:56 +0800
Subject: [PATCH 1/1] iommu/vt-d: debugfs: Remove device_domain_lock
On Sun, May 29, 2022 at 01:14:46PM +0800, Baolu Lu wrote:
> From 1e87b5df40c6ce9414cdd03988c3b52bfb17af5f Mon Sep 17 00:00:00 2001
> From: Lu Baolu
> Date: Sun, 29 May 2022 10:18:56 +0800
> Subject: [PATCH 1/1] iommu/vt-d: debugfs: Remove device_domain_lock usage
>
> The
On 2022/5/27 22:59, Jason Gunthorpe wrote:
On Fri, May 27, 2022 at 02:30:08PM +0800, Lu Baolu wrote:
Retrieve the attached domain for a device through the generic interface
exposed by the iommu core. This also makes device_domain_lock static.
Signed-off-by: Lu Baolu
On Fri, May 27, 2022 at 02:30:08PM +0800, Lu Baolu wrote:
> Retrieve the attached domain for a device through the generic interface
> exposed by the iommu core. This also makes device_domain_lock static.
>
> Signed-off-by: Lu Baolu
> drivers/iommu/intel/iommu.h | 1 -
>
26 matches
Mail list logo
