Re: [PATCH v2 0/7] iommu/vt-d: Fix-up device-domain relationship by refactoring to use iommu group default domain.

From: Lu Baolu
Date: Tue Mar 19 2019 - 21:32:34 EST

Hi James,

On 3/19/19 9:35 PM, James Sewart wrote:
Hey Lu,

On 15 Mar 2019, at 03:13, Lu Baolu <> wrote:

Hi James,

On 3/14/19 7:56 PM, James Sewart wrote:
Patches 1 and 2 are the same as v1.
Refactored ISA direct mappings to be returned by iommu_get_resv_regions.
Integrated patch by Lu to defer turning on DMAR until iommu.c has mapped
reserved regions.
Integrated patches by Lu to remove more unused code in cleanup.
Lu: I didn't integrate your patch to set the default domain type as it
isn't directly related to the aim of this patchset. Instead patch 4

Without those patches, user experience will be affected and some devices
will not work on Intel platforms anymore.

For a long time, Intel IOMMU driver has its own logic to determine
whether a device requires an identity domain. For example, when user
specifies "iommu=pt" in kernel parameter, all device will be attached
with the identity domain. Further more, some quirky devices require
an identity domain to be used before enabling DMA remapping, otherwise,
it will not work. This was done by adding quirk bits in Intel IOMMU

So from my point of view, one way is porting all those quirks and kernel
parameters into IOMMU generic layer, or opening a door for vendor IOMMU
driver to determine the default domain type by their own. I prefer the
latter option since it will not impact any behaviors on other

I see your point. Iâm not confident that using the proposed door to set a
groups default domain has the desired behaviour. As discussed before the
default domain type will be set based on the desired type for only the
first device attached to a group. I think to change the default domain
type you would need a slightly different door that wasnât conditioned on

I think this as another problem. Just a summarize for the ease of
discussion. We saw two problems:

1. When allocating a new group for a device, how should we determine the
type of the default domain? This is what my proposal patches trying to

2. If we need to put a device into an existing group which uses a
different type of domain from what the device desires to use, we might
break the functionality of the device. For this problem I'd second your
proposal below if I get your point correctly.

For situations where individual devices require an identity domain because
of quirks then maybe calling is_identity_map per device in
iommu_group_get_for_dev is a better solution than the one I proposed.

Do you mean if we see a quirky device requires a different domain type
other than the default domain type of the group, we will assign a new
group to it? That looks good to me as far as I can see. I suppose this
should be done in vt-d's ops callback.

Best regards,
Lu Baolu