On Tue, Nov 16, 2010 at 05:43:06PM +0100, Bernhard Kohl wrote: > Am 16.11.2010 14:14, schrieb m...@redhat.com: > >Although explicitly disallowed by the PCI spec, some guests read a > >single byte or word from mmio. Likely a guest OS bug, but I have an OS > >which reads single bytes and it works fine on real hardware. > > > >Signed-off-by: Bernhard Kohl<bernhard.k...@nsn.com> > >Signed-off-by: Michael S. Tsirkin<m...@redhat.com> > >--- > > > >OK so it could like something like the below. > > Yes, this looks good for me. > > > However, my question is: > >do we need to put this in or can the guest simply be fixed? > > I tried to locate the code where the readw occurs, > but not successful. It only occurs during booting our OS, > and the virtio-net driver seems to be OK. With 4 virtio > NICs we have the following readw accesses, thats all! > 3 accesses per NIC and the first NIC appears twice. > > MSI-X: msix_mmio_readw dev=0x9767c58 addr=0000000000000008 > MSI-X: msix_mmio_readw dev=0x9767c58 addr=0000000000000018 > MSI-X: msix_mmio_readw dev=0x9767c58 addr=0000000000000028 > MSI-X: msix_mmio_readw dev=0x9772c40 addr=0000000000000008 > MSI-X: msix_mmio_readw dev=0x9772c40 addr=0000000000000018 > MSI-X: msix_mmio_readw dev=0x9772c40 addr=0000000000000028 > MSI-X: msix_mmio_readw dev=0x977dc38 addr=0000000000000008 > MSI-X: msix_mmio_readw dev=0x977dc38 addr=0000000000000018 > MSI-X: msix_mmio_readw dev=0x977dc38 addr=0000000000000028 > MSI-X: msix_mmio_readw dev=0x9788d90 addr=0000000000000008 > MSI-X: msix_mmio_readw dev=0x9788d90 addr=0000000000000018 > MSI-X: msix_mmio_readw dev=0x9788d90 addr=0000000000000028 > MSI-X: msix_mmio_readw dev=0x9767c58 addr=0000000000000008 > MSI-X: msix_mmio_readw dev=0x9767c58 addr=0000000000000018 > MSI-X: msix_mmio_readw dev=0x9767c58 addr=0000000000000028 > > Is it possible to add a stack back tace printing to the > readw function?
See some words of wisdom from Marcelo (this appliues to qemu-kvm.git): <mst> marcelot, there is a guest that misbehaves <mst> marcelot, so we get an fprintf in qemu <mst> marcelot, but we don't know which place in guest caused the problem, no backtrace, etc <marcelot> mst, print guest RIP there? <mst> marcelot, 1. how to? <marcelot> mst, cpu_synchronize_state(cpu_single_env) + print (env->eip) <marcelot> s/env/cpu_single_env/ <mst> marcelot, 2. can we also make it so that when io completes, guest stops with backtrace in gdb? <marcelot> mst, see kvm_show_code in qemu-kvm-x86.c <marcelot> mst, either add a breakpoint there, or call abort() and gdb core later <mst> marcelot, abort will exit qemu though. gdb core will give me qemu backtrace, not guest one, right? <mst> marcelot, I would like kvm to pretend it hit a breakpoint <mst> marcelot, or a segfault ... something <marcelot> mst, well, vmstop() then. you can see guest RIP from there. <marcelot> mst, yes gdb core will give qemu backtrace. inject a #GP to see guest backtrace (see kvm_put_vcpu_events in qemu-kvm-x86.c <marcelot> ) -- MST