Re: [Xen-devel] Re: APIC rework

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> > During boot the device can be owned by pciback or by the modele for
> > which a 
> > PCI entry exist. Look for pciback.hide entry.
> > 
> > There are two modes of execution:
> >  1). First being what you described wherein the device initially
> >      belogs to Dom0. The user unbinds it from the PCI device and
> >      binds it to the pciback module. At that point, the device is
> >      disabled and ready for PV guests. When a PV guest starts pciback
> >      module makes the pci_enable_device call and sets the IRQ, etc
> >      for the device (for MSI, it obviously gets the IDT value from
> >  the hypervisor call). 2). Dom0 boots where the user specified on the
> >      command line pciback.hide=(0000:01:03.1). The pciback owns the
> >      device (is binded to it) and the native module that would load
> > for this PCI device is not called. 
> > 
> > It is correct that the unmapping/mapping and the ownership needs to
> > be dynamic. As user could bind to the pciback module, give it to
> > guest, kill the guest, then map the PCI device back to dom0, and
> > after that repeat the whole thing.
> 
> If only the above two cases are needed to support, I think my patch should 
> meet the requirement. This is because once the device is hidden by the 
> pciback, the pirq unmap logic should be callled in both cases. So it the 
> mapping for dom0 should be cleared in the operation, so there is not the 
> issue you figured.  :-)

Ah, what about maping the device to a guest? That is not neccessary? Or are you
saying that the PV guest should be making a hypervisor call to 
PHYSDEVOP_map_pirq and
it will map the device itself? I thought those calls in the Hypervisor
were guarded by a IS_PRIV(xx) which would expel a PV guest. The other 
complication is
that the PV guests have their own PCI subsystem (look in arch/x86/pci/xen.c)
which only calls 'xen_allocate_pirq' to setup the chip_data to xen_pirq_chip.

The next call the PV guest does is to startup_pirq.

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

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