[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 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"? > > 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |