mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Suthikulpanit, Suravee" <suravee.suthikulpanit@amd.com>
To: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org
Cc: joro@8bytes.org, joao.m.martins@oracle.com,
	boris.ostrovsky@oracle.com, jon.grimm@amd.com,
	santosh.shukla@amd.com, vasant.hegde@amd.com,
	kishon.vijayabraham@amd.com
Subject: Re: [PATCH 3/5] iommu/amd: Introduce Disable IRTE Caching Support
Date: Thu, 18 May 2023 23:04:44 +0700	[thread overview]
Message-ID: <81b4010d-d8c6-0915-2408-e6454e4d501d@amd.com> (raw)
In-Reply-To: <2d0ab154-596e-437f-1575-3d25fe421b86@oracle.com>

Hi Alejandro,

On 5/10/2023 5:47 AM, Alejandro Jimenez wrote:
> Hi Suravee,
> 
> A couple of additional comments below:
> 
> On 5/9/2023 7:16 AM, Suravee Suthikulpanit wrote:
>> An Interrupt Remapping Table (IRT) stores interrupt remapping 
>> configuration
>> for each device. In a normal operation, the AMD IOMMU caches the table
>> to optimize subsequent data accesses. This requires the IOMMU driver to
>> invalidate IRT whenever it updates the table. The invalidation process
>> includes issuing an INVALIDATE_INTERRUPT_TABLE command following by
>> a COMPLETION_WAIT command.
>>
>> However, there are cases in which the IRT is updated at a high rate.
>> For example, for IOMMU AVIC, the IRTE[IsRun] bit is updated on every
>> vcpu scheduling (i.e. amd_iommu_update_ga()). On system with large
>> amount of vcpus and VFIO PCI pass-through devices, the invalidation
>> process could potentially become a performance bottleneck.
>>
>> Introducing a new kernel boot option:
>>
>>      amd_iommu=irtcachedis
>>
>> which disables IRTE caching by setting the IRTCachedis bit in each IOMMU
>> Control register, and bypass the IRT invalidation process.
>>
>> Co-developed-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
>> [Awaiting sign-off-by Alejandro]
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>> ---
>>   .../admin-guide/kernel-parameters.txt         |  1 +
>>   drivers/iommu/amd/amd_iommu_types.h           |  4 +++
>>   drivers/iommu/amd/init.c                      | 25 +++++++++++++++++++
>>   3 files changed, 30 insertions(+)
> [snip]
>> diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
>> index fd487c33b28a..01d131e75de4 100644
>> --- a/drivers/iommu/amd/init.c
>> +++ b/drivers/iommu/amd/init.c
>> @@ -160,6 +160,7 @@ static int amd_iommu_xt_mode = IRQ_REMAP_XAPIC_MODE;
>>   static bool amd_iommu_detected;
>>   static bool amd_iommu_disabled __initdata;
>>   static bool amd_iommu_force_enable __initdata;
>> +static bool amd_iommu_irtcachedis __initdata;
> Lets drop the __initdata attribute above, since amd_iommu_irtcachedis is 
> used by early_enable_iommus(), which is in .text (causes modpost warning).

Good point.

> [snip]
>> +static void iommu_enable_irtcachedis(struct amd_iommu *iommu)
>> +{
>> +    u64 ctrl;
>> +
>> +    if (amd_iommu_irtcachedis) {
>> +        /*
>> +         * Note:
>> +         * The support for IRTCacheDis feature is dertermined by
>> +         * checking if the bit is writable.
>> +         */
>> +        iommu_feature_enable(iommu, CONTROL_IRTCACHEDIS);
>> +        ctrl = readq(iommu->mmio_base +  MMIO_CONTROL_OFFSET);
>> +        ctrl &= (1ULL << CONTROL_IRTCACHEDIS);
>> +        if (ctrl)
>> +            iommu->irtcachedis_enabled = true;
>> +        pr_info("iommu%d (%#06x) : IRT cache is %s\n",
>> +            iommu->index, iommu->devid,
>> +            iommu->irtcachedis_enabled ? "disabled" : "enabled");
>> +    }
>> +}
>> +
>>   static void early_enable_iommu(struct amd_iommu *iommu)
>>   {
>>       iommu_disable(iommu);
>> @@ -2710,6 +2732,7 @@ static void early_enable_iommu(struct amd_iommu 
>> *iommu)
>>       iommu_set_exclusion_range(iommu);
>>       iommu_enable_ga(iommu);
>>       iommu_enable_xt(iommu);
>> +    iommu_enable_irtcachedis(iommu);
>>       iommu_enable(iommu);
>>       iommu_flush_all_caches(iommu);
>>   }
> I need to understand better the code flow around kdump, and it is not 
> clear from my reading of the spec that this is required, but shouldn't 
> iommu_enable_irtcachedis() also be called in the else{} block of 
> early_enable_iommus()?

Actually, you are correct. There are a few things that I missed.

First, we need to ensure that the bit is cleared when disable the IOMMU 
when the system is shutting down. Otherwise, when we do kexec, the bit 
might still be set unintentionally.

When booting into kdump kernel, we need to evaluate the variable 
amd_iommu_irtcachedis and setup the CONTROL_IRTCACHEDIS bit in control 
register accordingly.  Otherwise, we could end up with a situation where 
the CONTROL_IRTCACHEDIS bit is inconsistent with the 
amd_iommu_irtcachedis in the kdump kernel causing the kdump kernel to 
skip IRT invalidation process when it is needed.

I'll fix this and send out v2.

Thanks,
Suravee

  reply	other threads:[~2023-05-18 16:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09 11:16 [PATCH 0/5] iommu/amd: AVIC Interrupt Remapping Improvements Suravee Suthikulpanit
2023-05-09 11:16 ` [PATCH 1/5] iommu/amd: Switch amd_iommu_update_ga() to use modify_irte_ga() Suravee Suthikulpanit
2023-05-09 11:16 ` [PATCH 2/5] iommu/amd: Remove the unused struct amd_ir_data.ref Suravee Suthikulpanit
2023-05-09 11:16 ` [PATCH 3/5] iommu/amd: Introduce Disable IRTE Caching Support Suravee Suthikulpanit
2023-05-09 22:47   ` Alejandro Jimenez
2023-05-18 16:04     ` Suthikulpanit, Suravee [this message]
2023-05-09 11:16 ` [PATCH 4/5] iommu/amd: Do not Invalidate IRT when disable IRTE caching Suravee Suthikulpanit
2023-05-09 11:16 ` [PATCH 5/5] iommu/amd: Improving Interrupt Remapping Table Invalidation Suravee Suthikulpanit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81b4010d-d8c6-0915-2408-e6454e4d501d@amd.com \
    --to=suravee.suthikulpanit@amd.com \
    --cc=alejandro.j.jimenez@oracle.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joao.m.martins@oracle.com \
    --cc=jon.grimm@amd.com \
    --cc=joro@8bytes.org \
    --cc=kishon.vijayabraham@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=santosh.shukla@amd.com \
    --cc=vasant.hegde@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®