WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Xen 4.1 rc5 outstanding bugs

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Xen 4.1 rc5 outstanding bugs
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Fri, 18 Feb 2011 18:59:55 +0000
Delivery-date: Fri, 18 Feb 2011 11:01:18 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
Hi all,
I went through the list of bugs affecting the latest Xen 4.1 RC and
I made a list of what they seem to be the most serious.
All of them affect PCI passthrough and seem to be hypervisor/qemu-xen
bugs apart from the last one that is a libxenlight/xl bug.


 *  VF passthrough does not work
Passing through a normal NIC seem to work but passing through a VF
doesn't.
The device appears in the guest but it cannot exchange packets, the
guest kernel version doesn't seem to matter.
>From the qemu logs:

pci_msix_writel: Error: Can't update msix entry 0 since MSI-X is already        
         function.

It might be the same problem of the two following bug reports:
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1709
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1742


 *  Xen panic on guest shutdown with PCI Passthrough
http://xen.1045712.n5.nabble.com/Xen-panic-on-guest-shutdown-with-PCI-Passthrough-tt3371337.html#none
When the guest with a passthrough pci device is shut down, Xen panic
on a NMI - MEMORY ERROR.
(XEN) Xen call trace:
(XEN)    [<ffff82c48015f032>] msi_set_mask_bit+0xea/0x121
(XEN)    [<ffff82c48015f087>] mask_msi_irq+0xe/0x10
(XEN)    [<ffff82c480162fb1>] __pirq_guest_unbind+0x298/0x2aa
(XEN)    [<ffff82c48016315c>] unmap_domain_pirq+0x199/0x307
(XEN)    [<ffff82c480163321>] free_domain_pirqs+0x57/0x83
(XEN)    [<ffff82c48015642a>] arch_domain_destroy+0x30/0x2e3
(XEN)    [<ffff82c480104c59>] complete_domain_destroy+0x6e/0x12a
(XEN)    [<ffff82c48012adfd>] rcu_process_callbacks+0x173/0x1e1
(XEN)    [<ffff82c480123327>] __do_softirq+0x88/0x99
(XEN)    [<ffff82c4801233a2>] do_softirq+0x6a/0x7a


 *  possible Xen pirq leak at domain shutdown
If a guest doesn't support pci hot-unplug (or a malicious guest), it
won't do anything in response to the acpi SCI interrupt we send when the
domain is destroyed, therefore unregister_real_device will never be
called in qemu and we might be leaking MSIs in the Xen (to be
verified).
http://xen.1045712.n5.nabble.com/template/NamlServlet.jtp?macro=print_post&node=3369367


 *  Xen warns about MSIs when assigning a PCI device to a guest
also known as "Xen complains msi error when startup"
At startup Xen prints multiple:
(XEN) Xen WARN at msi.c:635
(XEN) Xen WARN at msi.c:648
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1732


 *  PCI hot-unplug causes a guest crash
also know as "fail to detach NIC from guest"
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1736


 * multiple PCI devices passthrough to PV guests or HVM guests with
   stubdoms is broken with the xl toolstack
Cannot assign >1 PCI passthrough devices as domain creation time because
libxl creates a bus for the first device and increments "num_devs" node
in xenstore for each subsequent device but pciback cannot cope with
num_devs changing while the guest is not running to respond to the
reconfiguration request. A fix would be to create the entire bus in a
single cold-plug operation at start of day.



 - Stefano

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

<Prev in Thread] Current Thread [Next in Thread>