RE: [Xen-devel] Re: APIC rework

["Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>]

Konrad Rzeszutek Wilk wrote:
>>> 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.

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.   

Xiantao

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