From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Gora Subject: Re: PCI BAR register space written with garbage in HVM guest. Date: Mon, 15 Mar 2010 23:55:40 -0300 Message-ID: <4779de451003151955v15863656i5f39a631a8c558ee@mail.gmail.com> References: <4779de451003151809n6cec813dp32d77fee34b1bda2@mail.gmail.com> <20100316014851.GE7622@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20100316014851.GE7622@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Mon, Mar 15, 2010 at 10:48 PM, Konrad Rzeszutek Wilk wrote: >> I've added a debugging printf to XEN in >> xen/arch/x86/pci.c:pci_conf_write() and I can see the entire PCI BAR >> address space being overwritten with garbage: >> >> (XEN) xen/arch/x86/pci.c: pci_conf_write: cf8=3D0x80080000 offset=3D0x0 >> bytes=3D4 value=3D0xffffffff >> (XEN) xen/arch/x86/pci.c: pci_conf_write: cf8=3D0x80080004 offset=3D0x0 >> bytes=3D4 value=3D0x1600ffff >> (XEN) xen/arch/x86/pci.c: pci_conf_write: cf8=3D0x80080008 offset=3D0x0 >> bytes=3D4 value=3D0x64d5323e >> (XEN) xen/arch/x86/pci.c: pci_conf_write: cf8=3D0x8008000c offset=3D0x0 >> bytes=3D4 value=3D0x450008 >> (XEN) xen/arch/x86/pci.c: pci_conf_write: cf8=3D0x80080010 offset=3D0x0 >> bytes=3D4 value=3D0xa7e54002 >> (XEN) xen/arch/x86/pci.c: pci_conf_write: cf8=3D0x80080014 offset=3D0x0 >> bytes=3D4 value=3D0x11400000 > > Wow.. That is impressive. Are the values always the same? Or are they > truly random? I'm pretty sure that they are always the same... >> I'm really pretty much at a loss as even how to debug this. =A0There >> doesn't appear to be any dump_stack() in XEN so that I can see what >> called pci_conf_write() in XEN, but even then it appears that it only >> gets called as a trap from the dom0 or domU. =A0It's not clear to me if >> you can even see what process/stack actually caused the trap back in >> the dom0 or domU. =A0Is that possible? > > You could instrument the code (Xen) to crash the DomU domain when you > detect garbage. Then you can pick at with xenctx to look at its stack..et= c This is where I could really use some help... Is it possible crash only the domU from with xen? What would it leave behind to analyze with xenctx? >> >> Is there anything else that I should look at? =A0qemu? =A0pciback? >> pcifront? =A0Am I missing some access method to PCI configuration space >> down in the kernel or is pci_confl_read/write pretty much it? =A0Any > > QEMU uses libpci, which is the same as lspci, and that looks to work. > > You can crank up the verbosity of pciback and pcifront with its > parameters to see if they are the ones doing this. But your domain is > HVM DomU so the pcifront/pciback is not utilized. > Yeah I tried that and there doesn't appear to be anything going on there. > That narrows it down to QEMU or the Dom0 kernel. Yeah that's what I figured.. I instrumented qemu a bit and also did not see anything going on in there, but I'm not at the office anymore so I cannot tell you exactly what functions I instrumented. I'm going to look into this more tomorrow. thanks a lot for your help... dan