From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: winXP "Standard PC" HAL and qemu-kvm >= 0.15 Date: Mon, 05 Dec 2011 15:28:30 +0200 Message-ID: <4EDCC6FE.8040702@redhat.com> References: <4EDC8D06.20308@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: KVM list To: Michael Tokarev Return-path: Received: from mx1.redhat.com ([209.132.183.28]:62239 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932250Ab1LEN2l (ORCPT ); Mon, 5 Dec 2011 08:28:41 -0500 In-Reply-To: <4EDC8D06.20308@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: On 12/05/2011 11:21 AM, Michael Tokarev wrote: > As it turned out, a windowsXP machine does not work in > qemu-kvm >= 0.15 (it loses network and USB entirely) > if it is using "Standard PC" HAL. In 0.14 it worked > fine, but not in 0.14 (I haven't tried any in-between > versions yet). > > There are several HAL types available in winXP: these > are "Uniprocessor PC with MPS" (or Multiprocessor), > also two ACPI types, and "Standard PC". All the other > HAL types appears to work fine, but not "Standard PC". > > I haven't debugged further yet, -- because it were > not easy to find out what was causing the regression > and how to reproduce it, and also because I don't think > it is the right HAL for qemu-kvm guest anyway. It's not, but the regression indicates we broke something. It would be good to know what that is. > So, if anybody have some thoughts about this issue, > and especially if you know a way to switch winXP HAL > type to some ACPI variant without reinstalling, please > speak up.. ;) I remember doing it somewhere in device manager, perhaps in the processor entry. But it was years since I last did this. > Debian bugreport for a reference: http://bugs.debian.org/647312 > > Reproducer: install a winXP guest on kvm with -no-acpi so > it chooses an "Uniprocessor with MPS" HAL. Switch it to > "Standard PC" in device manager, reboot -- in 0.15+ it does > not work anymore, while in 0.14 it continues to work fine. Most likely non-ACPI interrupt routing. -- error compiling committee.c: too many arguments to function