From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Lwwoz-0000rB-Uj
	for qemu-devel@nongnu.org; Thu, 23 Apr 2009 07:10:25 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Lwwov-0000qv-Gy
	for Qemu-devel@nongnu.org; Thu, 23 Apr 2009 07:10:25 -0400
Received: from [199.232.76.173] (port=44414 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Lwwov-0000qs-Bi
	for Qemu-devel@nongnu.org; Thu, 23 Apr 2009 07:10:21 -0400
Received: from mx2.redhat.com ([66.187.237.31]:49592)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1Lwwou-0002nh-Mw
	for Qemu-devel@nongnu.org; Thu, 23 Apr 2009 07:10:21 -0400
Message-ID: <49F04C80.2040204@redhat.com>
Date: Thu, 23 Apr 2009 14:09:52 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: Question about KVM and PC speaker
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>
In-Reply-To: <49F0430A.8010300@siemens.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>, Qemu-devel@nongnu.org, kvm-devel <kvm@vger.kernel.org>, Simon Bienlein <s.bienlein@gmx.de>

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