2016-07-11 05:11-0500, Suravee Suthikulpanit:
> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@xxxxxxx>
>
> Introduces a new IOMMU API, 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@xxxxxxx>
> ---
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> @@ -4481,4 +4481,67 @@ int amd_iommu_create_irq_domain(struct amd_iommu *iommu)
> +int amd_iommu_update_ga(u32 vcpu_id, u32 cpu, u32 ga_tag,
> + u64 base, bool is_run)
Not just in this function does the interface between svm and iommu split
ga_tag into its two components (vcpu_id and ga_tag), but it seems that
the combined value could always be used instead ...
Is there an advantage to passing two values?
> +{
> + unsigned long flags;
> + struct amd_iommu *iommu;
> +
> + if (!AMD_IOMMU_GUEST_IR_VAPIC(amd_iommu_guest_ir))
> + return 0;
> +
> + for_each_iommu(iommu) {
> + struct amd_ir_data *ir_data;
> +
> + spin_lock_irqsave(&iommu->ga_hash_lock, flags);
> +
> + /* Note: Update all possible ir_data for a particular
> + * vcpu in a particular vm.
> + */
> + hash_for_each_possible(iommu->ga_hash, ir_data, hnode,
> + AMD_IOMMU_GATAG(ga_tag, vcpu_id)) {
> + struct irte_ga *irte = (struct irte_ga *) ir_data->entry;
(The ga_tag check is missing here too.)
> + if (!irte->lo.fields_vapic.guest_mode)
> + continue;
> +
> + update_irte_ga((struct irte_ga *)ir_data->ref,
> + ir_data->irq_2_irte.devid,
> + base, cpu, is_run);
(The lookup leading up to here is avoidable -- svm, the caller, has the
ability to map ga_tag into irte/ir_data directly with a pointer.
I'm not sure if the lookup is slow enough to pardon optimization, but
it might make the code simpler as well.)
> + iommu_flush_irt(iommu, ir_data->irq_2_irte.devid);
> + iommu_completion_wait(iommu);
> + }
> +
> + spin_unlock_irqrestore(&iommu->ga_hash_lock, flags);
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
