qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Anthony Liguori" <aliguori@amazon.com>
Subject: Re: [Qemu-devel] fix clearing i8259 IRQ lines (Was: Should the i8259 devices remain no-user?)
Date: Sat, 26 Oct 2013 14:00:24 -0600	[thread overview]
Message-ID: <20131026200024.GA27159@comcast.net> (raw)
In-Reply-To: <525EBD6F.3060609@redhat.com>

On Wed, Oct 16, 2013 at 06:23:11PM +0200, Paolo Bonzini wrote:
> Il 16/10/2013 18:21, BALATON Zoltan ha scritto:
> > A bit off topic but this reminded me of these patches:
> >
> > http://patchwork.ozlabs.org/patch/206753/
> > http://patchwork.ozlabs.org/patch/208252/
> >
> > which never got merged. Is there a chance that these fixes get merged
> > sometimes or is there an explanation why it won't be fixed? As far as I
> > remember the patches were reviewed and multiple versions were proposed
> > but at the end no decision was reached on which one to merge and it was
> > just left uncorrected.
>
> Right, thank you very much.  ISTR the unanswered question was what to do
> about migration, but I need to reread all the threads.
>
> Paolo

Essentially correct.

Although the 8259 (interrupts) model is clearly wrong with respect
to clearing an IRQ request line, only one ancient unimportant guest
(Microport UNIX ca. 1987) seems to care, and there are potentially
significant risks to more important guests if we try to fix it:

Risks: The 8254 (timers) model is wrong in various ways, some of
which are hidden by the incorrect 8259 model, and fixing it could
potentially break migration, depending on exact circumstances.
Also, it isn't clear if there are other device models depending
on the incorrect 8259 that would also need to be fixed.

Similar changes are needed in KVM for consistency, although some of
the 8254 modes are implemented in a more simplistic way (pulses
handled "as fast as possible" directly, instead of
1-millisecond-long pulses on real hardware).  Note that I was
never able to get my guest running successfully under KVM; I'm
not sure what the remaining problems were.

Also, the patch series included a few other things:
  - A couple of low priority fixes that can still be worked
    around without code changes, but could probably qualify
    as "trivial patches".
  - Some test cases to test for the 8259 problem.
  - Plus an optional VGA hack to make it work when
    my ancient guest tries to directly (no BIOS) configure it
    for CGA text mode.
I didn't get much feedback about these.

-----

If someone actually showed real interest in actually merging
these, including the selection of a migration compatibility
strategy they would actually be willing to merge (and above:
other devices, KVM, etc), I could look into updating
the patches to match.  But the "if" parts aren't looking
particularly likely.  This seems like a rather core-level
wide-implication change for a newbie to be messing
with.  (I've already spent noticably more time on qemu
patches than I had intended to spend total on playing with
this guest, although I may continue if I have a clearly
defined strategy.)

                - Matthew Ogilvie

  reply	other threads:[~2013-10-26 20:00 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-10 14:42 [Qemu-devel] [PATCH RFC 0/9] Clean up and fix no_user armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 1/9] qdev: Replace no_user by cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 2/9] sysbus: Set cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 3/9] apic: Document why cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 4/9] pci-host: Consistently set cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 5/9] ich9: Document why cannot_instantiate_with_device_add_yet armbru
2013-10-10 16:01   ` Paolo Bonzini
2013-10-10 16:03     ` Paolo Bonzini
2013-10-11  6:13       ` Markus Armbruster
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 6/9] piix3 piix4: " armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 7/9] vt82c686: " armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 8/9] isa: Clean up use of cannot_instantiate_with_device_add_yet armbru
2013-10-15 12:43   ` [Qemu-devel] Should the i8259 devices remain no-user? (was: [PATCH RFC 8/9] isa: Clean up use of cannot_instantiate_with_device_add_yet) Markus Armbruster
2013-10-15 12:54     ` [Qemu-devel] Should the i8259 devices remain no-user? Paolo Bonzini
2013-10-16  9:51       ` Markus Armbruster
2013-10-16 11:06         ` Paolo Bonzini
2013-10-16 16:12           ` Markus Armbruster
2013-10-16 16:21           ` BALATON Zoltan
2013-10-16 16:23             ` Paolo Bonzini
2013-10-26 20:00               ` Matthew Ogilvie [this message]
2013-10-29 16:27                 ` [Qemu-devel] fix clearing i8259 IRQ lines (Was: Should the i8259 devices remain no-user?) BALATON Zoltan
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 9/9] qdev: Do not let the user try to device_add when it cannot work armbru
2013-10-15 12:24 ` [Qemu-devel] Why is TYPE_CPU no-user? (was: [PATCH RFC 0/9] Clean up and fix no_user) Markus Armbruster
2013-10-15 12:37   ` Peter Maydell
2013-10-15 14:01     ` [Qemu-devel] Why is TYPE_CPU no-user? Markus Armbruster
2013-10-15 13:08   ` Andreas Färber
2013-10-16  9:55     ` Markus Armbruster
2013-10-15 13:21 ` [Qemu-devel] Which functions of southbridges should be no-user? (was: [PATCH RFC 0/9] Clean up and fix no_user) Markus Armbruster
2013-10-15 13:31   ` [Qemu-devel] Which functions of southbridges should be no-user? Andreas Färber
2013-10-15 14:41     ` Kevin Wolf
2013-10-15 14:53       ` Andreas Färber
2013-10-16  9:58         ` Markus Armbruster
2013-10-15 15:09       ` Anthony Liguori
2013-10-16 10:00         ` Markus Armbruster
2013-10-16 11:02           ` Andreas Färber
2013-10-17  9:47             ` Markus Armbruster
2013-10-16 17:53           ` Anthony Liguori
2013-10-17  9:49             ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131026200024.GA27159@comcast.net \
    --to=mmogilvi_qemu@miniinfo.net \
    --cc=afaerber@suse.de \
    --cc=aliguori@amazon.com \
    --cc=armbru@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).