This series makes a series of mostly-unrelated fixes to allow
running an old Microport UNIX (ca 1987) guest under qemu.
The most intrusive of the fixes is modifying how the i8259 handles
the trailing edge of an interrupt request (the trailing edge ought
to cancel interrupt, even when the line is edge-triggered).
Changes since version 7:
* Abandon attempts to be fancy about handling cross version migration
in the i8254 model. Just fix it directly. Analysis suggests
migration issues should essentially always be minor - see comments
for patch 5.
* Added qtest-based test/pic-test.c (and associated infrastructure)
to test the i8259's handling of the trailing edge of an interrupt
request, to prevent future regressions.
I'm still wondering if maybe the non-i825[49]-related patches should be
split off from the rest of this series? Any chance some of them (at
least the trivial ones) could just be included immediately?
I still need to refine the KVM patches I posted back in September
to match these latest changes. Maybe I'll get to that next weekend.
------------
Potential issue with this:
------------
I'm not sure if it is a problem or not, but while figuring out
how to hookup pic-test.c, I noticed the existence of the
qemu_irq_pulse()
function in hw/irq.h. It is raising an IRQ line only
to immediately lower it again, which for a real i8259
(at least) effectively cancels the interrupt request before
it could ever be serviced. It is used in the following files:
hw/bonito.c
hw/dma.c
hw/grlib_apbuart.c
hw/grlib_gptimer.c
hw/hpet.c
hw/milkymist-ac97.c
hw/milkymist-minimac2.c
hw/milkymist-pfpu.c
hw/milkymist-softusb.c
hw/milkymist-sysctl.c
hw/milkymist-tmu2.c
hw/omap1.c
hw/omap_gptimer.c
hw/onenand.c
hw/spapr_events.c
hw/spapr_llan.c
hw/spapr_pci.c
hw/spapr_vio.c
hw/spapr_vty.c
hw/stellaris.c
hw/xilinx_ethlite.c
If any of these calls are ever routed into the i8259, then I doubt
they will behave as desired once the i8259 is fixed to handle the
trailing edge of an interrupt request as indicated in the
spec (patch 6). (That is, the devices use over-simplified interrupt logic
that relies on the currently broken behavior of the i8259 model.)
On the other hand, maybe some or all of these devices are only used
in situations where the the IRQ line is fed into something else (like
an ioapic configured to invert the polarity of the line, or perhaps
some other non-intel interrupt chip that doesn't have this
canceling behavior), in which case they should be fine.
Can anyone shed some light on this? I don't really know much
of anything about any of the devices in the above list (or any
other devices that might manually do something similar without using
qemu_irq_pulse()), so I'm not sure if there are real problems here
or not.
If more than a couple of these devices are wrong, then I'm tempted to
only fix the cascade interrupt (IRQ2) in the i8259 (leaving others
as-is), until such time as all these device models are improved.
-----
Matthew Ogilvie (10):
fix some debug printf format strings
vl: fix -hdachs/-hda argument order parsing issues
qemu-options.hx: mention retrace= VGA option
vga: add some optional CGA compatibility hacks
fix i8254 output logic to match the spec
i8259: fix so that dropping IRQ level always clears the interrupt
request
i8259: refactor pic_set_irq level logic
qtest: fix qemu_irq_intercept_out()
qtest: add set_irq_{in,out} infrastructure for testing interrupt
controllers
add test/pic-test.c
hw/cirrus_vga.c | 4 +-
hw/i8254.c | 24 ++++++++++-
hw/i8254_common.c | 18 +++-----
hw/i8259.c | 34 +++++++--------
hw/ide/cmd646.c | 5 ++-
hw/ide/via.c | 5 ++-
hw/irq.c | 11 +++--
hw/irq.h | 2 +-
hw/pc.h | 4 ++
hw/vga.c | 37 ++++++++++++----
qemu-options.hx | 27 +++++++++++-
qtest.c | 53 ++++++++++++++++++++++-
tests/Makefile | 2 +
tests/libqtest.c | 12 ++++++
tests/libqtest.h | 48 +++++++++++++++++++++
tests/pic-test.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
vl.c | 62 +++++++++++++++++---------
17 files changed, 403 insertions(+), 72 deletions(-)
create mode 100644 tests/pic-test.c
--
1.7.10.2.484.gcd07cc5
