From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: pbonzini@redhat.com, joro@8bytes.org, bp@alien8.de,
gleb@kernel.org, alex.williamson@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, wei@redhat.com,
sherry.hurwitz@amd.com
Subject: Re: [PART2 RFC v1 5/9] iommu/amd: Introduce amd_iommu_update_ga()
Date: Wed, 13 Apr 2016 19:06:01 +0200 [thread overview]
Message-ID: <20160413170601.GA18429@potion.brq.redhat.com> (raw)
In-Reply-To: <1460119770-2896-6-git-send-email-Suravee.Suthikulpanit@amd.com>
2016-04-08 07:49-0500, Suravee Suthikulpanit:
> From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>
> This patch introduces a new IOMMU interface, amd_iommu_update_ga(),
> which allows KVM (SVM) to update existing posted interrupt IOMMU IRTE when
> load/unload vcpu.
>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> @@ -4330,4 +4330,74 @@ int amd_iommu_create_irq_domain(struct amd_iommu *iommu)
> +int amd_iommu_update_ga(u32 vcpu_id, u32 cpu, u32 ga_tag,
It'd be nicer to generate the tag on SVM side and pass it whole -- IOMMU
doesn't have to care how hypervisors use the tag.
> + u64 base, bool is_run)
> +{
> + unsigned long flags;
> + struct amd_iommu *iommu;
> +
> + if (amd_iommu_guest_ir < AMD_IOMMU_GUEST_IR_GA)
> + return 0;
> +
> + for_each_iommu(iommu) {
> + struct amd_ir_data *ir_data;
> +
> + spin_lock_irqsave(&iommu->ga_hash_lock, flags);
> +
> + hash_for_each_possible(iommu->ga_hash, ir_data, hnode,
> + AMD_IOMMU_GATAG(ga_tag, vcpu_id)) {
All tags can map into the same bucket. Code below doesn't check that
the ir_data belongs to the tag and will modify unrelated IRTEs.
Have you considered a per-VCPU list of IRTEs on the SVM side?
> + struct iommu_dev_data *dev_data;
> + if (!ir_data)
(ir_data can't be NULL.)
> + break;
> +
> + dev_data = search_dev_data(ir_data->irq_2_irte.devid);
> +
> + if (!dev_data || !dev_data->guest_mode)
> + continue;
(guest_mode can be also read from the irte.)
> + set_irte_ga(iommu, ir_data->irq_2_irte.devid,
> + base, cpu, is_run);
set_irte_ga() is pretty expensive -- do we need to invalidate the irt
when changing cpu and is_run?
2.2.5.2 Interrupt Virtualization Tables with Guest Virtual APIC Enabled,
point 9, bullet 5 says that IRTE is read from memory before considering
IsRun, GATag and Destination, which makes me think that avoiding races
can be faster in the common case.
next prev parent reply other threads:[~2016-04-13 17:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-08 12:49 [PART2 RFC v1 0/9] iommu/AMD: Introduce IOMMU AVIC support Suravee Suthikulpanit
2016-04-08 12:49 ` [PART2 RFC v1 1/9] iommu/amd: Detect and enable guest vAPIC support Suravee Suthikulpanit
2016-05-09 11:49 ` Joerg Roedel
2016-06-02 20:38 ` Suravee Suthikulanit
2016-04-08 12:49 ` [PART2 RFC v1 2/9] iommu/amd: Add data structure for " Suravee Suthikulpanit
2016-04-08 12:49 ` [PART2 RFC v1 3/9] iommu/amd: Detect and initialize guest vAPIC log Suravee Suthikulpanit
2016-04-08 12:49 ` [PART2 RFC v1 4/9] iommu/amd: Adding GALOG interrupt handler Suravee Suthikulpanit
2016-04-08 12:49 ` [PART2 RFC v1 5/9] iommu/amd: Introduce amd_iommu_update_ga() Suravee Suthikulpanit
2016-04-13 17:06 ` Radim Krčmář [this message]
2016-06-09 23:59 ` Suravee Suthikulpanit
2016-04-08 12:49 ` [PART2 RFC v1 6/9] iommu/amd: Implements irq_set_vcpu_affinity hook to setup GA mode for pass-through devices Suravee Suthikulpanit
2016-04-08 12:49 ` [PART2 RFC v1 7/9] svm: Introduce AMD IOMMU avic_ga_log_notifier Suravee Suthikulpanit
2016-04-08 12:49 ` [PART2 RFC v1 8/9] svm: Implements update_pi_irte hook to setup posted interrupt Suravee Suthikulpanit
2016-04-08 12:49 ` [PART2 RFC v1 9/9] svm: Update AMD IOMMU IRTE with vcpu scheduling information when enable AVIC 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=20160413170601.GA18429@potion.brq.redhat.com \
--to=rkrcmar@redhat.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=alex.williamson@redhat.com \
--cc=bp@alien8.de \
--cc=gleb@kernel.org \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sherry.hurwitz@amd.com \
--cc=wei@redhat.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;
as well as URLs for NNTP newsgroup(s).