From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
To: "Radim Krčmář" <rkrcmar@redhat.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: Thu, 9 Jun 2016 18:59:34 -0500 [thread overview]
Message-ID: <2f97d84f-8ce0-6c60-ec36-219900f42755@amd.com> (raw)
In-Reply-To: <20160413170601.GA18429@potion.brq.redhat.com>
Hi Radim,
On 4/13/16 12:06, Radim Krčmář wrote:
> 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.
Actually, we are generating the tag from the SVM side currently (please
see avic_get_next_tag() in patch 8). The amd_iommu_update_ga() is meant
to be called from SVM side and we are passing in the tag here.
>
>> + 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?
Actually, the hash key is basically vm-id and vcpu-id. So, this should
get us all the ir_data for a specific vcpu in a particular VM.
>> + 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?
You are right -- I think we can actually keep a pointer to IRTE in the
amd_ir_data, and use that to directly get to the IRTE when we need to
update the GA mode related stuff. That way, we don't need to go through
the whole interrupt remapping table.
> 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.
Right.
I'm working on sending out V2 soon.
Thanks,
Suravee
next prev parent reply other threads:[~2016-06-09 23:59 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ář
2016-06-09 23:59 ` Suravee Suthikulpanit [this message]
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=2f97d84f-8ce0-6c60-ec36-219900f42755@amd.com \
--to=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=rkrcmar@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
all inboxes | Powered by JetHome®