Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Friday, November 14, 2014, 5:31:03 PM, you wrote:

> Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the 
> device before tearing it down"):
>> (Now with Reply-all, sorry)

> Likewise.

>> On 11/14/2014 11:01 AM, Ian Jackson wrote:
>> > What call to xc_physdev_unmap_pirq ?  I see one in the PV path.
>> 
>> At the skip1 label.

> `goto skip1' only appears in the PV path AFAICT.

Not wanting to hijack this thread, but since it addresses a problem i tried to 
report and partly fix earlier, just 3 notes:

1) xc_physdev_unmap_pirq does get called when destroying a HVM guest.

   See this part of an earlier report of mine: 
    http://lists.xen.org/archives/html/xen-devel/2014-10/msg02518.html :

   - When i destroy the guest (instead of shutting it down), 
     "xen_pcibk_disable_msi()" does get called, but then i get an error
     from the toolstack, it reads the /sys/bus/pci/devices/<BDF>/irq value 
which 
     is still "68" and that is not
     assigned to the guest:
     libxl: error: libxl_pci.c:1319:do_pci_remove: xc_physdev_unmap_pirq 
irq=68: 
     Invalid argument
     libxl: error: libxl_pci.c:1323:do_pci_remove: xc_domain_irq_permission 
     irq=68: Invalid argument

     On the guest start it called xc_physdev_unmap_pirq and 
     xc_domain_irq_permission for irq=22 ..

  This particular error only occurs when the guest is has enabled MSI, this 
changes the 
  irq number in /sys/bus/pci/devices/<BDF>/irq to the MSI nr. So on guest 
  destroy it now tries to do things based on the MSI nr instead of the intX irq.

2) When setting and updating the device states in xenstore for a passed through 
   device, libxl doesn't mimic the states pciback and pcifront set and use, 
very well.
   (see f.e. http://lists.xen.org/archives/html/xen-devel/2014-08/msg00970.html)
   And when 

3) When a HVM guest has multiple pci devices passes through,  pciback doesn't 
currently get a signal *what* pci-device has 
   been removed from the guest on a 'xl pci-detach', since it only has a watch 
on the whole pci-root in xenstore, 
   since it doesn't know which device has been yanked out, it also can't clean 
up everything properly until *all* devices
   have been removed from the guest and the whole pci-root entry gets removed 
from xenstore.
   The effect is that if you remove only one device from a guest with "xl 
   pci-detach" and then do a "xl pci-assignable-remove" you will run into 
trouble.

Just my 3 notes and 2 cents on issues related to this code.

> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel