* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-08-23 20:28 ` Jason Gunthorpe
@ 2022-08-23 21:01 ` Robin Murphy
2022-08-24 0:02 ` Jason Gunthorpe
2022-09-06 15:41 ` Jason Gunthorpe
2022-09-07 13:28 ` Takashi Iwai
2 siblings, 1 reply; 19+ messages in thread
From: Robin Murphy @ 2022-08-23 21:01 UTC (permalink / raw)
To: Jason Gunthorpe, Takashi Iwai
Cc: Lu Baolu, Joerg Roedel, Greg Kroah-Hartman, Bjorn Helgaas,
Eric Auger, regressions, linux-kernel
On 2022-08-23 21:28, Jason Gunthorpe wrote:
> On Tue, Aug 23, 2022 at 01:46:36PM +0200, Takashi Iwai wrote:
>> It was tested now and confirmed that the call path is via AMDGPU, as
>> expected:
>> amdgpu_pci_probe ->
>> amdgpu_driver_load_kms ->
>> amdgpu_device_init ->
>> amdgpu_amdkfd_device_init ->
>> kgd2kfd_device_init ->
>> kgd2kfd_resume_iommu ->
>> kfd_iommu_resume ->
>> amd_iommu_init_device ->
>> iommu_attach_group ->
>> __iommu_attach_group
>
> Oh, when you said sound intel I thought this was an Intel CPU..
>
> Yes, there is this hacky private path from the amdgpu to
> the amd iommu driver that makes a mess of it here. We discussed it in
> this thread:
>
> https://lore.kernel.org/linux-iommu/YgtuJQhY8SNlv9%2F6@8bytes.org/
>
> But nobody put it together that it would be a problem with this.
>
> Something like this, perhaps, but I didn't check if overriding the
> type would cause other problems.
>
> diff --git a/drivers/iommu/amd/iommu_v2.c b/drivers/iommu/amd/iommu_v2.c
> index 696d5555be5794..6a1f02c62dffcc 100644
> --- a/drivers/iommu/amd/iommu_v2.c
> +++ b/drivers/iommu/amd/iommu_v2.c
> @@ -777,6 +777,8 @@ int amd_iommu_init_device(struct pci_dev *pdev, int pasids)
> if (dev_state->domain == NULL)
> goto out_free_states;
>
> + /* See iommu_is_default_domain() */
> + dev_state->domain->type = IOMMU_DOMAIN_IDENTITY;
> amd_iommu_domain_direct_map(dev_state->domain);
Same question as 6 months ago, apparently: allocating an unmanaged
domain with a pagetable then sucking out the pagetable is silly enough,
but if we're going to then also call it a proper identity domain, we
should really just allocate an identity domain directly; but then why
not just enable_v2 on the identity domain that we know is already there
courtesy of def_domain_type?
Robin.
Intentional whitespace-damaged patch based on wrong kernel version to
stress how much it is for illustration purposes only:
----->8-----
diff --git a/drivers/iommu/amd/iommu_v2.c b/drivers/iommu/amd/iommu_v2.c
index fb61bdca4c2c..2925103cd71a 100644
--- a/drivers/iommu/amd/iommu_v2.c
+++ b/drivers/iommu/amd/iommu_v2.c
@@ -135,9 +135,6 @@ static void free_device_state(struct device_state
*dev_state)
iommu_group_put(group);
- /* Everything is down now, free the IOMMUv2 domain */
- iommu_domain_free(dev_state->domain);
-
/* Finally get rid of the device-state */
kfree(dev_state);
}
@@ -730,7 +727,6 @@ EXPORT_SYMBOL(amd_iommu_unbind_pasid);
int amd_iommu_init_device(struct pci_dev *pdev, int pasids)
{
struct device_state *dev_state;
- struct iommu_group *group;
unsigned long flags;
int ret, tmp;
u16 devid;
@@ -773,34 +769,20 @@ int amd_iommu_init_device(struct pci_dev *pdev,
int pasids)
if (dev_state->states == NULL)
goto out_free_dev_state;
- dev_state->domain = iommu_domain_alloc(&pci_bus_type);
- if (dev_state->domain == NULL)
+ dev_state->domain = iommu_get_domain_for_dev(&pdev->dev);
+ if (dev_state->domain->type != IOMMU_DOMAIN_IDENTITY)
goto out_free_states;
- amd_iommu_domain_direct_map(dev_state->domain);
-
ret = amd_iommu_domain_enable_v2(dev_state->domain, pasids);
if (ret)
- goto out_free_domain;
-
- group = iommu_group_get(&pdev->dev);
- if (!group) {
- ret = -EINVAL;
- goto out_free_domain;
- }
-
- ret = iommu_attach_group(dev_state->domain, group);
- if (ret != 0)
- goto out_drop_group;
-
- iommu_group_put(group);
+ goto out_free_states;
spin_lock_irqsave(&state_lock, flags);
if (__get_device_state(devid) != NULL) {
spin_unlock_irqrestore(&state_lock, flags);
ret = -EBUSY;
- goto out_free_domain;
+ goto out_free_states;
}
list_add_tail(&dev_state->list, &state_list);
@@ -809,12 +791,6 @@ int amd_iommu_init_device(struct pci_dev *pdev, int
pasids)
return 0;
-out_drop_group:
- iommu_group_put(group);
-
-out_free_domain:
- iommu_domain_free(dev_state->domain);
-
out_free_states:
free_page((unsigned long)dev_state->states);
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-08-23 21:01 ` Robin Murphy
@ 2022-08-24 0:02 ` Jason Gunthorpe
0 siblings, 0 replies; 19+ messages in thread
From: Jason Gunthorpe @ 2022-08-24 0:02 UTC (permalink / raw)
To: Robin Murphy
Cc: Takashi Iwai, Lu Baolu, Joerg Roedel, Greg Kroah-Hartman,
Bjorn Helgaas, Eric Auger, regressions, linux-kernel,
Suravee Suthikulpanit, Felix Kuehling, amd-gfx, Alex Deucher,
Christian König, Pan, Xinhui
On Tue, Aug 23, 2022 at 10:01:57PM +0100, Robin Murphy wrote:
> > diff --git a/drivers/iommu/amd/iommu_v2.c b/drivers/iommu/amd/iommu_v2.c
> > index 696d5555be5794..6a1f02c62dffcc 100644
> > --- a/drivers/iommu/amd/iommu_v2.c
> > +++ b/drivers/iommu/amd/iommu_v2.c
> > @@ -777,6 +777,8 @@ int amd_iommu_init_device(struct pci_dev *pdev, int pasids)
> > if (dev_state->domain == NULL)
> > goto out_free_states;
> > + /* See iommu_is_default_domain() */
> > + dev_state->domain->type = IOMMU_DOMAIN_IDENTITY;
> > amd_iommu_domain_direct_map(dev_state->domain);
>
> Same question as 6 months ago, apparently: allocating an unmanaged domain
> with a pagetable then sucking out the pagetable is silly enough, but if
> we're going to then also call it a proper identity domain, we should really
> just allocate an identity domain directly; but then why not just enable_v2
> on the identity domain that we know is already there courtesy of
> def_domain_type?
Yeah, nobody who knows this code answered that question either..
Looking at it a bit, I think this comment will start to be a problem:
/*
* Save us all sanity checks whether devices already in the
* domain support IOMMUv2. Just force that the domain has no
* devices attached when it is switched into IOMMUv2 mode.
*/
ret = -EBUSY;
if (domain->dev_cnt > 0 || domain->flags & PD_IOMMUV2_MASK)
goto out;
Beacuse we should have dev_cnt != 0 on the existing identity domain at
this point - worse if the probe order is backwards the sound driver
may even already be running when we reach this.
Plus the challenge of undoing it when the PASID user goes away.
Overall I can see how it is easier and more logical to transition
between two domains. We already have good infrastructure for doing
that.
From a core perspective I don't have a real problem with iommu drivers
using multiple iommu_domains to manage their internal operations, eg
for different operating modes. But you are right that it should be
cleaner and directly allocate the special domains it needs. This would
be much more self-descriptive if it called a function 'allocate v2
identity domain', for instance.
I think it would also make sense for the core to provide some API to
change the default domain (ie dma API domain) of a group, and that
would be a more logical, and self explanatory, API for iommu drivers
to use than attach/detach. ie:
iommu_change_default_domain(group, amd_identity_domain_v2):
iommu_change_default_domain(group, amd_identity_domain_v1):
At least for this effort I wanted something simple enough to backport
that maybe doesn't need to be an expert in the amd iommu to write..
[I checked some more and the hack to change the type looks like it is
OK on the free path, so maybe this even works]
My general hope is that we can convince AMD to work on this once the
generic PASID & PRI series lands, as this entire private path to the
GPU driver and non-standard PASID handling all needs to be aligned
with the upcoming core code. When doing that work it would make sense
to tidy and modernize this better. I added a bunch of AMD people to
this thread to that end. It sure would be good if AMD participated in
that series since they are going to have to use it too.
https://lore.kernel.org/linux-iommu/20220817012024.3251276-1-baolu.lu@linux.intel.com/
Regards,
Jason
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-08-23 20:28 ` Jason Gunthorpe
2022-08-23 21:01 ` Robin Murphy
@ 2022-09-06 15:41 ` Jason Gunthorpe
2022-09-06 15:52 ` Takashi Iwai
2022-09-07 13:28 ` Takashi Iwai
2 siblings, 1 reply; 19+ messages in thread
From: Jason Gunthorpe @ 2022-09-06 15:41 UTC (permalink / raw)
To: Takashi Iwai
Cc: Lu Baolu, Joerg Roedel, Greg Kroah-Hartman, Bjorn Helgaas,
Robin Murphy, Eric Auger, regressions, linux-kernel
On Tue, Aug 23, 2022 at 05:28:24PM -0300, Jason Gunthorpe wrote:
> On Tue, Aug 23, 2022 at 01:46:36PM +0200, Takashi Iwai wrote:
> > It was tested now and confirmed that the call path is via AMDGPU, as
> > expected:
> > amdgpu_pci_probe ->
> > amdgpu_driver_load_kms ->
> > amdgpu_device_init ->
> > amdgpu_amdkfd_device_init ->
> > kgd2kfd_device_init ->
> > kgd2kfd_resume_iommu ->
> > kfd_iommu_resume ->
> > amd_iommu_init_device ->
> > iommu_attach_group ->
> > __iommu_attach_group
>
> Oh, when you said sound intel I thought this was an Intel CPU..
>
> Yes, there is this hacky private path from the amdgpu to
> the amd iommu driver that makes a mess of it here. We discussed it in
> this thread:
>
> https://lore.kernel.org/linux-iommu/YgtuJQhY8SNlv9%2F6@8bytes.org/
>
> But nobody put it together that it would be a problem with this.
>
> Something like this, perhaps, but I didn't check if overriding the
> type would cause other problems.
Takashi, do we want to do this patch?
Thanks,
Jason
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-09-06 15:41 ` Jason Gunthorpe
@ 2022-09-06 15:52 ` Takashi Iwai
2022-09-06 15:53 ` Jason Gunthorpe
0 siblings, 1 reply; 19+ messages in thread
From: Takashi Iwai @ 2022-09-06 15:52 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Takashi Iwai, Lu Baolu, Joerg Roedel, Greg Kroah-Hartman,
Bjorn Helgaas, Robin Murphy, Eric Auger, regressions,
linux-kernel
On Tue, 06 Sep 2022 17:41:51 +0200,
Jason Gunthorpe wrote:
>
> On Tue, Aug 23, 2022 at 05:28:24PM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 23, 2022 at 01:46:36PM +0200, Takashi Iwai wrote:
> > > It was tested now and confirmed that the call path is via AMDGPU, as
> > > expected:
> > > amdgpu_pci_probe ->
> > > amdgpu_driver_load_kms ->
> > > amdgpu_device_init ->
> > > amdgpu_amdkfd_device_init ->
> > > kgd2kfd_device_init ->
> > > kgd2kfd_resume_iommu ->
> > > kfd_iommu_resume ->
> > > amd_iommu_init_device ->
> > > iommu_attach_group ->
> > > __iommu_attach_group
> >
> > Oh, when you said sound intel I thought this was an Intel CPU..
> >
> > Yes, there is this hacky private path from the amdgpu to
> > the amd iommu driver that makes a mess of it here. We discussed it in
> > this thread:
> >
> > https://lore.kernel.org/linux-iommu/YgtuJQhY8SNlv9%2F6@8bytes.org/
> >
> > But nobody put it together that it would be a problem with this.
> >
> > Something like this, perhaps, but I didn't check if overriding the
> > type would cause other problems.
>
> Takashi, do we want to do this patch?
I really have no much preference regarding the fix for this
regression from my side. If you can work on it, it'd be greatly
appreciated.
thanks,
Takashi
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-09-06 15:52 ` Takashi Iwai
@ 2022-09-06 15:53 ` Jason Gunthorpe
2022-09-06 16:04 ` Takashi Iwai
0 siblings, 1 reply; 19+ messages in thread
From: Jason Gunthorpe @ 2022-09-06 15:53 UTC (permalink / raw)
To: Takashi Iwai
Cc: Lu Baolu, Joerg Roedel, Greg Kroah-Hartman, Bjorn Helgaas,
Robin Murphy, Eric Auger, regressions, linux-kernel
On Tue, Sep 06, 2022 at 05:52:34PM +0200, Takashi Iwai wrote:
> On Tue, 06 Sep 2022 17:41:51 +0200,
> Jason Gunthorpe wrote:
> >
> > On Tue, Aug 23, 2022 at 05:28:24PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Aug 23, 2022 at 01:46:36PM +0200, Takashi Iwai wrote:
> > > > It was tested now and confirmed that the call path is via AMDGPU, as
> > > > expected:
> > > > amdgpu_pci_probe ->
> > > > amdgpu_driver_load_kms ->
> > > > amdgpu_device_init ->
> > > > amdgpu_amdkfd_device_init ->
> > > > kgd2kfd_device_init ->
> > > > kgd2kfd_resume_iommu ->
> > > > kfd_iommu_resume ->
> > > > amd_iommu_init_device ->
> > > > iommu_attach_group ->
> > > > __iommu_attach_group
> > >
> > > Oh, when you said sound intel I thought this was an Intel CPU..
> > >
> > > Yes, there is this hacky private path from the amdgpu to
> > > the amd iommu driver that makes a mess of it here. We discussed it in
> > > this thread:
> > >
> > > https://lore.kernel.org/linux-iommu/YgtuJQhY8SNlv9%2F6@8bytes.org/
> > >
> > > But nobody put it together that it would be a problem with this.
> > >
> > > Something like this, perhaps, but I didn't check if overriding the
> > > type would cause other problems.
> >
> > Takashi, do we want to do this patch?
>
> I really have no much preference regarding the fix for this
> regression from my side. If you can work on it, it'd be greatly
> appreciated.
If you say this patch works I will formally propose it, but I have no
ability to test on this special AMD HW.
Thanks,
Jason
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-09-06 15:53 ` Jason Gunthorpe
@ 2022-09-06 16:04 ` Takashi Iwai
2022-09-06 16:08 ` Jason Gunthorpe
0 siblings, 1 reply; 19+ messages in thread
From: Takashi Iwai @ 2022-09-06 16:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Takashi Iwai, Lu Baolu, Joerg Roedel, Greg Kroah-Hartman,
Bjorn Helgaas, Robin Murphy, Eric Auger, regressions,
linux-kernel
On Tue, 06 Sep 2022 17:53:44 +0200,
Jason Gunthorpe wrote:
>
> On Tue, Sep 06, 2022 at 05:52:34PM +0200, Takashi Iwai wrote:
> > On Tue, 06 Sep 2022 17:41:51 +0200,
> > Jason Gunthorpe wrote:
> > >
> > > On Tue, Aug 23, 2022 at 05:28:24PM -0300, Jason Gunthorpe wrote:
> > > > On Tue, Aug 23, 2022 at 01:46:36PM +0200, Takashi Iwai wrote:
> > > > > It was tested now and confirmed that the call path is via AMDGPU, as
> > > > > expected:
> > > > > amdgpu_pci_probe ->
> > > > > amdgpu_driver_load_kms ->
> > > > > amdgpu_device_init ->
> > > > > amdgpu_amdkfd_device_init ->
> > > > > kgd2kfd_device_init ->
> > > > > kgd2kfd_resume_iommu ->
> > > > > kfd_iommu_resume ->
> > > > > amd_iommu_init_device ->
> > > > > iommu_attach_group ->
> > > > > __iommu_attach_group
> > > >
> > > > Oh, when you said sound intel I thought this was an Intel CPU..
> > > >
> > > > Yes, there is this hacky private path from the amdgpu to
> > > > the amd iommu driver that makes a mess of it here. We discussed it in
> > > > this thread:
> > > >
> > > > https://lore.kernel.org/linux-iommu/YgtuJQhY8SNlv9%2F6@8bytes.org/
> > > >
> > > > But nobody put it together that it would be a problem with this.
> > > >
> > > > Something like this, perhaps, but I didn't check if overriding the
> > > > type would cause other problems.
> > >
> > > Takashi, do we want to do this patch?
> >
> > I really have no much preference regarding the fix for this
> > regression from my side. If you can work on it, it'd be greatly
> > appreciated.
>
> If you say this patch works I will formally propose it, but I have no
> ability to test on this special AMD HW.
Erm, it's not clear which patch you're referring to. The mentioned
URL points to a patch series.
If you can send (or point) a patch for test, I can set up a test
kernel and ask reporters for testing it.
thanks,
Takashi
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-09-06 16:04 ` Takashi Iwai
@ 2022-09-06 16:08 ` Jason Gunthorpe
2022-09-06 16:16 ` Takashi Iwai
0 siblings, 1 reply; 19+ messages in thread
From: Jason Gunthorpe @ 2022-09-06 16:08 UTC (permalink / raw)
To: Takashi Iwai
Cc: Lu Baolu, Joerg Roedel, Greg Kroah-Hartman, Bjorn Helgaas,
Robin Murphy, Eric Auger, regressions, linux-kernel
On Tue, Sep 06, 2022 at 06:04:27PM +0200, Takashi Iwai wrote:
> If you can send (or point) a patch for test, I can set up a test
> kernel and ask reporters for testing it.
https://lore.kernel.org/all/20220823202824.GA4516@nvidia.com/
Jason
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-09-06 16:08 ` Jason Gunthorpe
@ 2022-09-06 16:16 ` Takashi Iwai
2022-09-07 10:08 ` Takashi Iwai
0 siblings, 1 reply; 19+ messages in thread
From: Takashi Iwai @ 2022-09-06 16:16 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Takashi Iwai, Lu Baolu, Joerg Roedel, Greg Kroah-Hartman,
Bjorn Helgaas, Robin Murphy, Eric Auger, regressions,
linux-kernel
On Tue, 06 Sep 2022 18:08:50 +0200,
Jason Gunthorpe wrote:
>
> On Tue, Sep 06, 2022 at 06:04:27PM +0200, Takashi Iwai wrote:
>
> > If you can send (or point) a patch for test, I can set up a test
> > kernel and ask reporters for testing it.
>
> https://lore.kernel.org/all/20220823202824.GA4516@nvidia.com/
Ah, that one!
OK, will ask the reporters with a test kernel with that patch.
thanks,
Takashi
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-09-06 16:16 ` Takashi Iwai
@ 2022-09-07 10:08 ` Takashi Iwai
0 siblings, 0 replies; 19+ messages in thread
From: Takashi Iwai @ 2022-09-07 10:08 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Takashi Iwai, Lu Baolu, Joerg Roedel, Greg Kroah-Hartman,
Bjorn Helgaas, Robin Murphy, Eric Auger, regressions,
linux-kernel
On Tue, 06 Sep 2022 18:16:50 +0200,
Takashi Iwai wrote:
>
> On Tue, 06 Sep 2022 18:08:50 +0200,
> Jason Gunthorpe wrote:
> >
> > On Tue, Sep 06, 2022 at 06:04:27PM +0200, Takashi Iwai wrote:
> >
> > > If you can send (or point) a patch for test, I can set up a test
> > > kernel and ask reporters for testing it.
> >
> > https://lore.kernel.org/all/20220823202824.GA4516@nvidia.com/
>
> Ah, that one!
>
> OK, will ask the reporters with a test kernel with that patch.
According to both reporters, unfortunately it caused a hang at boot
somewhere. Only the reset button helped.
Takashi
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-08-23 20:28 ` Jason Gunthorpe
2022-08-23 21:01 ` Robin Murphy
2022-09-06 15:41 ` Jason Gunthorpe
@ 2022-09-07 13:28 ` Takashi Iwai
2022-09-07 13:48 ` Jason Gunthorpe
2 siblings, 1 reply; 19+ messages in thread
From: Takashi Iwai @ 2022-09-07 13:28 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Takashi Iwai, Lu Baolu, Joerg Roedel, Greg Kroah-Hartman,
Bjorn Helgaas, Robin Murphy, Eric Auger, regressions,
linux-kernel
On Tue, 23 Aug 2022 22:28:24 +0200,
Jason Gunthorpe wrote:
>
> On Tue, Aug 23, 2022 at 01:46:36PM +0200, Takashi Iwai wrote:
> > It was tested now and confirmed that the call path is via AMDGPU, as
> > expected:
> > amdgpu_pci_probe ->
> > amdgpu_driver_load_kms ->
> > amdgpu_device_init ->
> > amdgpu_amdkfd_device_init ->
> > kgd2kfd_device_init ->
> > kgd2kfd_resume_iommu ->
> > kfd_iommu_resume ->
> > amd_iommu_init_device ->
> > iommu_attach_group ->
> > __iommu_attach_group
>
> Oh, when you said sound intel I thought this was an Intel CPU..
>
> Yes, there is this hacky private path from the amdgpu to
> the amd iommu driver that makes a mess of it here. We discussed it in
> this thread:
>
> https://lore.kernel.org/linux-iommu/YgtuJQhY8SNlv9%2F6@8bytes.org/
>
> But nobody put it together that it would be a problem with this.
>
> Something like this, perhaps, but I didn't check if overriding the
> type would cause other problems.
>
> diff --git a/drivers/iommu/amd/iommu_v2.c b/drivers/iommu/amd/iommu_v2.c
> index 696d5555be5794..6a1f02c62dffcc 100644
> --- a/drivers/iommu/amd/iommu_v2.c
> +++ b/drivers/iommu/amd/iommu_v2.c
> @@ -777,6 +777,8 @@ int amd_iommu_init_device(struct pci_dev *pdev, int pasids)
> if (dev_state->domain == NULL)
> goto out_free_states;
>
> + /* See iommu_is_default_domain() */
> + dev_state->domain->type = IOMMU_DOMAIN_IDENTITY;
> amd_iommu_domain_direct_map(dev_state->domain);
>
> ret = amd_iommu_domain_enable_v2(dev_state->domain, pasids);
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 780fb70715770d..fe8bd17f52314b 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -3076,6 +3076,24 @@ static ssize_t iommu_group_store_type(struct iommu_group *group,
> return ret;
> }
>
> +static bool iommu_is_default_domain(struct iommu_group *group)
> +{
> + if (group->domain == group->default_domain)
> + return true;
> +
> + /*
> + * If the default domain was set to identity and it is still an identity
> + * domain then we consider this a pass. This happens because of
> + * amd_iommu_init_device() replacing the default idenity domain with an
> + * identity domain that has a different configuration for AMDGPU.
> + */
> + if (group->default_domain &&
> + group->default_domain->type == IOMMU_DOMAIN_IDENTITY &&
> + group->domain && group->domain->type == IOMMU_DOMAIN_IDENTITY)
> + return true;
> + return false;
> +}
> +
> /**
> * iommu_device_use_default_domain() - Device driver wants to handle device
> * DMA through the kernel DMA API.
> @@ -3094,8 +3112,7 @@ int iommu_device_use_default_domain(struct device *dev)
>
> mutex_lock(&group->mutex);
> if (group->owner_cnt) {
> - if (group->domain != group->default_domain ||
> - group->owner) {
> + if (group->owner || iommu_is_default_domain(group)) {
Isn't this rather
if (group->owner || !iommu_is_default_domain(group)) {
?
I'll rebuild the kernel with this change and ask reporters again.
Takashi
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-09-07 13:28 ` Takashi Iwai
@ 2022-09-07 13:48 ` Jason Gunthorpe
2022-09-08 6:23 ` Takashi Iwai
0 siblings, 1 reply; 19+ messages in thread
From: Jason Gunthorpe @ 2022-09-07 13:48 UTC (permalink / raw)
To: Takashi Iwai
Cc: Lu Baolu, Joerg Roedel, Greg Kroah-Hartman, Bjorn Helgaas,
Robin Murphy, Eric Auger, regressions, linux-kernel
On Wed, Sep 07, 2022 at 03:28:31PM +0200, Takashi Iwai wrote:
> > /**
> > * iommu_device_use_default_domain() - Device driver wants to handle device
> > * DMA through the kernel DMA API.
> > @@ -3094,8 +3112,7 @@ int iommu_device_use_default_domain(struct device *dev)
> >
> > mutex_lock(&group->mutex);
> > if (group->owner_cnt) {
> > - if (group->domain != group->default_domain ||
> > - group->owner) {
> > + if (group->owner || iommu_is_default_domain(group)) {
>
> Isn't this rather
> if (group->owner || !iommu_is_default_domain(group)) {
> ?
>
> I'll rebuild the kernel with this change and ask reporters again.
Oh yes, good eyes, that probably crashes on boot too
Jason
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [REGRESSION 5.19.x] AMD HD-audio devices missing on 5.19
2022-09-07 13:48 ` Jason Gunthorpe
@ 2022-09-08 6:23 ` Takashi Iwai
0 siblings, 0 replies; 19+ messages in thread
From: Takashi Iwai @ 2022-09-08 6:23 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Takashi Iwai, Lu Baolu, Joerg Roedel, Greg Kroah-Hartman,
Bjorn Helgaas, Robin Murphy, Eric Auger, regressions,
linux-kernel
On Wed, 07 Sep 2022 15:48:33 +0200,
Jason Gunthorpe wrote:
>
> On Wed, Sep 07, 2022 at 03:28:31PM +0200, Takashi Iwai wrote:
> > > /**
> > > * iommu_device_use_default_domain() - Device driver wants to handle device
> > > * DMA through the kernel DMA API.
> > > @@ -3094,8 +3112,7 @@ int iommu_device_use_default_domain(struct device *dev)
> > >
> > > mutex_lock(&group->mutex);
> > > if (group->owner_cnt) {
> > > - if (group->domain != group->default_domain ||
> > > - group->owner) {
> > > + if (group->owner || iommu_is_default_domain(group)) {
> >
> > Isn't this rather
> > if (group->owner || !iommu_is_default_domain(group)) {
> > ?
> >
> > I'll rebuild the kernel with this change and ask reporters again.
>
> Oh yes, good eyes, that probably crashes on boot too
Indeed the corrected patch seems working; it boots and the HD-audio
device appears again.
Can we go forward with this?
thanks,
Takashi
^ permalink raw reply [flat|nested] 19+ messages in thread