From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Xen 4.1 rc5 outstanding bugs Date: Tue, 8 Mar 2011 10:43:41 -0500 Message-ID: <20110308154341.GA20811@dumpdata.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Fri, Feb 18, 2011 at 06:59:55PM +0000, Stefano Stabellini wrote: > 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. What is the status of these? I know you made some strides in fixing most if not all of them both in the hypervisor and Linux kernel. > 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) [] msi_set_mask_bit+0xea/0x121 > (XEN) [] mask_msi_irq+0xe/0x10 > (XEN) [] __pirq_guest_unbind+0x298/0x2aa > (XEN) [] unmap_domain_pirq+0x199/0x307 > (XEN) [] free_domain_pirqs+0x57/0x83 > (XEN) [] arch_domain_destroy+0x30/0x2e3 > (XEN) [] complete_domain_destroy+0x6e/0x12a > (XEN) [] rcu_process_callbacks+0x173/0x1e1 > (XEN) [] __do_softirq+0x88/0x99 > (XEN) [] 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@lists.xensource.com > http://lists.xensource.com/xen-devel