[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <25e2e7fa-487c-f951-4b2c-27bac5e30815@linux.intel.com>
Date: Sun, 19 Jan 2020 14:29:17 +0800
From: Lu Baolu <baolu.lu@...ux.intel.com>
To: Joerg Roedel <joro@...tes.org>
Cc: baolu.lu@...ux.intel.com,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Bjorn Helgaas <bhelgaas@...gle.com>, ashok.raj@...el.com,
jacob.jun.pan@...el.com, kevin.tian@...el.com,
Christoph Hellwig <hch@....de>,
Robin Murphy <robin.murphy@....com>,
iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 3/4] iommu: Preallocate iommu group when probing
devices
Hi Joerg,
On 1/17/20 6:21 PM, Joerg Roedel wrote:
> On Wed, Jan 01, 2020 at 01:26:47PM +0800, Lu Baolu wrote:
>> This splits iommu group allocation from adding devices. This makes
>> it possible to determine the default domain type for each group as
>> all devices belonging to the group have been determined.
>
> I think its better to keep group allocation as it is and just defer
> default domain allocation after each device is in its group. But take
I tried defering default domain allocation, but it seems not possible.
The call path of adding devices into their groups:
iommu_probe_device
-> ops->add_device(dev)
-> (iommu vendor driver) iommu_group_get_for_dev(dev)
After doing this, the vendor driver will get the default domain and
apply dma_ops according to the domain type. If we defer the domain
allocation, they will get a NULL default domain and cause panic in
the vendor driver.
Any suggestions?
Best regards,
baolu
> care about the device hotplug path which might add new devices to groups
> which already have a default domain, or add new groups that might need a
> default domain too.
Powered by blists - more mailing lists