Re: Xen 4.4 development update: Is PVH a blocker?

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Dec 17, 2013 at 07:04:23AM -0800, Anthony Liguori wrote:
> On Dec 16, 2013 11:37 AM, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
> wrote:
> >
> > On Mon, Dec 16, 2013 at 06:59:16PM +0100, Sander Eikelenboom wrote:
> > >
> > > Monday, December 16, 2013, 6:46:35 PM, you wrote:
> > >
> > > > On Mon, Dec 16, 2013 at 06:24:20PM +0100, Sander Eikelenboom wrote:
> > > >>
> > > >> Monday, December 16, 2013, 4:09:06 PM, you wrote:
> > > >>
> > > >> >> >> * qemu-upstream not freeing pirq
> > > >> >> >>  > http://www.gossamer-threads.com/lists/xen/devel/281498
> > > >> >> >>  > http://marc.info/?l=xen-devel&m=137265766424502
> > > >> >> >>  status: patches posted; latest patches need testing
> > > >> >> >>  Not a blocker.
> > > >> >>
> > > >> >> > I can't test it, b/c qemu-upstream does not work with PCI
> passthrough
> > > >> >> > anymore.
> > > >> >>
> > > >> >> Strange, pci passthrough in general works for me on "simple" pci
> devices (usb cards, videograbber) with latest qemu-upstream and seabios
> upstream.
> > > >> >> (if you have no need for pci rombars, no vga passthrough, no need
> for specifying funky things about which virtual functions to passthrough)
> > > >> >>
> > > >> >> What are you trying to passthrough ?
> > > >>
> > > >> > -bash-4.1# lspci -s 01:00.0 -v
> > > >> > 01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit
> Network Connection (rev 01)
> > > >> >         Subsystem: Intel Corporation Gigabit ET Dual Port Server
> Adapter
> > > >> >         Flags: fast devsel, IRQ 16
> > > >> >         Memory at fbc20000 (32-bit, non-prefetchable) [disabled]
> [size=128K]
> > > >> >         Memory at fb800000 (32-bit, non-prefetchable) [disabled]
> [size=4M]
> > > >> >         I/O ports at e020 [disabled] [size=32]
> > > >> >         Memory at fbc44000 (32-bit, non-prefetchable) [disabled]
> [size=16K]
> > > >> >         Expansion ROM at fb400000 [disabled] [size=4M]
> > > >> >         Capabilities: [40] Power Management version 3
> > > >> >         Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> > > >> >         Capabilities: [70] MSI-X: Enable- Count=10 Masked-
> > > >> >         Capabilities: [a0] Express Endpoint, MSI 00
> > > >> >         Capabilities: [100] Advanced Error Reporting
> > > >> >         Capabilities: [140] Device Serial Number
> 00-1b-21-ff-ff-45-d9-ac
> > > >> >         Capabilities: [150] Alternative Routing-ID Interpretation
> (ARI)
> > > >> >         Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
> > > >> >         Kernel driver in use: pciback
> > > >> >         Kernel modules: igb
> > > >>
> > > >>
> > > >> >> What problems do you have / errors do you see ?
> > > >> >>
> > > >>
> > > >> >
> http://www.gossamer-threads.com/lists/xen/devel/309476?do=post_view_threaded
> > > >>
> > > >>
> > > >> Could it be related to the outstanding issue (since 4.3) of:
> > > >>
> > > >> * PCI hole resize support hvmloader/qemu-traditional/qemu-upstream
> with PCI/GPU passthrough
> > > >>   >
> http://lists.xen.org/archives/html/xen-devel/2013-05/msg02813.html
> > > >>   > Where Stefano writes:
> > > >>   > 2) for Xen 4.4 rework the two patches above and improve
> > > >>   > i440fx_update_pci_mem_hole: resizing the pci_hole subregion is
> not
> > > >>   > enough, it also needs to be able to resize the system memory
> region
> > > >>   > (xen.ram) to make room for the bigger pci_hole
> > > >>
> > > >>   Your card seems to need quite some resources, and restricted to
> 32bit, even other SR-IOV cards seems to to with less and or support 32 bit.
> > > >>
> > >
> > > > I don't think that is the problem. The QEMU-xen did work at some
> point - until
> > > > I blew away 'qemu-xen-dir' to get the newest and best. So I think the
> problem
> > > > I am seeing is with QEMU 1.6 regression.
> > >
> > >
> > > Could try to get the latest upstream qemu and seabios patches then by
> changing your trees in Config.mk to the upstream qemu tree:
> > >
> > > git://git.qemu.org/qemu.git
> > >
> > > and
> > >
> > > git://git.qemu.org/seabios.git
> > > (at the extra config option questions, just except the defaults).
> > >
> > > It's what i run at the moment, could be there is a off-chance there is
> a patch upstream that fixes your problem that's not in the xen qemu
> upstream tree yet.
> >
> > I did this:
> > diff --git a/Config.mk b/Config.mk
> > index 2007b22..7702fff 100644
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -235,7 +235,13 @@ SEABIOS_UPSTREAM_URL ?= git://
> xenbits.xen.org/seabios.git
> >  endif
> >  OVMF_UPSTREAM_REVISION ?= 447d264115c476142f884af0be287622cd244423
> >  QEMU_UPSTREAM_REVISION ?= master
> 
> QEMU is bisectable so if the old rev worked you can find the commit that
> stopped working for youe card.

That will have to wait (the bisection) after New Year. I got a whole
bunch of other things I need to get done.

I am hoping that Anthony (the other one) can reproduce this when he gets
hardware capable of doing PCI passthrough and find the bug immediately.