From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38433 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIizt-0001F5-CJ for qemu-devel@nongnu.org; Wed, 17 Nov 2010 09:28:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIizs-0002Cu-4a for qemu-devel@nongnu.org; Wed, 17 Nov 2010 09:28:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60292) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PIizr-0002Cf-TD for qemu-devel@nongnu.org; Wed, 17 Nov 2010 09:28:28 -0500 Date: Wed, 17 Nov 2010 16:28:16 +0200 From: "Michael S. Tsirkin" Message-ID: <20101117142816.GA15204@redhat.com> References: <20101116131452.GA23963@redhat.com> <4CE2B49A.7000701@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE2B49A.7000701@nsn.com> Subject: [Qemu-devel] Re: [PATCH comment tweaked] msix: allow byte and word reading from mmio List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bernhard Kohl , mtosatti@redhat.com Cc: qemu-devel@nongnu.org On Tue, Nov 16, 2010 at 05:43:06PM +0100, Bernhard Kohl wrote: > Am 16.11.2010 14:14, schrieb mst@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 > >Signed-off-by: Michael S. Tsirkin > >--- > > > >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): marcelot, there is a guest that misbehaves marcelot, so we get an fprintf in qemu marcelot, but we don't know which place in guest caused the problem, no backtrace, etc mst, print guest RIP there? marcelot, 1. how to? mst, cpu_synchronize_state(cpu_single_env) + print (env->eip) s/env/cpu_single_env/ marcelot, 2. can we also make it so that when io completes, guest stops with backtrace in gdb? mst, see kvm_show_code in qemu-kvm-x86.c mst, either add a breakpoint there, or call abort() and gdb core later marcelot, abort will exit qemu though. gdb core will give me qemu backtrace, not guest one, right? marcelot, I would like kvm to pretend it hit a breakpoint marcelot, or a segfault ... something mst, well, vmstop() then. you can see guest RIP from there. 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 ) -- MST