Re: [Xen-devel] PCI BAR register space written with garbage in HVM guest.

[Dan Gora <dan.gora@xxxxxxxxx>]

On Mon, Mar 15, 2010 at 10:48 PM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> 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=0x80080000 offset=0x0
>> bytes=4 value=0xffffffff
>> (XEN) xen/arch/x86/pci.c: pci_conf_write: cf8=0x80080004 offset=0x0
>> bytes=4 value=0x1600ffff
>> (XEN) xen/arch/x86/pci.c: pci_conf_write: cf8=0x80080008 offset=0x0
>> bytes=4 value=0x64d5323e
>> (XEN) xen/arch/x86/pci.c: pci_conf_write: cf8=0x8008000c offset=0x0
>> bytes=4 value=0x450008
>> (XEN) xen/arch/x86/pci.c: pci_conf_write: cf8=0x80080010 offset=0x0
>> bytes=4 value=0xa7e54002
>> (XEN) xen/arch/x86/pci.c: pci_conf_write: cf8=0x80080014 offset=0x0
>> bytes=4 value=0x11400000
>
> 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.  There
>> 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.  It's not clear to me if
>> you can even see what process/stack actually caused the trap back in
>> the dom0 or domU.  Is 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..etc

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?  qemu?  pciback?
>> pcifront?  Am I missing some access method to PCI configuration space
>> down in the kernel or is pci_confl_read/write pretty much it?  Any
>
> 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.

<aside>
What is pcifront/pciback's role for HVM guests exactly?  I understand
that you "hide" the devices from the dom0 with pciback and it
definately loads and does *something* when the HVM guest comes up, but
accesses from the domU don't appear to go through it at all (I
understand that it works with qemu somehow, but that channel too is
not at all clear how it works...)
I've looked through qemu enough to kind of understand that it's
responsible for abstracting the PCI configuration space for the domU,
but I don't really understand how accesses get channeled through to it
from the domU.  Does it use hypercalls somehow?  Can someone explain
how this whole flow is supposed to work for PCI configuration space
accesses?
</aside>

> 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

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