Re: Re: APIC rework

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

> I am also confusing about how to assign a device to a PV guest. Originally  I thought the logic should be it should be hidden first through pciback in dom0, and pv guest uses its pci subsystem (pcifront end) to require pciback to mapping this device.  In the first step, once pciback.hide logic is called in dom0,  this device should be released by dom0 and avaliable for PV guests at this time. And the in subsequent step, pciback or dom0's pci system should help PV guests to do the irq mapping, otherwise I can't see how the irqs from the assigned device are delivered to PV guests.   

That is correct. Here is an URL of the correct steps:
http://wiki.xensource.com/xenwiki/Assign_hardware_to_DomU_with_PCIBack_as_module

>From the unprivileged side (domU), when it makes a call to
pci_enable_device, it gets routed to pcifront_bus_write.
On the privileged side (dom0), pciback picks up the write
and routes it to 'command_write' (conf_space_header.c). It
does the pci_enable_device in the dom0 side. The pci_enable_device
ends up calling xen_allocate_pirq which gets the IRQ from
PHYSDEVOP_alloc_irq_vector. That IRQ is saved in dev->irq and
is visible to the DomU.

Also during the pci_enable_device (in the DomU side), pcibios_enable_device
gets called - which in domU is called 'xen_pcifront_enable_irq'.
The xen_pcifront_enable_irq allocates an irq_desc with xen_pirq_chip
structure. The GSI it requests is actually the IRQ number from dev->irq.

To summarize, dom0 on behalf of domU, calls PHYSDEVOP_alloc_irq_vector
for the device in question. Saves the GSI in dev->irq which is visible to
the DomU. DomU sets up a xen_pirq_chip structure for the device and
starts/stop/etc through that function structure. Please note that 
there is nothing in PHYSDEVOP_alloc..  about which domain owns the device.
That is only done with PHYSDEVOP_map_pirq calls.

With your patch instead of PHYSDEVOP_alloc_irq_vector, it would be
PHYSDEVOP_map_pirq.