linux-kernel - Re: [PART2 PATCH v6 12/12] svm: Implements update_pi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 22 Aug 2016 17:16:51 +0200
From:   Radim Krčmář <rkrcmar@...hat.com>
To:     Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>
Cc:     joro@...tes.org, pbonzini@...hat.com, alex.williamson@...hat.com,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        sherry.hurwitz@....com
Subject: Re: [PART2 PATCH v6 12/12] svm: Implements update_pi_irte hook to
 setup posted interrupt

2016-08-22 17:09+0700, Suravee Suthikulpanit:
> On 08/22/2016 04:19 PM, Suravee Suthikulpanit wrote:
>> > he problem with wrappers is that we don't know what list we should
>> > remove the "struct amd_ir_data" from;  we would need to add another
>> > tracking structure or go through all VCPUs.
>> > 
>> > Having "struct list_head" in "struct amd_ir_data" would allow us to know
>> > the current list and remove it from there:
>> > One "struct amd_ir_data" should never be used by more than one caller of
>> > amd_iommu_update_ga(), because they would have to be cooperating anyway,
>> > which would mean a single mediator, so we can add a "struct list_head"
>> > into "struct amd_ir_data".
>> > 
>> >    Minor design note:
>> >    To make the usage of "struct amd_ir_data" safer, we could pass "struct
>> >    list_head" into irq_set_vcpu_affinity(), instead of returning "struct
>> >    amd_ir_data *".
>> > 
>> >    irq_set_vcpu_affinity() would add "struct amd_ir_data" to the list
>> > only
>> >    if ir_data was not already in some list and report whether the list
>> >    was modified.
>> > 
>> > I think that adding "struct list_head" into "struct amd_ir_data" is
>> > nicer than having wrappers.
>> > 
>> > Joerg, Paolo, what do you think?
>> > 
>> 
>> I think modifying irq_set_vcpu_affinity() to also pass struct list_head
>> seems a bit redundant since it is currently design to allow passing in
>> void *, which leaves the other option where we might just need to pass
>> in a wrapper (e.g. going back to the previous design where we pass in
>> struct amd_iommu_pi_data) and also add a pointer to the ir_list in the
>> wrapper as well. Then, IOMMU is responsible for adding/deleting ir_data
>> to/from this list instead of SVM. This should be fine since we only need
>> to coordinate b/w SVM and AMD-IOMMU.
> 
> Actually, thinking about this again, going back to keeping the per-vcpu list
> of struct amd_iommu_pi_data is probably the simplest here.
> 
> * We avoid having to expose the amd_ir_data to SVM.
> * We can match using amd_ir_data * when traversing the list.
> * We can easily add the code to manage the list in the SVM. We can make sure
> that the struct amd_iommu_pi_data is not already mapped before adding it to
> a new per-vcpu list. If it is currently mapped, we can simply unmapped it.

Sounds good.
A new SVM-specific wrapper for amd_ir_data instead of reusing
amd_iommu_pi_data would be nicer, IMO -- we could change it without
touching the IOMMU interface and also allocate in svm_pi_list_add.

Updating lists would become O(N^2), but updates should not occur often
(and N small) so I think it's still worth the saving on every
sched_in/out.

> Doing this from IOMMU would be more complicate and require lots of parameter
> passing.

Yeah, doing more than returning amd_ir_data from IOMMU doesn't make
sense and not adding list_head for SVm to amd_ir_data is more
acceptable.

Thanks.