[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 2/2] linux/xen: support pirq_eoi_map



On Fri, 27 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 27, 2012 at 11:03:41AM +0000, Stefano Stabellini wrote:
> > On Thu, 26 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Jan 26, 2012 at 06:00:39PM +0000, Stefano Stabellini wrote:
> > > > The pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
> > > > be EOI'd without having to issue an hypercall every time.
> > > > We use PHYSDEVOP_pirq_eoi_gmfn (v2) to map the bitmap, then, if we
> > > > succeed, we use pirq_eoi_map to check whether pirqs need eoi.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> > > > ---
> > > >  drivers/xen/events.c            |   17 ++++++++++++++++-
> > > >  include/xen/interface/physdev.h |   12 ++++++++++++
> > > >  2 files changed, 28 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > > index 6e075cd..7fdc738 100644
> > > > --- a/drivers/xen/events.c
> > > > +++ b/drivers/xen/events.c
> > > > @@ -37,6 +37,7 @@
> > > >  #include <asm/idle.h>
> > > >  #include <asm/io_apic.h>
> > > >  #include <asm/sync_bitops.h>
> > > > +#include <asm/xen/page.h>
> > > >  #include <asm/xen/pci.h>
> > > >  #include <asm/xen/hypercall.h>
> > > >  #include <asm/xen/hypervisor.h>
> > > > @@ -108,6 +109,7 @@ struct irq_info {
> > > >  #define PIRQ_SHAREABLE (1 << 1)
> > > >  
> > > >  static int *evtchn_to_irq;
> > > > +static unsigned long *pirq_eoi_map;
> > > >  
> > > >  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > > >                       cpu_evtchn_mask);
> > > > @@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
> > > >  
> > > >         BUG_ON(info->type != IRQT_PIRQ);
> > > >  
> > > > +       if (pirq_eoi_map != NULL)
> > > > +               return test_bit(irq, pirq_eoi_map);
> > > > +
> > > 
> > > How about just having a different function called
> > > pirq_needs_eoi_v2 which will just do
> > > 
> > >  return test_bit(irq, pirq_eoi_map)?
> > > 
> > > And then set the pirq_needs_eoi_v2 in the function table?
> > 
> > Ok, but the name "pirq_needs_eoi_v2" is misleading because
> > PHYSDEVOP_pirq_eoi_gmfn only works for PV guests at the moment.
> > How about I call the new function "pirq_check_eoi_map" and rename the old
> > one "pirq_needs_eoi_flag" and the generic name of the function pointer
> > would remain "pirq_needs_eoi"?
> 
> Even better!
> > 
> > 
> > > >         return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> > > >  }
> > > >  
> > > > @@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
> > > >  
> > > >  void __init xen_init_IRQ(void)
> > > >  {
> > > > -       int i;
> > > > +       int i, rc;
> > > >  
> > > >         evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, 
> > > > sizeof(*evtchn_to_irq),
> > > >                                     GFP_KERNEL);
> > > > @@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
> > > >                  * __acpi_register_gsi can point at the right function 
> > > > */
> > > >                 pci_xen_hvm_init();
> > > >         } else {
> > > > +               struct physdev_pirq_eoi_gmfn eoi_gmfn;
> > > > +
> > > >                 irq_ctx_init(smp_processor_id());
> > > >                 if (xen_initial_domain())
> > > >                         pci_xen_initial_domain();
> > > > +
> > > > +               pirq_eoi_map = (void 
> > > > *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> > > > +               eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
> > > > +               rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn, 
> > > > &eoi_gmfn);
> > > 
> > > 
> > > Don't we want the v2 version?
> > > 
> > > > +               if (rc != 0) {
> > > > +                       free_page((unsigned long) pirq_eoi_map);
> > > > +                       pirq_eoi_map = NULL;
> > > > +               }
> > > >         }
> > > >  }
> > > > diff --git a/include/xen/interface/physdev.h 
> > > > b/include/xen/interface/physdev.h
> > > > index c1080d9..132c61f 100644
> > > > --- a/include/xen/interface/physdev.h
> > > > +++ b/include/xen/interface/physdev.h
> > > > @@ -39,6 +39,18 @@ struct physdev_eoi {
> > > >  };
> > > >  
> > > >  /*
> > > > + * Register a shared page for the hypervisor to indicate whether the
> > > > + * guest must issue PHYSDEVOP_eoi. The page registered is used as a bit
> > > > + * array indexed by Xen's PIRQ value.
> > > > + */
> > > > +#define PHYSDEVOP_pirq_eoi_gmfn      28
> > > 
> > > Ah, the number is right, but the name is the generic one.
> > > 
> > > We should really mention that this is different from v1 or just
> > > 
> > > #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> > > and use that in the code?
> > 
> > Maybe we should:
> > 
> > #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> > 
> > in order not to hide the fact that there are two versions of this
> > hypercall.
> > Then we do:
> > 
> > /* we use the second version of the hypercall */
> > #define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
> > 
> > 
> > This way we just have PHYSDEVOP_pirq_eoi_gmfn in the code but we don't
> > hide the version with are using.
> 
> That could work. However using a v2 everywhere will clearly show to
> to somebody why it won't work with say Xen 4.0 (if they are trying to run it
> under it and wonder why that hypercall did not work). Which reminds me, once 
> the
> hypervisor patch is in, we should definitly mention that in this git commit.

OK then, let's go with PHYSDEVOP_pirq_eoi_gmfn_v2

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.