[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: Possible regression in "passthough: add no_wb option for pci conf write"



On Mon, Dec 07, 2009 at 10:57:50AM +0800, Qing He wrote:
> On Mon, 2009-12-07 at 10:55 +0800, Simon Horman wrote:
> > On Mon, Dec 07, 2009 at 10:16:40AM +0800, Qing He wrote:
> > > On Sun, 2009-12-06 at 13:55 +0800, Simon Horman wrote:
> > > > > passthough: add no_wb option for pci conf write
> > > > > 
> > > > > Current pt_pci_write_config always writes back to real pci conf
> > > > > space. However, in the case of MSI address and data registers,
> > > > > if guest changes the affinity of the interrupt, stale data will
> > > > > be written to these registers. This is particularly a problem
> > > > > if Xen uses per-CPU vector, where the interrupt in question fails
> > > > > to work. This patch fixes this by adding an option to disable the
> > > > > write back of certain controls.
> > > > 
> > > > This patch seems to cause the creation of passing a domain
> > > > to fail when passing through either an intel 82576 or 82572EI.
> > > > I didn't try any others.
> > > > 
> > > 
> > > Hi Simon,
> > >   Do you notice anything unusual in the ioemu and hypervisor logs?
> > 
> > I couldn't see anything of particular note. I'll try and poke a bit harder.
> > 
> 
> Thank you, I'll also try at my side. What's your configuration? On what
> changeset are you experiencing this?

Hi,

I have attached logs from xend and qemu-dm. Unfortunately they
don't seem to shed much light on the problem other than that
qemu-dm exits prematurely.

The "bad" logs are using staging/xen-unstable.hg:

        changeset:   20587:763bc7e6b3b4
        tag:         tip
        user:        Keir Fraser <keir.fraser@xxxxxxxxxx>
        date:        Sat Dec 05 12:32:34 2009 +0000
        summary:     x86_32: Fix build after 20575:0930d17589a6

And staging/qemu-xen-unstable.git:

        commit e2b98415256cb264bc25e6df539ec0dc9d1b85b0
        Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
        Date:   Fri Nov 6 18:11:50 2009 +0000

        passthough: add no_wb option for pci conf write

        Current pt_pci_write_config always writes back to real pci conf
        space. However, in the case of MSI address and data registers,
        if guest changes the affinity of the interrupt, stale data will
        be written to these registers. This is particularly a problem
        if Xen uses per-CPU vector, where the interrupt in question fails
        to work. This patch fixes this by adding an option to disable the
        write back of certain controls.

        Signed-off-by: Qing He <qing.he@xxxxxxxxx>

the "good" logs use the same version of staging/xen-unstable.hg and
the previous commit of staging/qemu-xen-unstable.git:

        commit de6c06808e300b35368178a281660ae8acf64f66
        Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
        Date:   Fri Nov 6 18:10:44 2009 +0000

        Enlarge the size of the global mmio_space mmio[].

        With the Multi-Function passthrough, we're actually able to assign
        more than 32 functions to guest, so we should enlarge the MAX_MMIO.
        1024 should be big enough.

        Signed-off-by: Dexuan Cui <dexuan.cui@xxxxxxxxx>

Dom0 is linux-xen 2.6.18.8 + by igb backport

        URL: http://hg.vergenet.net/xen/linux-2.6.18-xen-igb/

        changeset:   1123:f4deded581e6
        tag:         tip
        parent:      1121:4b89768ad33b
        parent:      1122:f1a207ccb493
        user:        Simon Horman <horms@xxxxxxxxxxxx>
        date:        Mon Aug 31 09:54:00 2009 +1000
        summary:     Merge with http://xenbits.xensource.com/linux-2.6.18-xen.hg

Attachment: xend.good
Description: Text document

Attachment: qemu-dm.good
Description: Text document

Attachment: xend.bad
Description: Text document

Attachment: qemu-dm.bad
Description: Text document

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.