From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tian, Kevin" Subject: Re: [v3 11/15] Update IRTE according to guest interrupt config changes Date: Wed, 8 Jul 2015 11:46:10 +0000 Message-ID: References: <1435123109-10481-1-git-send-email-feng.wu@intel.com> <1435123109-10481-12-git-send-email-feng.wu@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Wu, Feng" , "xen-devel@lists.xen.org" Cc: "Zhang, Yang Z" , "andrew.cooper3@citrix.com" , "keir@xen.org" , "george.dunlap@eu.citrix.com" , "jbeulich@suse.com" List-Id: xen-devel@lists.xenproject.org > From: Wu, Feng > Sent: Wednesday, July 08, 2015 6:32 PM > > > > > -----Original Message----- > > From: Tian, Kevin > > Sent: Wednesday, July 08, 2015 6:23 PM > > To: Wu, Feng; xen-devel@lists.xen.org > > Cc: keir@xen.org; jbeulich@suse.com; andrew.cooper3@citrix.com; Zhang, > > Yang Z; george.dunlap@eu.citrix.com > > Subject: RE: [v3 11/15] Update IRTE according to guest interrupt config > > changes > > > > > From: Wu, Feng > > > Sent: Wednesday, June 24, 2015 1:18 PM > > > > > > When guest changes its interrupt configuration (such as, vector, etc.) > > > for direct-assigned devices, we need to update the associated IRTE > > > with the new guest vector, so external interrupts from the assigned > > > devices can be injected to guests without VM-Exit. > > > > > > For lowest-priority interrupts, we use vector-hashing mechamisn to find > > > the destination vCPU. This follows the hardware behavior, since modern > > > Intel CPUs use vector hashing to handle the lowest-priority interrupt. > > > > > > For multicast/broadcast vCPU, we cannot handle it via interrupt posting, > > > still use interrupt remapping. > > > > > > Signed-off-by: Feng Wu > > > --- > > > v3: > > > - Use bitmap to store the all the possible destination vCPUs of an > > > interrupt, then trying to find the right destination from the bitmap > > > - Typo and some small changes > > > > > > xen/drivers/passthrough/io.c | 96 > > > +++++++++++++++++++++++++++++++++++++++++++- > > > 1 file changed, 95 insertions(+), 1 deletion(-) > > > > > > diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c > > > index 9b77334..18e24e1 100644 > > > --- a/xen/drivers/passthrough/io.c > > > +++ b/xen/drivers/passthrough/io.c > > > @@ -26,6 +26,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > static DEFINE_PER_CPU(struct list_head, dpci_list); > > > > > > @@ -199,6 +200,78 @@ void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci) > > > xfree(dpci); > > > } > > > > > > +/* > > > + * The purpose of this routine is to find the right destination vCPU for > > > + * an interrupt which will be delivered by VT-d posted-interrupt. There > > > + * are several cases as below: > > > > If you aim to have this interface common to more usages, don't restrict to > > VT-d posted-interrupt which should be just an example. > > Yes, making this a common interface should be better. > > > > > > + * > > > + * - For lowest-priority interrupts, we find the destination vCPU from the > > > + * guest vector using vector-hashing mechanism and return true. This > > follows > > > + * the hardware behavior, since modern Intel CPUs use vector hashing to > > > + * handle the lowest-priority interrupt. > > > > Does AMD use same hashing mechanism? Can this interface be reused by > > other IOMMU type or it's an Intel specific implementation? > > I am not sure how AMD handle lowest-priority. Intel hardware guys told me > recent Intel hardware platform use this method to deliver lowest-priority > interrupts. What do you mean by "other IOMMU type"? > OS doesn't assume how vector hashing is done in hardware level. So it should be fine to use Intel algorithm in this emulation path. However my point is just about the comment " since modern Intel CPUs use vector hashing to handle the lowest-priority interrupt". It's not because Intel does so. It's the implementation option that you choose Intel algorithm here. Thanks Kevin