From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tih1p-000772-GB for qemu-devel@nongnu.org; Wed, 12 Dec 2012 02:47:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tih1h-0002xO-Df for qemu-devel@nongnu.org; Wed, 12 Dec 2012 02:46:53 -0500 Received: from qmta03.emeryville.ca.mail.comcast.net ([76.96.30.32]:51427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tih1g-0002ur-Ty for qemu-devel@nongnu.org; Wed, 12 Dec 2012 02:46:45 -0500 Date: Wed, 12 Dec 2012 00:46:41 -0700 From: Matthew Ogilvie Message-ID: <20121212074641.GB3582@comcast.net> References: <1353880306-8004-1-git-send-email-mmogilvi_qemu@miniinfo.net> <20121211161955.GG29003@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121211161955.GG29003@redhat.com> Subject: Re: [Qemu-devel] [PATCH v7 00/10] i8254, i8259 and running Microport UNIX (ca 1987) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Jan Kiszka , qemu-devel@nongnu.org, "Maciej W. Rozycki" , Avi Kivity On Tue, Dec 11, 2012 at 06:19:56PM +0200, Gleb Natapov wrote: > On Sun, Nov 25, 2012 at 02:51:36PM -0700, Matthew Ogilvie wrote: > > ---------------- > > Still needed: > > > > * Corresponding KVM patches. The best approach may depend > > on what option is selected for qemu above. > > * Note that KVM uses a simplified model that doesn't try > > to emulate the trailing edge of the interrupt very well > > at all. I'm not proposing to change this aspect of it. > > * A patch analogous to 7 should be easy. > > * Patches 8 through 10 are also fairly easy by themselves. > > But now we start having an explosion of combinations > > of versions of KVM and qemu and migration to/from, and it > > might be better to: > Why explosion of combinations? I do not see any changes in > migration code in your series, so as long as we care about migration > from in-kernel irqchip to in-kernel irqchip we should be independent > from qemu version, no? You may be correct. I'm a little hazy on the details of how things are split between KVM and QEMU. Are there situations that do ioport read/write handling within qemu rather than KVM? How about things like pit_get_out(), pit_get_next_transition_time(), etc in qemu/hw/i8254_common.c? (If not used when KVM is enabled, then why are they "common"?) What are the implications if qemu and KVM implementations of such functions disagree? > > > * Or more involved fixes would involve new ioctl()'s and > > command line arguments to select old or fixed 8254 models > > dynamically. See below. > > > > ---------------- > > Alternative options for improving the i8254 model and migration: > > > > 1. Don't fix 8254 at all. Just apply through patch 7 or 8, and don't try > > to make any additional fixes. I don't know of any guests that need > > improvements, so this could be a viable option. > > > > 2. Just fix it immediately, and don't worry about migration. Squash > > the last few patches together. A single missed periodic > > timer tick that only happens when migrating > > between versions of qemu is probably not a significant > > concern. (Unless someone knows of an OS that actually runs > > the i8254 in single shot mode 4, where a missed interrupt > > could cause a hang or something?) > > > If migration can fail only with the single, rarely (if ever) used mode, > I honestly like this option the most. As long as it is truly rare, I agree. I'm just not sure if the "rare" qualification is actually true or not. See also my response to Jamie Lokier about Linux's tickless configuration. > > > 3. Use patches 8 and 9 now, and patch 10 sometime in the future. > > If it was just qemu, this would be attractive. But when you > > also need to worry about a bunch of combinations of versions of > > qemu and KVM and migration, this is looking less attractive. > > > > 4. Support both old and fixed i8254 models, selectable at runtime > > with a command line option. (Question: What should such an > > option look like?) This may be the best way to actually > > change the 8254, but I'm not sure changes are even needed. > > It's certainly getting rather far afield from running Microport > > UNIX... > If we will start doing it for each bug... >