From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] Re: Question about KVM and PC speaker Date: Thu, 23 Apr 2009 12:29:30 +0200 Message-ID: <49F0430A.8010300@siemens.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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Samuel Thibault , Simon Bienlein , Qemu-devel@nongnu.org, kvm-devel To: Avi Kivity Return-path: Received: from lizzard.sbs.de ([194.138.37.39]:15781 "EHLO lizzard.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755152AbZDWKbW (ORCPT ); Thu, 23 Apr 2009 06:31:22 -0400 In-Reply-To: <49F03A00.8060502@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. 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. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux