Message ID | 20230404072742.1895252-1-jsnitsel@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2853222vqo; Tue, 4 Apr 2023 01:06:19 -0700 (PDT) X-Google-Smtp-Source: AKy350blGOes8WN0KnGAVqR2U08uk49zlp3KuEI+YvaG3kNNZoyZTMPDhjt+9B9aBsxDZqnp9H87 X-Received: by 2002:a17:906:68ca:b0:931:b4d3:fc7f with SMTP id y10-20020a17090668ca00b00931b4d3fc7fmr1617944ejr.30.1680595579141; Tue, 04 Apr 2023 01:06:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680595579; cv=none; d=google.com; s=arc-20160816; b=uYHR4r0umtrCdTAioVxJ15PbEoBF+0vzj9uFD31icahs/RrgWiQ8RGX4tBHgngtQfD HzvkAfJC1T98DvLJaOJ82Q9KGkmQxSzcm3HSo8RQZO2ppABUqaV91Qg6nEyyDZ+SmMDh CnI/2s5Ud6PhvyVUvVcAvQ56j1iup981/Tiwv1ML4dCf84VMdkLOgLsIx6eMDNpz2mtq w7p/Cg99oGI+jG2tDjSsTFxqfdKVVY0ijetxYNa+Yy+xG8xLdRHgNVzvsTlL/ykkKVjl 0qYu2QxeWURZmGfE2ze8bzvNmWgy5P+gRotKNQr987DBu+LIjOwT+BLzPfUj1nGC+zGq lwrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=/5C/yOSwsdBflA8qC2A6ywwjDfEDFy/JAgkrHH95HtM=; b=rBj4C2PkJll/GFpexReeJiSlpQf25Pd1nZscdbtYb+itR+rXPd7Rx0C8HlFlnMnmDT 3KhtOBFcRjq5OQiHG9NsO681yd3ZfMLcfvwXWun2gjh1T6ExReKuUVJu2x5gGyefAv8W cadp6vr15ajGX7u/wCmw7Q7h09Hqpx4OEE5FdsY4fuZxB01VUNxr3MvTe2WKgh+JlAyR jNX8dvoDf0bPAT91G5u0uJvj429KVeeYyBq+pWlDlc71FJ4yYAog/VlMeZabTEfLLxP2 mlxXctP5c/yAB4eUXQ9CabGunqYx4MuNc33fCK2sj31P29S1xkUqLQw58+YViReS41XS K2UA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LjjeHvTi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xo5-20020a170907bb8500b0092ff0294c61si2055365ejc.710.2023.04.04.01.05.55; Tue, 04 Apr 2023 01:06:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LjjeHvTi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233675AbjDDHer (ORCPT <rfc822;zwp10758@gmail.com> + 99 others); Tue, 4 Apr 2023 03:34:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229510AbjDDHeq (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 4 Apr 2023 03:34:46 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2BBB137 for <linux-kernel@vger.kernel.org>; Tue, 4 Apr 2023 00:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680593641; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=/5C/yOSwsdBflA8qC2A6ywwjDfEDFy/JAgkrHH95HtM=; b=LjjeHvTi6SD+pusjfiYe/9M6eXRNHCUOMPfjRYibGEIwzMXOVUm6P92IpfgVNSE1y5N9PC zb94kDaNC06xVd+dAO26UZ0w+jnynokMLPS/ZjVpg1BzmxwlRvGrSwqMcLiS/FqV5JS0Ee yP+OX3moMBM54bfLnTM4pNLx8TRdzT8= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-155-VhQV1HVlNiqg9xFomLDR7w-1; Tue, 04 Apr 2023 03:27:46 -0400 X-MC-Unique: VhQV1HVlNiqg9xFomLDR7w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7EC733C1014A; Tue, 4 Apr 2023 07:27:45 +0000 (UTC) Received: from cantor.redhat.com (unknown [10.2.16.124]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6F68A440BC; Tue, 4 Apr 2023 07:27:44 +0000 (UTC) From: Jerry Snitselaar <jsnitsel@redhat.com> To: linux-kernel@vger.kernel.org, iommu@lists.linux.dev Cc: Vasant Hegde <vasant.hegde@amd.com>, Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>, Robin Murphy <robin.murphy@arm.com>, Will Deacon <will@kernel.org>, Joerg Roedel <joro@8bytes.org> Subject: [PATCH] iommu: amd: Set page size bitmap during V2 domain allocation Date: Tue, 4 Apr 2023 00:27:42 -0700 Message-Id: <20230404072742.1895252-1-jsnitsel@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762232190017232574?= X-GMAIL-MSGID: =?utf-8?q?1762232190017232574?= |
Series |
iommu: amd: Set page size bitmap during V2 domain allocation
|
|
Commit Message
Jerry Snitselaar
April 4, 2023, 7:27 a.m. UTC
With the addition of the V2 page table support, the domain page size
bitmap needs to be set prior to iommu core setting up direct mappings
for reserved regions. When reserved regions are mapped, if this is not
done, it will be looking at the V1 page size bitmap when determining
the page size to use in iommu_pgsize(). When it gets into the actual
amd mapping code, a check of see if the page size is supported can
fail, because at that point it is checking it against the V2 page size
bitmap which only supports 4K, 2M, and 1G.
Add a check to __iommu_domain_alloc() to not override the
bitmap if it was already set by the iommu ops domain_alloc() code path.
Cc: Vasant Hegde <vasant.hegde@amd.com>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Joerg Roedel <joro@8bytes.org>
Fixes: 4db6c41f0946 ("iommu/amd: Add support for using AMD IOMMU v2 page table for DMA-API")
Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
---
drivers/iommu/amd/iommu.c | 6 ++----
drivers/iommu/iommu.c | 9 +++++++--
2 files changed, 9 insertions(+), 6 deletions(-)
Comments
On Tue, Apr 04, 2023 at 12:27:42AM -0700, Jerry Snitselaar wrote: > With the addition of the V2 page table support, the domain page size > bitmap needs to be set prior to iommu core setting up direct mappings > for reserved regions. When reserved regions are mapped, if this is not > done, it will be looking at the V1 page size bitmap when determining > the page size to use in iommu_pgsize(). When it gets into the actual > amd mapping code, a check of see if the page size is supported can > fail, because at that point it is checking it against the V2 page size > bitmap which only supports 4K, 2M, and 1G. > > Add a check to __iommu_domain_alloc() to not override the > bitmap if it was already set by the iommu ops domain_alloc() code path. > > Cc: Vasant Hegde <vasant.hegde@amd.com> > Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> > Cc: Robin Murphy <robin.murphy@arm.com> > Cc: Will Deacon <will@kernel.org> > Cc: Joerg Roedel <joro@8bytes.org> > Fixes: 4db6c41f0946 ("iommu/amd: Add support for using AMD IOMMU v2 page table for DMA-API") > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> I'm still not sure this is the best solution. Feels odd with adding a check to core code to handle something one of the drivers has done. Another thought was something like arm does, with amd_iommu_ops dropping the const and setting the default page size bitmap in iommu_init_pci(), but I think that would still require adding something in the protection domain/init code to deal with it forcing v1, so it would still require a check in the core code. Would adding an op make more sense, with a generic op doing what the core code currently does for setting the default? Or am I overthinking this? snits > --- > drivers/iommu/amd/iommu.c | 6 ++---- > drivers/iommu/iommu.c | 9 +++++++-- > 2 files changed, 9 insertions(+), 6 deletions(-) > > diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c > index 5a505ba5467e..167da5b1a5e3 100644 > --- a/drivers/iommu/amd/iommu.c > +++ b/drivers/iommu/amd/iommu.c > @@ -1666,10 +1666,6 @@ static void do_attach(struct iommu_dev_data *dev_data, > domain->dev_iommu[iommu->index] += 1; > domain->dev_cnt += 1; > > - /* Override supported page sizes */ > - if (domain->flags & PD_GIOV_MASK) > - domain->domain.pgsize_bitmap = AMD_IOMMU_PGSIZES_V2; > - > /* Update device table */ > set_dte_entry(iommu, dev_data->devid, domain, > ats, dev_data->iommu_v2); > @@ -2048,6 +2044,8 @@ static int protection_domain_init_v2(struct protection_domain *domain) > > domain->flags |= PD_GIOV_MASK; > > + domain->domain.pgsize_bitmap = AMD_IOMMU_PGSIZES_V2; > + > if (domain_enable_v2(domain, 1)) { > domain_id_free(domain->id); > return -ENOMEM; > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index 10db680acaed..256a38371120 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -1964,8 +1964,13 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus, > return NULL; > > domain->type = type; > - /* Assume all sizes by default; the driver may override this later */ > - domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap; > + /* > + * If not already set, assume all sizes by default; the driver > + * may override this later > + */ > + if (!domain->pgsize_bitmap) > + domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap; > + > if (!domain->ops) > domain->ops = bus->iommu_ops->default_domain_ops; > > -- > 2.38.1 >
Jerry, On 4/4/2023 9:58 PM, Jerry Snitselaar wrote: > On Tue, Apr 04, 2023 at 12:27:42AM -0700, Jerry Snitselaar wrote: >> With the addition of the V2 page table support, the domain page size >> bitmap needs to be set prior to iommu core setting up direct mappings >> for reserved regions. When reserved regions are mapped, if this is not >> done, it will be looking at the V1 page size bitmap when determining >> the page size to use in iommu_pgsize(). When it gets into the actual >> amd mapping code, a check of see if the page size is supported can >> fail, because at that point it is checking it against the V2 page size >> bitmap which only supports 4K, 2M, and 1G. >> >> Add a check to __iommu_domain_alloc() to not override the >> bitmap if it was already set by the iommu ops domain_alloc() code path. >> >> Cc: Vasant Hegde <vasant.hegde@amd.com> >> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> >> Cc: Robin Murphy <robin.murphy@arm.com> >> Cc: Will Deacon <will@kernel.org> >> Cc: Joerg Roedel <joro@8bytes.org> >> Fixes: 4db6c41f0946 ("iommu/amd: Add support for using AMD IOMMU v2 page table for DMA-API") >> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> > > > > I'm still not sure this is the best solution. Feels odd with adding a > check to core code to handle something one of the drivers has > done. Another thought was something like arm does, with amd_iommu_ops > dropping the const and setting the default page size bitmap in > iommu_init_pci(), but I think that would still require adding > something in the protection domain/init code to deal with it forcing > v1, so it would still require a check in the core code. > I am not familiar with how arm paging works. But in AMD case we decide the page table during protection domain allocation. Also we can have different page size for different domains. (like one domain in v1 and another in v2 page mode). > Would adding an op make more sense, with a generic op doing what the > core code currently does for setting the default? Or am I overthinking > this? IMO adding another ops is not required. I think current fix is good enough. Thanks for debugging/fixing this issue. Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> -Vasant > > snits > >> --- >> drivers/iommu/amd/iommu.c | 6 ++---- >> drivers/iommu/iommu.c | 9 +++++++-- >> 2 files changed, 9 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c >> index 5a505ba5467e..167da5b1a5e3 100644 >> --- a/drivers/iommu/amd/iommu.c >> +++ b/drivers/iommu/amd/iommu.c >> @@ -1666,10 +1666,6 @@ static void do_attach(struct iommu_dev_data *dev_data, >> domain->dev_iommu[iommu->index] += 1; >> domain->dev_cnt += 1; >> >> - /* Override supported page sizes */ >> - if (domain->flags & PD_GIOV_MASK) >> - domain->domain.pgsize_bitmap = AMD_IOMMU_PGSIZES_V2; >> - >> /* Update device table */ >> set_dte_entry(iommu, dev_data->devid, domain, >> ats, dev_data->iommu_v2); >> @@ -2048,6 +2044,8 @@ static int protection_domain_init_v2(struct protection_domain *domain) >> >> domain->flags |= PD_GIOV_MASK; >> >> + domain->domain.pgsize_bitmap = AMD_IOMMU_PGSIZES_V2; >> + >> if (domain_enable_v2(domain, 1)) { >> domain_id_free(domain->id); >> return -ENOMEM; >> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c >> index 10db680acaed..256a38371120 100644 >> --- a/drivers/iommu/iommu.c >> +++ b/drivers/iommu/iommu.c >> @@ -1964,8 +1964,13 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus, >> return NULL; >> >> domain->type = type; >> - /* Assume all sizes by default; the driver may override this later */ >> - domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap; >> + /* >> + * If not already set, assume all sizes by default; the driver >> + * may override this later >> + */ >> + if (!domain->pgsize_bitmap) >> + domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap; >> + >> if (!domain->ops) >> domain->ops = bus->iommu_ops->default_domain_ops; >> >> -- >> 2.38.1 >> >
On 04/04/2023 5:28 pm, Jerry Snitselaar wrote: > On Tue, Apr 04, 2023 at 12:27:42AM -0700, Jerry Snitselaar wrote: >> With the addition of the V2 page table support, the domain page size >> bitmap needs to be set prior to iommu core setting up direct mappings >> for reserved regions. When reserved regions are mapped, if this is not >> done, it will be looking at the V1 page size bitmap when determining >> the page size to use in iommu_pgsize(). When it gets into the actual >> amd mapping code, a check of see if the page size is supported can >> fail, because at that point it is checking it against the V2 page size >> bitmap which only supports 4K, 2M, and 1G. >> >> Add a check to __iommu_domain_alloc() to not override the >> bitmap if it was already set by the iommu ops domain_alloc() code path. >> >> Cc: Vasant Hegde <vasant.hegde@amd.com> >> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> >> Cc: Robin Murphy <robin.murphy@arm.com> >> Cc: Will Deacon <will@kernel.org> >> Cc: Joerg Roedel <joro@8bytes.org> >> Fixes: 4db6c41f0946 ("iommu/amd: Add support for using AMD IOMMU v2 page table for DMA-API") >> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> > > > > I'm still not sure this is the best solution. Feels odd with adding a > check to core code to handle something one of the drivers has > done. Another thought was something like arm does, with amd_iommu_ops > dropping the const and setting the default page size bitmap in > iommu_init_pci(), but I think that would still require adding > something in the protection domain/init code to deal with it forcing > v1, so it would still require a check in the core code. > > Would adding an op make more sense, with a generic op doing what the > core code currently does for setting the default? Or am I overthinking > this? I think this is fine as-is. TBH it's probably high time ops->pgsize_bitmap finished going away entirely - as the Arm SMMU bodges prove, it's no longer a good fit for the multi-instance model which we've evolved, and for the sake of only this one assignment now, it really doesn't seem worthwhile any more. Since I'm still reworking domain_alloc, and already have plans to clean up the horrible default_domain_ops thing (honestly, what possessed me to think that was a good idea at the time!?), I can throw pgsize_bitmap in there as well. Cheers, Robin. > > snits > >> --- >> drivers/iommu/amd/iommu.c | 6 ++---- >> drivers/iommu/iommu.c | 9 +++++++-- >> 2 files changed, 9 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c >> index 5a505ba5467e..167da5b1a5e3 100644 >> --- a/drivers/iommu/amd/iommu.c >> +++ b/drivers/iommu/amd/iommu.c >> @@ -1666,10 +1666,6 @@ static void do_attach(struct iommu_dev_data *dev_data, >> domain->dev_iommu[iommu->index] += 1; >> domain->dev_cnt += 1; >> >> - /* Override supported page sizes */ >> - if (domain->flags & PD_GIOV_MASK) >> - domain->domain.pgsize_bitmap = AMD_IOMMU_PGSIZES_V2; >> - >> /* Update device table */ >> set_dte_entry(iommu, dev_data->devid, domain, >> ats, dev_data->iommu_v2); >> @@ -2048,6 +2044,8 @@ static int protection_domain_init_v2(struct protection_domain *domain) >> >> domain->flags |= PD_GIOV_MASK; >> >> + domain->domain.pgsize_bitmap = AMD_IOMMU_PGSIZES_V2; >> + >> if (domain_enable_v2(domain, 1)) { >> domain_id_free(domain->id); >> return -ENOMEM; >> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c >> index 10db680acaed..256a38371120 100644 >> --- a/drivers/iommu/iommu.c >> +++ b/drivers/iommu/iommu.c >> @@ -1964,8 +1964,13 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus, >> return NULL; >> >> domain->type = type; >> - /* Assume all sizes by default; the driver may override this later */ >> - domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap; >> + /* >> + * If not already set, assume all sizes by default; the driver >> + * may override this later >> + */ >> + if (!domain->pgsize_bitmap) >> + domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap; >> + >> if (!domain->ops) >> domain->ops = bus->iommu_ops->default_domain_ops; >> >> -- >> 2.38.1 >> >
On Tue, Apr 04, 2023 at 12:27:42AM -0700, Jerry Snitselaar wrote: > With the addition of the V2 page table support, the domain page size > bitmap needs to be set prior to iommu core setting up direct mappings > for reserved regions. When reserved regions are mapped, if this is not > done, it will be looking at the V1 page size bitmap when determining > the page size to use in iommu_pgsize(). When it gets into the actual > amd mapping code, a check of see if the page size is supported can > fail, because at that point it is checking it against the V2 page size > bitmap which only supports 4K, 2M, and 1G. > > Add a check to __iommu_domain_alloc() to not override the > bitmap if it was already set by the iommu ops domain_alloc() code path. > > Cc: Vasant Hegde <vasant.hegde@amd.com> > Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> > Cc: Robin Murphy <robin.murphy@arm.com> > Cc: Will Deacon <will@kernel.org> > Cc: Joerg Roedel <joro@8bytes.org> > Fixes: 4db6c41f0946 ("iommu/amd: Add support for using AMD IOMMU v2 page table for DMA-API") > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> > --- > drivers/iommu/amd/iommu.c | 6 ++---- > drivers/iommu/iommu.c | 9 +++++++-- > 2 files changed, 9 insertions(+), 6 deletions(-) Applied, thanks.
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index 5a505ba5467e..167da5b1a5e3 100644 --- a/drivers/iommu/amd/iommu.c +++ b/drivers/iommu/amd/iommu.c @@ -1666,10 +1666,6 @@ static void do_attach(struct iommu_dev_data *dev_data, domain->dev_iommu[iommu->index] += 1; domain->dev_cnt += 1; - /* Override supported page sizes */ - if (domain->flags & PD_GIOV_MASK) - domain->domain.pgsize_bitmap = AMD_IOMMU_PGSIZES_V2; - /* Update device table */ set_dte_entry(iommu, dev_data->devid, domain, ats, dev_data->iommu_v2); @@ -2048,6 +2044,8 @@ static int protection_domain_init_v2(struct protection_domain *domain) domain->flags |= PD_GIOV_MASK; + domain->domain.pgsize_bitmap = AMD_IOMMU_PGSIZES_V2; + if (domain_enable_v2(domain, 1)) { domain_id_free(domain->id); return -ENOMEM; diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 10db680acaed..256a38371120 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -1964,8 +1964,13 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus, return NULL; domain->type = type; - /* Assume all sizes by default; the driver may override this later */ - domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap; + /* + * If not already set, assume all sizes by default; the driver + * may override this later + */ + if (!domain->pgsize_bitmap) + domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap; + if (!domain->ops) domain->ops = bus->iommu_ops->default_domain_ops;