From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932368AbcHVPQ5 (ORCPT ); Mon, 22 Aug 2016 11:16:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38450 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755722AbcHVPQy (ORCPT ); Mon, 22 Aug 2016 11:16:54 -0400 Date: Mon, 22 Aug 2016 17:16:51 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Suravee Suthikulpanit Cc: joro@8bytes.org, pbonzini@redhat.com, alex.williamson@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, sherry.hurwitz@amd.com Subject: Re: [PART2 PATCH v6 12/12] svm: Implements update_pi_irte hook to setup posted interrupt Message-ID: <20160822151651.GA27608@potion> References: <1471549364-6672-1-git-send-email-Suravee.Suthikulpanit@amd.com> <1471549364-6672-13-git-send-email-Suravee.Suthikulpanit@amd.com> <20160819144907.GB1885@potion> <57BAC3AD.8020001@amd.com> <57BACF73.8020401@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57BACF73.8020401@amd.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 22 Aug 2016 15:16:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.