Re: [Xen-devel] [v3 11/15] Update IRTE according to guest interrupt config changes

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Wu, Feng
> Sent: Wednesday, July 08, 2015 7:05 PM
> 
> 
> > -----Original Message-----
> > From: Wu, Feng
> > Sent: Wednesday, July 08, 2015 6:32 PM
> > To: Tian, Kevin; xen-devel@xxxxxxxxxxxxx
> > Cc: keir@xxxxxxx; jbeulich@xxxxxxxx; andrew.cooper3@xxxxxxxxxx; Zhang,
> > Yang Z; george.dunlap@xxxxxxxxxxxxx; Wu, Feng
> > Subject: RE: [v3 11/15] Update IRTE according to guest interrupt config
> > changes
> >
> >
> >
> > > -----Original Message-----
> > > From: Tian, Kevin
> > > Sent: Wednesday, July 08, 2015 6:23 PM
> > > To: Wu, Feng; xen-devel@xxxxxxxxxxxxx
> > > Cc: keir@xxxxxxx; jbeulich@xxxxxxxx; andrew.cooper3@xxxxxxxxxx; Zhang,
> > > Yang Z; george.dunlap@xxxxxxxxxxxxx
> > > 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 <feng.wu@xxxxxxxxx>
> > > > ---
> > > > 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 <asm/hvm/iommu.h>
> > > >  #include <asm/hvm/support.h>
> > > >  #include <xen/hvm/irq.h>
> > > > +#include <asm/io_apic.h>
> > > >
> > > >  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.
> 
> Thinking about this a little more, this function itself is kind of restricted 
> to
> VT-d posted-interrupt, since it doesn't handle multicast/broadcast interrupts,
> it only handle lowest-priority and single destination interrupts. However, I
> can make the vector-hashing logic as a separate function, which can be
> used elsewhere.
> 

iommu_intpost is a general option, not VT-d specific. It's fine to keep this 
function here. My earlier comment is more about the accuracy of the code
comment above. :-)

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel