From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: Question about KVM and PC speaker Date: Thu, 23 Apr 2009 14:09:52 +0300 Message-ID: <49F04C80.2040204@redhat.com> References: <49EF69BC.90300@gmx.de> <49F01C8D.1010203@web.de> <20090423083252.GB5277@const.bordeaux.inria.fr> <49F031C2.5000204@siemens.com> <20090423092546.GF5277@const.bordeaux.inria.fr> <49F035E7.5080906@siemens.com> <49F03A00.8060502@redhat.com> <49F0430A.8010300@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Samuel Thibault , Simon Bienlein , Qemu-devel@nongnu.org, kvm-devel To: Jan Kiszka Return-path: Received: from mx2.redhat.com ([66.187.237.31]:53033 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753065AbZDWLKZ (ORCPT ); Thu, 23 Apr 2009 07:10:25 -0400 In-Reply-To: <49F0430A.8010300@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: > Avi Kivity wrote: > >> Jan Kiszka wrote: >> >>> Huh, it is! Then the problem is a KVM-only thing: The kernel part hooks >>> onto those resources but doesn't communicate changes to this user space >>> backend. >>> >>> >> In this case, the -no-kvm-pit option should help. >> > > Probably fine in many cases (where the PIT is no longer used anyway), > just a bit unintuitive for users. > Yes, it's only a workaround. > I wonder why KVM moved port 0x61 handling into kernel space at all. By > leaving it in pcspk hands and extending the latter to sync with the > in-kernel PIT on sample generation, this speaker regression (of > kvm-userspace) should have been avoidable. > I'd rather not have partial components in the kernel. This case is particularly icky though. -- error compiling committee.c: too many arguments to function