Re: [PATCH 2/2] xen/x86: Implement x86_apic_ops

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

> > > > +unsigned int xen_io_apic_read(unsigned apic, unsigned reg) {
> > > > +       if (reg == 0x1)
> > > > +               return 0x00170020;
> > > > +       else if (reg == 0x0)
> > > > +               return apic << 24;
> > >
> > > Why is fixed value returned?
> > >
> > > Can't we implement it with hypercall(PHYSDEVOP_apic_read)?
> > 
> > We sure can. But this was meant to fix the regression - so I figured we would
> > do that later on. But the more important question is - do we actually need to
> > do the hypercall? We aren't using the IOAPIC for anything - we don't program
> > the pins from dom0.
> 
>  Actually, dom0 doesn't programe ioapic pins directly as you said,  but the work is done by dom0 in the indirect way.  For dom0,  I added a hypercall PHYSDEVOP_setup_gsi before, and with this hypercall, we can get rid of programing IOAPIC pins from dom0 and hypervisor helps to do the ioapic programming, but we still need to get correct GSI information from hypervisor, otherwise, the hypercall may meet issues.  

The GSI information (I think of the polarity and trigger, and as well
which PCI devices pins correspond to what interrupt) is retrieved via the ACPI _PRT.

The IO-APIC isn't used at all - instead the code in arch/x86/pci/xen.c is utilized
which does the appropiate lookup and invokes the proper hypercall to bind an
PIRQ (GSI) to an event channel (and the event channel is then binded to the Linux
IRQ subsystem).

The hypercall - PHYSDEVOP_apic_read can be implemented here - and I am
more than open for folks to submit a patch for it - but it does not affect
how GSI/IO-APIC programming is done. This will just report proper IO-APIC
information instead of the fabricated one.