From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPywu-0004Po-Jd for qemu-devel@nongnu.org; Wed, 10 Apr 2013 13:36:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPywq-0001TP-V9 for qemu-devel@nongnu.org; Wed, 10 Apr 2013 13:36:44 -0400 Received: from mail-ea0-x236.google.com ([2a00:1450:4013:c01::236]:40472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPywq-0001TC-OJ for qemu-devel@nongnu.org; Wed, 10 Apr 2013 13:36:40 -0400 Received: by mail-ea0-f182.google.com with SMTP id q15so359281ead.41 for ; Wed, 10 Apr 2013 10:36:40 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5165A320.1000303@redhat.com> Date: Wed, 10 Apr 2013 19:36:32 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <29682.93.184.66.138.1365510165.squirrel@lavabit.com> <1365527892.16420.153.camel@bling.home> <1365545868.16420.173.camel@bling.home> <20130410090104.GZ17919@redhat.com> <1365607252.2918.2.camel@bling.home> In-Reply-To: <1365607252.2918.2.camel@bling.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] VFIO-VGA Issue List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: qemu-devel , Gleb Natapov , deniv@lavabit.com Il 10/04/2013 17:20, Alex Williamson ha scritto: > On Wed, 2013-04-10 at 12:01 +0300, Gleb Natapov wrote: >> On Tue, Apr 09, 2013 at 04:17:48PM -0600, Alex Williamson wrote: >>> On Tue, 2013-04-09 at 11:18 -0600, Alex Williamson wrote: >>>> On Tue, 2013-04-09 at 08:22 -0400, deniv@lavabit.com wrote: >>>>> Hi! >>>>> >>>>> I've tried passing through my ASUS Radeon HD7750, but qemu just hogs 100% >>>>> of one core and stops. Since the display didn't light up, I couldn't see >>>>> how far Win 7 boot went. For a Linux guest I tried redirecting kernel >>>>> messages to serial console, but there was nothing (qemu stops even before >>>>> kernel start?). >>>>> >>>>> Also, this GPU is kinda troublesome: it doesn't work with the proprietary >>>>> driver if VT-d is enabled in BIOS (boot process stops with "dmar: DRHD: >>>>> handling fault status reg 3"). The GPU works with the FOSS driver, though. >>>>> Could this somehow be related to the passthrough issue? >>>>> >>>>> Anyway, VT-d in pci-assign mode works for network adapters on this host. >>>>> It runs kernel 3.9.0-rc5 (with vfio-vga enabled), qemu git from yesterday, >>>>> and seabios 1.7.2. The host has no driver installed for the GPU. Before >>>>> assiging it to qemu I'd run "echo '1002 683f' > >>>>> /sys/bus/pci/drivers/vfio-pci/new_id" and the same for the associated HDMI >>>>> device. Command line: >>>>> qemu-kvm -machine q35,accel=kvm \ >>>>> -cpu host -smp 4 -m 2G \ >>>>> -vga none -display none \ >>>>> -kernel /kvm/kernel-3.7.8 -append 'root=/dev/vda console=ttyS0' \ >>>>> -drive >>>>> index=0,media=disk,cache=none,if=virtio,aio=native,file=/dev/vg3/gpu \ >>>>> -device vfio-pci,host=01:00.0,x-vga=on \ >>>>> -device vfio-pci,host=01:00.1 \ >>>>> -serial telnet:127.0.0.1:52990,server >>>> >>>> You should always at least get monitor sync if it's going to work, but >>>> you may have to reboot the host between each attempt. I've been doing >>>> most of the VGA development on an AMD box and swapping over to an Intel >>>> system reminds me why. Try removing the ",accel=kvm -cpu host -smp 4" >>>> pieces of your command an try again. If that works, it means there are >>>> still broken bits of real mode handling in KVM. My HD7850 hangs on an >>>> Intel host the same way you describe, but posts if I disable KVM >>>> support. Thanks, >>> >>> Gleb, >>> >>> If I run trace-cmd while I'm in this hung state with KVM enabled, the >>> log is filled with: >>> >>> qemu-system-x86-9569 [000] 10027.806836: kvm_emulate_insn: c0000:b2d3: ff 7d 00 >>> >>> I hope this means more to you than it does to me ;) Based on the >>> segment register we're executing in the VGA BIOS for the assigned VGA >>> device. Let me know what more I can provide to help debug. Thanks, >>> >> This is wrong encoding. Such instruction does not exists. Can you see >> what happens before this emulation starts to happen. > > Yeah, it seems like b2d3 is a bad offset, if I align the code at d2 or > d0 gdb is able to disassemble it. I'm not having much luck with > breakpoints or stepping, but I'll keep fiddling with it to try to figure > out how we're getting here. Thanks, How does -d in_asm look for eip values around 000cb2XX? Paolo