[Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[Matthew Ogilvie]

After applying this version 2 of this patch series, I can
successfully run "Micoport UNIX System V/386, v 2.1" (ca 1987)
under qemu.  (although not if I try to enable KVM)

Version 1 of this series was posted about 4 weeks ago.  See
http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654

The patches are all independent, except that the documentation part
of patch 5 (vga) adds onto patch 4 (retrace=) changes.

Patches 2 (mov crN), 5 (vga/cga), and 6 (spurious interrupts) are
required to run this UNIX.  The other three patches are trivial
improvements I noticed while tracking down the main issues.

The first four patches are probably trivially obvious.

The last two patches might be a little controversial, since they
add hacks to work around what could be argued are operating system
bugs.  But I've tried to make them minimal impact (leave
them disabled by default, isolate relevant code in minimal number
of places, etc), and tried to implement and describe them so that
they might be useful for other old OS's and programs besides my old
version of UNIX.

==================

Just for reference, in case someone else wants to debug similar issues
with other operating systems, here are some notes about running and
debugging this UNIX system under qemu:

 - This version of UNIX seems to hard code the number of tracks
   per cylinder for the hard drive to 17.  So build your drive image
   with that in mind, and tell qemu to use 17 tracks per cylinder.
 - This version of UNIX seems to think it doesn't have any RAM unless
   I configure the virtual machine with 17MB or less RAM.  I've mostly
   been reducing that to 15 while debugging other issues, just to
   eliminate any possible problems at 16.  Someday I'll try 17 again.
 - I use a command line similar to the following (from a shell script):
     qemu-system-i386 -monitor stdio -m 15 -hdachs 977,5,17 -hda "$diskC" \
        -drive file="$installDisk",if=floppy,snapshot=on -no-fd-bootchk \
        -vga std,cga_hacks=palette_blanking+font_height \
        -no-spurious-interrupt-hack
 - -no-shutdown and -no-reboot were also handy for tracking some of the
   early bootup issues (mov crN patch).
 - Without my cga hacks patch, you can get a snapshot of the screen
   by running "pmemsave 0xb8000 0x8000 screenDump.out" in the monitor,
   and then examining every other byte of screenDump.out externally.
 - Other tools:
    - I can mount the first install floppy in Linux if I skip the
      first track:
        mount -t sysv -r -o loop,offset=15K "$installDisk" /mnt/misc
    - I can also mount the UNIX hard drive in Linux, but I don't
      know a good way to find the correct offset.  UNIX seems to use
      it's own partition scheme within a DOS-style partition, so it
      doesn't work to just use the offset of the (DOS) partition.
      "kpartx" and "pvscan" sounded promising, but only seem to find DOS
      partitions.  Perhaps reboot with the "max_part" option on a
      kernel configured with the correct partitioning scheme
      enabled?  I found the offset by brute force trying every sector
      on the the above hard disk.  The actual number likely depends
      on a lot of things.
        mount -t sysv -r -o loop,offset=5178880 "$diskC" /mnt/misc
    - GNU objdump can dissassemble the kernel with something
      like "objdump -s -d $MOUNTPOINT/unix" from Linux, including
      function names but not much else.  But objdump needs to be
      configured with something like:
        ./configure -enable-target=i386-foobar-coff
    - gdb can recognize function names from UNIX kernel if configured
      with something like "./configure -target=i386-foobar-coff".  Use
      qemu's "-s" option, run "gdb $MOUNTPOINT/unix", and issue the
      gdb command "target remote:1234".  After the floppy boots (kernel
      loaded in RAM), but before it accesses the hard disk, I
      could set breakpoints early in panic like "break splintpanic2".
      I could examine registers ("info registers" or
      "info all-registers") and memory, but the call stack
      tended to be truncated early.

==================

Matthew Ogilvie (6):
  fix some debug printf format strings
  target-i386/translate.c: mov to/from crN/drN: ignore mod bits
  vl: fix -hdachs/-hda argument order parsing issues
  qemu-options.hx: mention retrace= VGA option
  vga: add some optional CGA compatibility hacks
  i8259: add -no-spurious-interrupt-hack option

 cpu-exec.c              | 12 +++++----
 hw/cirrus_vga.c         |  4 +--
 hw/i8259.c              | 21 +++++++++++++++-
 hw/ide/cmd646.c         |  5 ++--
 hw/ide/via.c            |  5 ++--
 hw/pc.h                 |  4 +++
 hw/vga.c                | 39 +++++++++++++++++++++++------
 qemu-options.hx         | 38 +++++++++++++++++++++++++++-
 sysemu.h                |  1 +
 target-i386/translate.c | 14 ++++++++---
 vl.c                    | 66 +++++++++++++++++++++++++++++++++----------------
 11 files changed, 163 insertions(+), 46 deletions(-)

-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH v2 1/6] fix some debug printf format strings

[Matthew Ogilvie]

These are normally ifdefed out and don't matter.  But if you enable
them, they ought to be correct.

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---

This version of the patch adds i8259.c.

An alternative approach might be to eliminate these printf's,
and/or replace them with trace*() calls, but until someone gets
around to doing so...

 hw/cirrus_vga.c | 4 ++--
 hw/i8259.c      | 3 ++-
 hw/ide/cmd646.c | 5 +++--
 hw/ide/via.c    | 5 +++--
 4 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index e8dcc6b..909899d 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2055,8 +2055,8 @@ static void cirrus_vga_mem_write(void *opaque,
 	}
     } else {
 #ifdef DEBUG_CIRRUS
-        printf("cirrus: mem_writeb " TARGET_FMT_plx " value %02x\n", addr,
-               mem_value);
+        printf("cirrus: mem_writeb " TARGET_FMT_plx " value %" PRIx64 "\n",
+               addr, mem_value);
 #endif
     }
 }
diff --git a/hw/i8259.c b/hw/i8259.c
index 53daf78..6587666 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -355,7 +355,8 @@ static uint64_t pic_ioport_read(void *opaque, target_phys_addr_t addr,
             ret = s->imr;
         }
     }
-    DPRINTF("read: addr=0x%02x val=0x%02x\n", addr, ret);
+    DPRINTF("read: addr=0x%02" TARGET_PRIxPHYS " val=0x%02x\n",
+            addr, ret);
     return ret;
 }
 
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index e0b9443..dd2855e 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -154,7 +154,7 @@ static uint64_t bmdma_read(void *opaque, target_phys_addr_t addr,
         break;
     }
 #ifdef DEBUG_IDE
-    printf("bmdma: readb 0x%02x : 0x%02x\n", addr, val);
+    printf("bmdma: readb 0x%02" TARGET_PRIxPHYS " : 0x%02x\n", addr, val);
 #endif
     return val;
 }
@@ -170,7 +170,8 @@ static void bmdma_write(void *opaque, target_phys_addr_t addr,
     }
 
 #ifdef DEBUG_IDE
-    printf("bmdma: writeb 0x%02x : 0x%02x\n", addr, val);
+    printf("bmdma: writeb 0x%02" TARGET_PRIxPHYS " : 0x%02" PRIx64 "\n",
+           addr, val);
 #endif
     switch(addr & 3) {
     case 0:
diff --git a/hw/ide/via.c b/hw/ide/via.c
index b20e4f0..948a469 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -55,7 +55,7 @@ static uint64_t bmdma_read(void *opaque, target_phys_addr_t addr,
         break;
     }
 #ifdef DEBUG_IDE
-    printf("bmdma: readb 0x%02x : 0x%02x\n", addr, val);
+    printf("bmdma: readb 0x%02" TARGET_PRIxPHYS " : 0x%02x\n", addr, val);
 #endif
     return val;
 }
@@ -70,7 +70,8 @@ static void bmdma_write(void *opaque, target_phys_addr_t addr,
     }
 
 #ifdef DEBUG_IDE
-    printf("bmdma: writeb 0x%02x : 0x%02x\n", addr, val);
+    printf("bmdma: writeb 0x%02" TARGET_PRIxPHYS " : 0x%02" PRIx64 "\n",
+           addr, val);
 #endif
     switch (addr & 3) {
     case 0:
-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH v2 2/6] target-i386/translate.c: mov to/from crN/drN: ignore mod bits

[Matthew Ogilvie]

>From AMD's documentation (multiple versions of 24594.pdf):
> This instruction is always treated as a register-to-register (MOD = 11)
> instruction, regardless of the encoding of the MOD field in the MODR/M
> byte.

Also, Microport UNIX System V/386 v 2.1 (ca 1987) runs fine on
real Intel 386 and 486 CPU's (at least), but does not run in qemu without
this patch.

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---

This version of the patch tweaks some of the comments to refer to
AMD's documentation, based on "malc <av1474@comtv.ru>"'s response to
version 1.  It is functionally identical.

====================

 target-i386/translate.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/target-i386/translate.c b/target-i386/translate.c
index 7ab2ccb..eb0cabc 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -7551,8 +7551,11 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
             gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
         } else {
             modrm = cpu_ldub_code(cpu_single_env, s->pc++);
-            if ((modrm & 0xc0) != 0xc0)
-                goto illegal_op;
+            /* Ignore the mod bits (assume (modrm&0xc0)==0xc0).
+             * AMD documentation (24594.pdf) and testing of
+             * intel 386 and 486 processors all show that the mod bits
+             * are assumed to be 1's, regardless of actual values.
+             */
             rm = (modrm & 7) | REX_B(s);
             reg = ((modrm >> 3) & 7) | rex_r;
             if (CODE64(s))
@@ -7594,8 +7597,11 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
             gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
         } else {
             modrm = cpu_ldub_code(cpu_single_env, s->pc++);
-            if ((modrm & 0xc0) != 0xc0)
-                goto illegal_op;
+            /* Ignore the mod bits (assume (modrm&0xc0)==0xc0).
+             * AMD documentation (24594.pdf) and testing of
+             * intel 386 and 486 processors all show that the mod bits
+             * are assumed to be 1's, regardless of actual values.
+             */
             rm = (modrm & 7) | REX_B(s);
             reg = ((modrm >> 3) & 7) | rex_r;
             if (CODE64(s))
-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH v2 3/6] vl: fix -hdachs/-hda argument order parsing issues

[Matthew Ogilvie]

Without this patch, the -hdachs argument had to occur either
BEFORE the corresponding "-hda" option, or AFTER the plain
disk image name (if neither -hda nor -drive is used).  Otherwise
it would effectively be ignored.

Option -hdachs still has no effect on -drive, but that seems best.

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---

Version 1 of this patch had the confusing subject
"Re: [Qemu-devel] [PATCH 0/3] Attempting to run Microport UNIX (ca 1987)".

This version reworks things a little to avoid duplicated code between
the "-hda" and "just a file" cases, based on Markus Armbruster's
comments.

An alternative approach would be to just get rid of the -hdachs
option, and require the use of -drive for anything that -hda can't
handle by itself.

================

 vl.c | 39 ++++++++++++++++++---------------------
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/vl.c b/vl.c
index 7c577fa..febfd62 100644
--- a/vl.c
+++ b/vl.c
@@ -2352,8 +2352,9 @@ int main(int argc, char **argv, char **envp)
     char boot_devices[33] = "cad"; /* default to HD->floppy->CD-ROM */
     DisplayState *ds;
     DisplayChangeListener *dcl;
-    int cyls, heads, secs, translation;
-    QemuOpts *hda_opts = NULL, *opts, *machine_opts;
+    char hdachs_params[512];  /* save -hdachs to apply to later -hda */
+    QemuOpts *hda_opts = NULL; /* save -hda to be modified by later -hdachs */
+    QemuOpts *opts, *machine_opts;
     QemuOptsList *olist;
     int optind;
     const char *optarg;
@@ -2408,8 +2409,7 @@ int main(int argc, char **argv, char **envp)
     cpu_model = NULL;
     ram_size = 0;
     snapshot = 0;
-    cyls = heads = secs = 0;
-    translation = BIOS_ATA_TRANSLATION_AUTO;
+    snprintf(hdachs_params, sizeof(hdachs_params), "%s", HD_OPTS);
 
     for (i = 0; i < MAX_NODES; i++) {
         node_mem[i] = 0;
@@ -2457,7 +2457,7 @@ int main(int argc, char **argv, char **envp)
         if (optind >= argc)
             break;
         if (argv[optind][0] != '-') {
-	    hda_opts = drive_add(IF_DEFAULT, 0, argv[optind++], HD_OPTS);
+            hda_opts = drive_add(IF_DEFAULT, 0, argv[optind++], hdachs_params);
         } else {
             const QEMUOption *popt;
 
@@ -2475,21 +2475,8 @@ int main(int argc, char **argv, char **envp)
                 cpu_model = optarg;
                 break;
             case QEMU_OPTION_hda:
-                {
-                    char buf[256];
-                    if (cyls == 0)
-                        snprintf(buf, sizeof(buf), "%s", HD_OPTS);
-                    else
-                        snprintf(buf, sizeof(buf),
-                                 "%s,cyls=%d,heads=%d,secs=%d%s",
-                                 HD_OPTS , cyls, heads, secs,
-                                 translation == BIOS_ATA_TRANSLATION_LBA ?
-                                 ",trans=lba" :
-                                 translation == BIOS_ATA_TRANSLATION_NONE ?
-                                 ",trans=none" : "");
-                    drive_add(IF_DEFAULT, 0, optarg, buf);
-                    break;
-                }
+                hda_opts = drive_add(IF_DEFAULT, 0, optarg, hdachs_params);
+                break;
             case QEMU_OPTION_hdb:
             case QEMU_OPTION_hdc:
             case QEMU_OPTION_hdd:
@@ -2523,7 +2510,10 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_hdachs:
                 {
+                    int cyls, heads, secs, translation;
                     const char *p;
+                    cyls = heads = secs = 0;
+                    translation = BIOS_ATA_TRANSLATION_AUTO;
                     p = optarg;
                     cyls = strtol(p, (char **)&p, 0);
                     if (cyls < 1 || cyls > 16383)
@@ -2555,7 +2545,14 @@ int main(int argc, char **argv, char **envp)
                         fprintf(stderr, "qemu: invalid physical CHS format\n");
                         exit(1);
                     }
-		    if (hda_opts != NULL) {
+                    snprintf(hdachs_params, sizeof(hdachs_params),
+                             "%s,cyls=%d,heads=%d,secs=%d%s",
+                             HD_OPTS , cyls, heads, secs,
+                             translation == BIOS_ATA_TRANSLATION_LBA ?
+                             ",trans=lba" :
+                             translation == BIOS_ATA_TRANSLATION_NONE ?
+                             ",trans=none" : "");
+                    if (hda_opts != NULL) {
                         char num[16];
                         snprintf(num, sizeof(num), "%d", cyls);
                         qemu_opt_set(hda_opts, "cyls", num);
-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH v2 4/6] qemu-options.hx: mention retrace= VGA option

[Matthew Ogilvie]

The feature was added in commit cb5a7aa8c32141bb Sep 2008.
My description is based on "Better VGA retrace emulation (needed
for some DOS games/demos)" from
http://www.boblycat.org/~malc/code/patches/qemu/index.html

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---

This is the first version of this patch.  I noticed this was missing
when I wanted to add documentation for my own VGA option in the next
patch...

=======================

 qemu-options.hx | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 3c411c4..104d228 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -944,7 +944,7 @@ DEF("vga", HAS_ARG, QEMU_OPTION_vga,
     "-vga [std|cirrus|vmware|qxl|xenfb|none]\n"
     "                select video card type\n", QEMU_ARCH_ALL)
 STEXI
-@item -vga @var{type}
+@item -vga @var{type}[,@var{prop}=@var{value}[,...]]
 @findex -vga
 Select type of VGA card to emulate. Valid values for @var{type} are
 @table @option
@@ -971,6 +971,12 @@ Recommended choice when using the spice protocol.
 @item none
 Disable VGA card.
 @end table
+Valid optional properties are
+@table @option
+@item retrace=dumb|precise
+Select dumb (default) or precise VGA retrace logic, useful for some
+DOS games/demos.
+@end table
 ETEXI
 
 DEF("full-screen", 0, QEMU_OPTION_full_screen,
-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH v2 5/6] vga: add some optional CGA compatibility hacks

[Matthew Ogilvie]

This patch adds some optional compatibility hacks (default
disabled) to allow Microport UNIX to function under qemu.

I've tried to structure it to be easy to add more hacks for other
old CGA programs, if anyone ever needs them.

Microport UNIX System V/386 v 2.1 (ca 1987) tries to program
the CGA registers directly with neither the assistance of BIOS, nor
with proper handling of EGA/VGA-only registers.  Note that it didn't
work on real VGA hardware, either (although in that case, the most
obvious problems seemed to be out-of-range hsync and/or vsync
signalling, rather than the issues in this patch).

Eventually real MDA and/or CGA support might provide an alternative to
this patch, although a hybrid approach like this patch might still
be useful in marginal cases.

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---

Note: checkpatches.pl gives an error about initializing the global 
"int vga_cga_hacks = 0;", even though existing lines near it are
doing the same thing.  Should I give precedence to checkpatches.pl, or
nearby code?

Another approach would be to add real MDA and/or CGA support.
Perhaps "-vga mda" and/or "-vga cga" command line options, and
then make a split off hw/mda.c that is much simplified compared to
vga.c.

Note that even if qemu had a real "-vga cga" option, something like
this patch might still be useful to allow running both old/fragile
CGA programs and newer VGA programs in a single virtual machine.
One downside of real CGA is the relatively ugly low-res font
CGA uses (I think) for text mode, not just graphics mode.

Although irrelevant to UNIX, this idea of implementing old graphics
cards could be further extended:
  - "-vga hgc" (Hercules) support would probably be easy to add
    to MDA, after MDA was cleanly separated out.
  - "-vga hgc+cga", (or perhaps "-vga hgc,secondary=cga",
    or something else), to support a dual graphics card
    configurations.  I believe the real hardware supported various
    combinations: "(hgc|mda)\+(cga|std|...)",
    "(cga|std|...)\+(hgc|mda)", "cga\+(std|...)", and "(std|...)\+cga".
    Also, with a PCI bus, two of the same kind of card may be supported
    in some cases.  In such a configuration, I would expect each
    graphics card would have it's own display window in the host OS.
  - Also, in my research about CGA stuff, I noticed that there were
    a few other old rare cards that appear to be minor variations of CGA
    and/or MDA (a combination CGA/HGC, a color HGC, a higher-resolution
    CGA, etc).  Once you had a clean plain-CGA implementation,
    many of these could probably be implemented as optional enable flags
    fairly easily.

Does anyone have any thoughts about the best way of adding MDA, HGC,
CGA, or similar old video cards to qemu?

========================

 hw/pc.h         |  4 ++++
 hw/vga.c        | 39 +++++++++++++++++++++++++++++++--------
 qemu-options.hx | 19 +++++++++++++++++++
 vl.c            | 23 +++++++++++++++++++++++
 4 files changed, 77 insertions(+), 8 deletions(-)

diff --git a/hw/pc.h b/hw/pc.h
index e4db071..37e2f87 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -176,6 +176,10 @@ enum vga_retrace_method {
 
 extern enum vga_retrace_method vga_retrace_method;
 
+#define VGA_CGA_HACK_PALETTE_BLANKING  (1<<0)
+#define VGA_CGA_HACK_FONT_HEIGHT       (1<<1)
+extern int vga_cga_hacks;
+
 static inline DeviceState *isa_vga_init(ISABus *bus)
 {
     ISADevice *dev;
diff --git a/hw/vga.c b/hw/vga.c
index f82ced8..08ec4bd 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -547,14 +547,31 @@ void vga_ioport_write(void *opaque, uint32_t addr, uint32_t val)
         printf("vga: write CR%x = 0x%02x\n", s->cr_index, val);
 #endif
         /* handle CR0-7 protection */
-        if ((s->cr[VGA_CRTC_V_SYNC_END] & VGA_CR11_LOCK_CR0_CR7) &&
-            s->cr_index <= VGA_CRTC_OVERFLOW) {
-            /* can always write bit 4 of CR7 */
-            if (s->cr_index == VGA_CRTC_OVERFLOW) {
-                s->cr[VGA_CRTC_OVERFLOW] = (s->cr[VGA_CRTC_OVERFLOW] & ~0x10) |
-                    (val & 0x10);
+        if (s->cr[VGA_CRTC_V_SYNC_END] & VGA_CR11_LOCK_CR0_CR7) {
+            if (s->cr_index <= VGA_CRTC_OVERFLOW) {
+                /* can always write bit 4 of CR7 */
+                if (s->cr_index == VGA_CRTC_OVERFLOW) {
+                    s->cr[VGA_CRTC_OVERFLOW] =
+                        (s->cr[VGA_CRTC_OVERFLOW] & ~0x10) | (val & 0x10);
+                }
+                return;
+            } else if ((vga_cga_hacks & VGA_CGA_HACK_FONT_HEIGHT) &&
+                       !(s->sr[VGA_SEQ_CLOCK_MODE] & VGA_SR01_CHAR_CLK_8DOTS)) {
+                /* extra CGA compatibility hacks (not in standard VGA) */
+                if (s->cr_index == VGA_CRTC_MAX_SCAN &&
+                    val == 7 &&
+                    (s->cr[VGA_CRTC_MAX_SCAN] & 0xf) == 0xf) {
+                    return;
+                } else if (s->cr_index == VGA_CRTC_CURSOR_START &&
+                           val == 6 &&
+                           (s->cr[VGA_CRTC_MAX_SCAN] & 0xf) == 0xf) {
+                    val = 0xd;
+                } else if (s->cr_index == VGA_CRTC_CURSOR_END &&
+                           val == 7 &&
+                           (s->cr[VGA_CRTC_MAX_SCAN] & 0xf) == 0xf) {
+                    val = 0xe;
+                }
             }
-            return;
         }
         s->cr[s->cr_index] = val;
 
@@ -1886,7 +1906,10 @@ static void vga_update_display(void *opaque)
         /* nothing to do */
     } else {
         full_update = 0;
-        if (!(s->ar_index & 0x20)) {
+        if (!(s->ar_index & 0x20) &&
+            /* extra CGA compatibility hacks (not in standard VGA */
+            (!(vga_cga_hacks & VGA_CGA_HACK_PALETTE_BLANKING) ||
+             (s->ar_index != 0 && s->ar_flip_flop))) {
             graphic_mode = GMODE_BLANK;
         } else {
             graphic_mode = s->gr[VGA_GFX_MISC] & VGA_GR06_GRAPHICS_MODE;
diff --git a/qemu-options.hx b/qemu-options.hx
index 104d228..03e13ec 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -975,6 +975,25 @@ Valid optional properties are
 @item retrace=dumb|precise
 Select dumb (default) or precise VGA retrace logic, useful for some
 DOS games/demos.
+@item cga_hacks=@var{hack1}[+@var{hack2},[...]]
+Enable various extra CGA compatibility hacks for programs that are
+trying to directly set CGA modes without BIOS assistance nor
+real knowledge of EGA/VGA.  These might only work with -vga std.
+Valid hacks are
+@table @option
+@item palette_blanking
+Wait to blank the screen until palette registers seem to actually be
+modified, instead of blanking it as soon as the palette address bit (0x10)
+of the attribute address register (0x3c0) is cleared.
+@item font_height
+Ignore attempts to change the VGA font height (index 9),
+cursor start (index 10), and cursor end (index 11) of the CRTC control
+registers (0x3d5) if trying to set them to the default for CGA fonts
+instead of VGA fonts.
+@item all
+Enable all CGA hacks.  More CGA hacks may be added in future versions
+of qemu.
+@end table
 @end table
 ETEXI
 
diff --git a/vl.c b/vl.c
index febfd62..16d04a2 100644
--- a/vl.c
+++ b/vl.c
@@ -179,6 +179,7 @@ int main(int argc, char **argv)
 static const char *data_dir;
 const char *bios_name = NULL;
 enum vga_retrace_method vga_retrace_method = VGA_RETRACE_DUMB;
+int vga_cga_hacks = 0;
 DisplayType display_type = DT_DEFAULT;
 int display_remote = 0;
 const char* keyboard_layout = NULL;
@@ -1748,6 +1749,28 @@ static void select_vgahw (const char *p)
             else if (strstart(opts, "precise", &nextopt))
                 vga_retrace_method = VGA_RETRACE_PRECISE;
             else goto invalid_vga;
+        } else if (strstart(opts, ",cga_hacks=", &nextopt)) {
+            opts = nextopt;
+            while (*opts) {
+                if (strstart(opts, "all", &nextopt)) {
+                    opts = nextopt;
+                    vga_cga_hacks |= ~0;
+                } else if (strstart(opts, "palette_blanking", &nextopt)) {
+                    opts = nextopt;
+                    vga_cga_hacks |= VGA_CGA_HACK_PALETTE_BLANKING;
+                } else if (strstart(opts, "font_height", &nextopt)) {
+                    opts = nextopt;
+                    vga_cga_hacks |= VGA_CGA_HACK_FONT_HEIGHT;
+                } else {
+                    break;
+                }
+
+                if (*opts == '+') {
+                    opts++;
+                } else {
+                    break;
+                }
+            }
         } else goto invalid_vga;
         opts = nextopt;
     }
-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH v2 6/6] i8259: add -no-spurious-interrupt-hack option

[Matthew Ogilvie]

This patch provides a way to optionally suppress spurious interrupts,
as a workaround for systems described below:

Some old operating systems do not handle spurious interrupts well,
and qemu tends to generate them significantly more often than
real hardware.

Examples:
  - Microport UNIX System V/386 v 2.1 (ca 1987)
    (The main problem I'm fixing: Without this patch, it panics
    sporadically when accessing the hard disk.)
  - AT&T UNIX System V/386 Release 4.0 Version 2.1a (ca 1991)
    See screenshot in "QEMU Official OS Support List":
    http://www.claunia.com/qemu/objectManager.php?sClass=application&iId=9
    (I don't have this system to test.)
  - A report about OS/2 boot lockup from 2004 by Hampa Hug:
    http://lists.nongnu.org/archive/html/qemu-devel/2004-09/msg00367.html
    (My patch was partially inspired by his.)
    Also: http://lists.nongnu.org/archive/html/qemu-devel/2005-06/msg00243.html
    (I don't have this system to test.)

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---

Note: checkpatches.pl gives an error about initializing the global 
"int no_spurious_interrupt_hack = 0;", even though existing lines
near it are doing the same thing.  Should I give precedence to
checkpatches.pl, or nearby code?

There was no version 1 of this patch; this was the last thing I had to
work around to get UNIX running.

High level symptoms:
   1. Despite using this UNIX system for nearly 10 years (ca 1987-1996)
      on an early 80386, I don't remember ever seeing any crash like
      this.  I vaguely remember I may have had one or two crashes for
      which I don't have other explanations that perhaps could have
      been this, but I don't remember the error messages to confirm it.
   2. It is somewhat random when UNIX crashes when running in qemu.
       - Sometimes it crashes the first time the floppy-based installer
         tries to access the hard disk (partition table?).
       - Other times (though fairly rarely), it actually finishes
         formatting and copying the first disk's files to the
         hard disk without crashing.
       - On the other hand, I've never seen it successfully boot from
         the hard disk without this patch.  An attempt to boot from
         the hard drive always panics quite early.
   3. I tried -win2k-hack instead, thinking maybe the hard disk is just
      responding faster than UNIX expected.  But it doesn't seem
      to have any effect.  UNIX still panics sporadically the same way.
       - TANGENT: I was going to see if my patch provides an
         alternative fix for installing Windows 2000, but
         I was unable to reproduce the original -win2k-hack problem at
         all (with neither -win2k-hack NOR this patch).  Maybe
         some other change has fixed it some other way?  Or maybe
         it is only an issue in configurations I didn't test?
         (KVM instead of TCG?  Less RAM?  Something else?)
            It might be worth doing a little more investigation,
         and eliminating the -win2k-hack option if appropriate.
   4. If I enable KVM, I get a different error very early in
      bootup (in splx function instead of splint), and this patch
      doesn't help.

============
My low level analysis of what is going on:

It is hard to track down all the details, but based on logging a
lot of qemu IRQ stuff, and setting a breakpoint in the earliest
panic-related UNIX function using gdb, it looks like:

   1. It is near the end of servicing a previous IRQ14 from the
      hard disk.
   2. The processor has interrupts disabled (I think), while UNIX
      clears the slave 8259's IMR (mask) register (sets it to 0), allowing
      all interrupts to be passed on to the master.
   3. While in that state, IRQ14 is raised (on the slave), which
      gets propagated to the master (IRQ2), but the CPU
      is not interrupted yet.
   4. UNIX then masks the slave 8259's IMR register
      completely (sets to 0xff).
   5. Because the master elcr register is set (by BIOS; UNIX never
      touches it) to edge trigger for IRQ2, the master latched on
      to IRQ2 earlier, and continues to assert the processors INT line
      (the env->interrupt_request&CPU_INTERRUPT_HARD bit) even
      after all slave IRQs have been masked off (clearing the input
      IRQ2).
   6. Finally, UNIX enables CPU interrupts and the interrupt is delivered
      to the CPU, which ends up as a spurious IRQ15 due to the
      slave's imr register.  UNIX doesn't know what to do with
      that, and panics/halts.

I'm not sure why it only sporadically hits this sequence of events.
There doesn't seem to be other IRQs asserted or serviced anywhere
in the near past; the last several were all IRQ14's.  But I can't
help feeling I'm not reading the log output correctly or something,
because that doesn't make sense.  Maybe there is there some kind
of a-few-instructions delay before a CPU interrupt is actually
deliviered after interrupts are enabled, or some delay in raising
IRQ14 after a hard drive operation is requested, and such delays
need to fall into a narrow window of opportunity left by UNIX?

I can get a disassembly of the UNIX kernel using a "coff"-enabled
build of GNU objdump, giving function names but not much else.
But I haven't studied it in enough detail to actually find the
relevant code path that is manipulating imr as described above.
However, this old post outlines some of the high level theory
of UNIX spl*() functions:
http://www.linuxmisc.com/29-unix-internals/4e6c1f6fa2e41670.htm

If anyone wants to look into this further, I can provide access to the
initial boot install floppy, at least.  Email me.  (Without the rest
of the install disks, it isn't much use for anything except testing
virtual machines like qemu against rare corner cases...)

============
Alternative Approaches:

An alternative to this patch that might work (I haven't tried) would
be to have BIOS set the master's elcr register 0x04 bit, making IRQ2
level triggered instead of edge triggered.  I'm not sure what other
effects this might have.  Maybe it would actually be a more accurate
model (I haven't checked documentation; maybe "slave mode" of a
IRQ line into the master is supposed to be level triggered?)

Or perhaps find a way to model the minimum timescale that a interrupt
request needs to be active to be recognized?

Or maybe my analysis isn't correct; I wasn't able to find the
relevant code path in the UNIX kernel.

============

 cpu-exec.c      | 12 +++++++-----
 hw/i8259.c      | 18 ++++++++++++++++++
 qemu-options.hx | 12 ++++++++++++
 sysemu.h        |  1 +
 vl.c            |  4 ++++
 5 files changed, 42 insertions(+), 5 deletions(-)

diff --git a/cpu-exec.c b/cpu-exec.c
index 134b3c4..c309847 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -329,11 +329,15 @@ int cpu_exec(CPUArchState *env)
                                                           0);
                             env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ);
                             intno = cpu_get_pic_interrupt(env);
-                            qemu_log_mask(CPU_LOG_TB_IN_ASM, "Servicing hardware INT=0x%02x\n", intno);
-                            do_interrupt_x86_hardirq(env, intno, 1);
-                            /* ensure that no TB jump will be modified as
-                               the program flow was changed */
-                            next_tb = 0;
+                            if (intno >= 0) {
+                                qemu_log_mask(CPU_LOG_TB_IN_ASM,
+                                              "Servicing hardware INT=0x%02x\n",
+                                              intno);
+                                do_interrupt_x86_hardirq(env, intno, 1);
+                                /* ensure that no TB jump will be modified as
+                                   the program flow was changed */
+                                next_tb = 0;
+                            }
 #if !defined(CONFIG_USER_ONLY)
                         } else if ((interrupt_request & CPU_INTERRUPT_VIRQ) &&
                                    (env->eflags & IF_MASK) && 
diff --git a/hw/i8259.c b/hw/i8259.c
index 6587666..7ecb7e1 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -26,6 +26,7 @@
 #include "isa.h"
 #include "monitor.h"
 #include "qemu-timer.h"
+#include "sysemu.h"
 #include "i8259_internal.h"
 
 /* debug PIC */
@@ -193,6 +194,20 @@ int pic_read_irq(DeviceState *d)
                 pic_intack(slave_pic, irq2);
             } else {
                 /* spurious IRQ on slave controller */
+                if (no_spurious_interrupt_hack) {
+                    /* Pretend it was delivered and acknowledged.  If
+                     * it was spurious due to slave_pic->imr, then
+                     * as soon as the mask is cleared, the slave will
+                     * re-trigger IRQ2 on the master.  If it is spurious for
+                     * some other reason, make sure we don't keep trying
+                     * to half-process the same spurious interrupt over
+                     * and over again.
+                     */
+                    s->irr &= ~(1<<irq);
+                    s->last_irr &= ~(1<<irq);
+                    s->isr &= ~(1<<irq);
+                    return -1;
+                }
                 irq2 = 7;
             }
             intno = slave_pic->irq_base + irq2;
@@ -202,6 +217,9 @@ int pic_read_irq(DeviceState *d)
         pic_intack(s, irq);
     } else {
         /* spurious IRQ on host controller */
+        if (no_spurious_interrupt_hack) {
+            return -1;
+        }
         irq = 7;
         intno = s->irq_base + irq;
     }
diff --git a/qemu-options.hx b/qemu-options.hx
index 03e13ec..57bb0b4 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1188,6 +1188,18 @@ Windows 2000 is installed, you no longer need this option (this option
 slows down the IDE transfers).
 ETEXI
 
+DEF("no-spurious-interrupt-hack", 0, QEMU_OPTION_no_spurious_interrupt_hack,
+    "-no-spurious-interrupt-hack     disable delivery of spurious interrupts\n",
+    QEMU_ARCH_I386)
+STEXI
+@item -no-spurious-interrupt-hack
+@findex -no-spurious-interrupt-hack
+Use it as a workaround for operating systems that drive PICs in a way that
+can generate spurious interrupts, but the OS doesn't handle spurious
+interrupts gracefully.  (e.g. late 80s/early 90s versions of ATT UNIX
+and derivatives)
+ETEXI
+
 HXCOMM Deprecated by -rtc
 DEF("rtc-td-hack", 0, QEMU_OPTION_rtc_td_hack, "", QEMU_ARCH_I386)
 
diff --git a/sysemu.h b/sysemu.h
index 65552ac..0170109 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -117,6 +117,7 @@ extern int graphic_depth;
 extern DisplayType display_type;
 extern const char *keyboard_layout;
 extern int win2k_install_hack;
+extern int no_spurious_interrupt_hack;
 extern int alt_grab;
 extern int ctrl_grab;
 extern int usb_enabled;
diff --git a/vl.c b/vl.c
index 16d04a2..6de41c1 100644
--- a/vl.c
+++ b/vl.c
@@ -204,6 +204,7 @@ CharDriverState *serial_hds[MAX_SERIAL_PORTS];
 CharDriverState *parallel_hds[MAX_PARALLEL_PORTS];
 CharDriverState *virtcon_hds[MAX_VIRTIO_CONSOLES];
 int win2k_install_hack = 0;
+int no_spurious_interrupt_hack = 0;
 int usb_enabled = 0;
 int singlestep = 0;
 int smp_cpus = 1;
@@ -3046,6 +3047,9 @@ int main(int argc, char **argv, char **envp)
             case QEMU_OPTION_win2k_hack:
                 win2k_install_hack = 1;
                 break;
+            case QEMU_OPTION_no_spurious_interrupt_hack:
+                no_spurious_interrupt_hack = 1;
+                break;
             case QEMU_OPTION_rtc_td_hack: {
                 static GlobalProperty slew_lost_ticks[] = {
                     {
-- 
1.7.10.2.484.gcd07cc5

Re: [Qemu-devel] [PATCH v2 1/6] fix some debug printf format strings

[Andreas Färber]

Hi,

Am 23.08.2012 08:24, schrieb Matthew Ogilvie:
> These are normally ifdefed out and don't matter.  But if you enable
> them, they ought to be correct.
> 
> Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
> ---
> 
> This version of the patch adds i8259.c.
> 
> An alternative approach might be to eliminate these printf's,
> and/or replace them with trace*() calls, but until someone gets
> around to doing so...
> 
>  hw/cirrus_vga.c | 4 ++--
>  hw/i8259.c      | 3 ++-
>  hw/ide/cmd646.c | 5 +++--
>  hw/ide/via.c    | 5 +++--
>  4 files changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
> index e8dcc6b..909899d 100644
> --- a/hw/cirrus_vga.c
> +++ b/hw/cirrus_vga.c
> @@ -2055,8 +2055,8 @@ static void cirrus_vga_mem_write(void *opaque,
>  	}
>      } else {
>  #ifdef DEBUG_CIRRUS
> -        printf("cirrus: mem_writeb " TARGET_FMT_plx " value %02x\n", addr,
> -               mem_value);
> +        printf("cirrus: mem_writeb " TARGET_FMT_plx " value %" PRIx64 "\n",
> +               addr, mem_value);

This one is dropping 02.

The other ones looks okay on brief look (declaration of "value" invisible).

Regards,
Andreas

>  #endif
>      }
>  }
> diff --git a/hw/i8259.c b/hw/i8259.c
> index 53daf78..6587666 100644
> --- a/hw/i8259.c
> +++ b/hw/i8259.c
> @@ -355,7 +355,8 @@ static uint64_t pic_ioport_read(void *opaque, target_phys_addr_t addr,
>              ret = s->imr;
>          }
>      }
> -    DPRINTF("read: addr=0x%02x val=0x%02x\n", addr, ret);
> +    DPRINTF("read: addr=0x%02" TARGET_PRIxPHYS " val=0x%02x\n",
> +            addr, ret);
>      return ret;
>  }
>  
> diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
> index e0b9443..dd2855e 100644
> --- a/hw/ide/cmd646.c
> +++ b/hw/ide/cmd646.c
> @@ -154,7 +154,7 @@ static uint64_t bmdma_read(void *opaque, target_phys_addr_t addr,
>          break;
>      }
>  #ifdef DEBUG_IDE
> -    printf("bmdma: readb 0x%02x : 0x%02x\n", addr, val);
> +    printf("bmdma: readb 0x%02" TARGET_PRIxPHYS " : 0x%02x\n", addr, val);
>  #endif
>      return val;
>  }
> @@ -170,7 +170,8 @@ static void bmdma_write(void *opaque, target_phys_addr_t addr,
>      }
>  
>  #ifdef DEBUG_IDE
> -    printf("bmdma: writeb 0x%02x : 0x%02x\n", addr, val);
> +    printf("bmdma: writeb 0x%02" TARGET_PRIxPHYS " : 0x%02" PRIx64 "\n",
> +           addr, val);
>  #endif
>      switch(addr & 3) {
>      case 0:
> diff --git a/hw/ide/via.c b/hw/ide/via.c
> index b20e4f0..948a469 100644
> --- a/hw/ide/via.c
> +++ b/hw/ide/via.c
> @@ -55,7 +55,7 @@ static uint64_t bmdma_read(void *opaque, target_phys_addr_t addr,
>          break;
>      }
>  #ifdef DEBUG_IDE
> -    printf("bmdma: readb 0x%02x : 0x%02x\n", addr, val);
> +    printf("bmdma: readb 0x%02" TARGET_PRIxPHYS " : 0x%02x\n", addr, val);
>  #endif
>      return val;
>  }
> @@ -70,7 +70,8 @@ static void bmdma_write(void *opaque, target_phys_addr_t addr,
>      }
>  
>  #ifdef DEBUG_IDE
> -    printf("bmdma: writeb 0x%02x : 0x%02x\n", addr, val);
> +    printf("bmdma: writeb 0x%02" TARGET_PRIxPHYS " : 0x%02" PRIx64 "\n",
> +           addr, val);
>  #endif
>      switch (addr & 3) {
>      case 0:
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[malc]

On Thu, 23 Aug 2012, Matthew Ogilvie wrote:

> After applying this version 2 of this patch series, I can
> successfully run "Micoport UNIX System V/386, v 2.1" (ca 1987)
> under qemu.  (although not if I try to enable KVM)
> 
> Version 1 of this series was posted about 4 weeks ago.  See
> http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654
> 
> The patches are all independent, except that the documentation part
> of patch 5 (vga) adds onto patch 4 (retrace=) changes.

[..snip..]

Applied, thanks.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH v2 6/6] i8259: add -no-spurious-interrupt-hack option

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 11528 bytes --]

On 2012-08-23 08:24, Matthew Ogilvie wrote:
> This patch provides a way to optionally suppress spurious interrupts,
> as a workaround for systems described below:
> 
> Some old operating systems do not handle spurious interrupts well,
> and qemu tends to generate them significantly more often than
> real hardware.
> 
> Examples:
>   - Microport UNIX System V/386 v 2.1 (ca 1987)
>     (The main problem I'm fixing: Without this patch, it panics
>     sporadically when accessing the hard disk.)
>   - AT&T UNIX System V/386 Release 4.0 Version 2.1a (ca 1991)
>     See screenshot in "QEMU Official OS Support List":
>     http://www.claunia.com/qemu/objectManager.php?sClass=application&iId=9
>     (I don't have this system to test.)
>   - A report about OS/2 boot lockup from 2004 by Hampa Hug:
>     http://lists.nongnu.org/archive/html/qemu-devel/2004-09/msg00367.html
>     (My patch was partially inspired by his.)
>     Also: http://lists.nongnu.org/archive/html/qemu-devel/2005-06/msg00243.html
>     (I don't have this system to test.)
> 
> Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
> ---
> 
> Note: checkpatches.pl gives an error about initializing the global 
> "int no_spurious_interrupt_hack = 0;", even though existing lines
> near it are doing the same thing.  Should I give precedence to
> checkpatches.pl, or nearby code?
> 
> There was no version 1 of this patch; this was the last thing I had to
> work around to get UNIX running.
> 
> High level symptoms:
>    1. Despite using this UNIX system for nearly 10 years (ca 1987-1996)
>       on an early 80386, I don't remember ever seeing any crash like
>       this.  I vaguely remember I may have had one or two crashes for
>       which I don't have other explanations that perhaps could have
>       been this, but I don't remember the error messages to confirm it.
>    2. It is somewhat random when UNIX crashes when running in qemu.
>        - Sometimes it crashes the first time the floppy-based installer
>          tries to access the hard disk (partition table?).
>        - Other times (though fairly rarely), it actually finishes
>          formatting and copying the first disk's files to the
>          hard disk without crashing.
>        - On the other hand, I've never seen it successfully boot from
>          the hard disk without this patch.  An attempt to boot from
>          the hard drive always panics quite early.
>    3. I tried -win2k-hack instead, thinking maybe the hard disk is just
>       responding faster than UNIX expected.  But it doesn't seem
>       to have any effect.  UNIX still panics sporadically the same way.
>        - TANGENT: I was going to see if my patch provides an
>          alternative fix for installing Windows 2000, but
>          I was unable to reproduce the original -win2k-hack problem at
>          all (with neither -win2k-hack NOR this patch).  Maybe
>          some other change has fixed it some other way?  Or maybe
>          it is only an issue in configurations I didn't test?
>          (KVM instead of TCG?  Less RAM?  Something else?)
>             It might be worth doing a little more investigation,
>          and eliminating the -win2k-hack option if appropriate.
>    4. If I enable KVM, I get a different error very early in
>       bootup (in splx function instead of splint), and this patch
>       doesn't help.
> 
> ============
> My low level analysis of what is going on:
> 
> It is hard to track down all the details, but based on logging a
> lot of qemu IRQ stuff, and setting a breakpoint in the earliest
> panic-related UNIX function using gdb, it looks like:
> 
>    1. It is near the end of servicing a previous IRQ14 from the
>       hard disk.
>    2. The processor has interrupts disabled (I think), while UNIX
>       clears the slave 8259's IMR (mask) register (sets it to 0), allowing
>       all interrupts to be passed on to the master.
>    3. While in that state, IRQ14 is raised (on the slave), which
>       gets propagated to the master (IRQ2), but the CPU
>       is not interrupted yet.
>    4. UNIX then masks the slave 8259's IMR register
>       completely (sets to 0xff).
>    5. Because the master elcr register is set (by BIOS; UNIX never
>       touches it) to edge trigger for IRQ2, the master latched on
>       to IRQ2 earlier, and continues to assert the processors INT line
>       (the env->interrupt_request&CPU_INTERRUPT_HARD bit) even
>       after all slave IRQs have been masked off (clearing the input
>       IRQ2).
>    6. Finally, UNIX enables CPU interrupts and the interrupt is delivered
>       to the CPU, which ends up as a spurious IRQ15 due to the
>       slave's imr register.  UNIX doesn't know what to do with
>       that, and panics/halts.
> 
> I'm not sure why it only sporadically hits this sequence of events.
> There doesn't seem to be other IRQs asserted or serviced anywhere
> in the near past; the last several were all IRQ14's.  But I can't
> help feeling I'm not reading the log output correctly or something,
> because that doesn't make sense.  Maybe there is there some kind
> of a-few-instructions delay before a CPU interrupt is actually
> deliviered after interrupts are enabled, or some delay in raising
> IRQ14 after a hard drive operation is requested, and such delays
> need to fall into a narrow window of opportunity left by UNIX?
> 
> I can get a disassembly of the UNIX kernel using a "coff"-enabled
> build of GNU objdump, giving function names but not much else.
> But I haven't studied it in enough detail to actually find the
> relevant code path that is manipulating imr as described above.
> However, this old post outlines some of the high level theory
> of UNIX spl*() functions:
> http://www.linuxmisc.com/29-unix-internals/4e6c1f6fa2e41670.htm
> 
> If anyone wants to look into this further, I can provide access to the
> initial boot install floppy, at least.  Email me.  (Without the rest
> of the install disks, it isn't much use for anything except testing
> virtual machines like qemu against rare corner cases...)
> 
> ============
> Alternative Approaches:
> 
> An alternative to this patch that might work (I haven't tried) would
> be to have BIOS set the master's elcr register 0x04 bit, making IRQ2
> level triggered instead of edge triggered.  I'm not sure what other
> effects this might have.  Maybe it would actually be a more accurate
> model (I haven't checked documentation; maybe "slave mode" of a
> IRQ line into the master is supposed to be level triggered?)
> 
> Or perhaps find a way to model the minimum timescale that a interrupt
> request needs to be active to be recognized?
> 
> Or maybe my analysis isn't correct; I wasn't able to find the
> relevant code path in the UNIX kernel.
> 
> ============
> 
>  cpu-exec.c      | 12 +++++++-----
>  hw/i8259.c      | 18 ++++++++++++++++++
>  qemu-options.hx | 12 ++++++++++++
>  sysemu.h        |  1 +
>  vl.c            |  4 ++++
>  5 files changed, 42 insertions(+), 5 deletions(-)
> 
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 134b3c4..c309847 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -329,11 +329,15 @@ int cpu_exec(CPUArchState *env)
>                                                            0);
>                              env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ);
>                              intno = cpu_get_pic_interrupt(env);
> -                            qemu_log_mask(CPU_LOG_TB_IN_ASM, "Servicing hardware INT=0x%02x\n", intno);
> -                            do_interrupt_x86_hardirq(env, intno, 1);
> -                            /* ensure that no TB jump will be modified as
> -                               the program flow was changed */
> -                            next_tb = 0;
> +                            if (intno >= 0) {
> +                                qemu_log_mask(CPU_LOG_TB_IN_ASM,
> +                                              "Servicing hardware INT=0x%02x\n",
> +                                              intno);
> +                                do_interrupt_x86_hardirq(env, intno, 1);
> +                                /* ensure that no TB jump will be modified as
> +                                   the program flow was changed */
> +                                next_tb = 0;
> +                            }
>  #if !defined(CONFIG_USER_ONLY)
>                          } else if ((interrupt_request & CPU_INTERRUPT_VIRQ) &&
>                                     (env->eflags & IF_MASK) && 
> diff --git a/hw/i8259.c b/hw/i8259.c
> index 6587666..7ecb7e1 100644
> --- a/hw/i8259.c
> +++ b/hw/i8259.c
> @@ -26,6 +26,7 @@
>  #include "isa.h"
>  #include "monitor.h"
>  #include "qemu-timer.h"
> +#include "sysemu.h"
>  #include "i8259_internal.h"
>  
>  /* debug PIC */
> @@ -193,6 +194,20 @@ int pic_read_irq(DeviceState *d)
>                  pic_intack(slave_pic, irq2);
>              } else {
>                  /* spurious IRQ on slave controller */
> +                if (no_spurious_interrupt_hack) {
> +                    /* Pretend it was delivered and acknowledged.  If
> +                     * it was spurious due to slave_pic->imr, then
> +                     * as soon as the mask is cleared, the slave will
> +                     * re-trigger IRQ2 on the master.  If it is spurious for
> +                     * some other reason, make sure we don't keep trying
> +                     * to half-process the same spurious interrupt over
> +                     * and over again.
> +                     */
> +                    s->irr &= ~(1<<irq);
> +                    s->last_irr &= ~(1<<irq);
> +                    s->isr &= ~(1<<irq);
> +                    return -1;
> +                }
>                  irq2 = 7;
>              }
>              intno = slave_pic->irq_base + irq2;
> @@ -202,6 +217,9 @@ int pic_read_irq(DeviceState *d)
>          pic_intack(s, irq);
>      } else {
>          /* spurious IRQ on host controller */
> +        if (no_spurious_interrupt_hack) {
> +            return -1;
> +        }
>          irq = 7;
>          intno = s->irq_base + irq;
>      }
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 03e13ec..57bb0b4 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1188,6 +1188,18 @@ Windows 2000 is installed, you no longer need this option (this option
>  slows down the IDE transfers).
>  ETEXI
>  
> +DEF("no-spurious-interrupt-hack", 0, QEMU_OPTION_no_spurious_interrupt_hack,
> +    "-no-spurious-interrupt-hack     disable delivery of spurious interrupts\n",
> +    QEMU_ARCH_I386)
> +STEXI
> +@item -no-spurious-interrupt-hack
> +@findex -no-spurious-interrupt-hack
> +Use it as a workaround for operating systems that drive PICs in a way that
> +can generate spurious interrupts, but the OS doesn't handle spurious
> +interrupts gracefully.  (e.g. late 80s/early 90s versions of ATT UNIX
> +and derivatives)

Has to mention or even actively warn that it doesn't work with KVM and
its in-kernel irqchip (as that PIC model lacks your hack).

However, I strongly suspect you are nastily papering over an issue in
some device model. So I would prefer to dig deeper before installing
this in upstream (also due to its dependency on the userspace PIC model).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On 2012-08-24 05:58, malc wrote:
> On Thu, 23 Aug 2012, Matthew Ogilvie wrote:
> 
>> After applying this version 2 of this patch series, I can
>> successfully run "Micoport UNIX System V/386, v 2.1" (ca 1987)
>> under qemu.  (although not if I try to enable KVM)
>>
>> Version 1 of this series was posted about 4 weeks ago.  See
>> http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654
>>
>> The patches are all independent, except that the documentation part
>> of patch 5 (vga) adds onto patch 4 (retrace=) changes.
> 
> [..snip..]
> 
> Applied, thanks.

Err, does this comply with the -rcX process? Patch 6 alone has been on
the list for less than a day. Only now I was able to comment on it, and
I would prefer to not have it merged that easily.

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[Peter Maydell]

On 24 August 2012 06:44, Jan Kiszka <jan.kiszka@web.de> wrote:
> On 2012-08-24 05:58, malc wrote:
>> On Thu, 23 Aug 2012, Matthew Ogilvie wrote:
>>
>>> After applying this version 2 of this patch series, I can
>>> successfully run "Micoport UNIX System V/386, v 2.1" (ca 1987)
>>> under qemu.  (although not if I try to enable KVM)
>>>
>>> Version 1 of this series was posted about 4 weeks ago.  See
>>> http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654
>>>
>>> The patches are all independent, except that the documentation part
>>> of patch 5 (vga) adds onto patch 4 (retrace=) changes.
>>
>> [..snip..]
>>
>> Applied, thanks.
>
> Err, does this comply with the -rcX process? Patch 6 alone has been on
> the list for less than a day. Only now I was able to comment on it, and
> I would prefer to not have it merged that easily.

Adding a new command line option certainly looks like a new
feature rather than a bug fix to me, and really shouldn't
be going in at this point in the release cycle in my opinion.
I would suggest that these commits should all be reverted.

Thanks
-- Peter Maydell

Re: [Qemu-devel] [PATCH v2 6/6] i8259: add -no-spurious-interrupt-hack option

[Matthew Ogilvie]

On Fri, Aug 24, 2012 at 07:40:36AM +0200, Jan Kiszka wrote:
> On 2012-08-23 08:24, Matthew Ogilvie wrote:
> > This patch provides a way to optionally suppress spurious interrupts,

[snip]

> > I'm not sure why it only sporadically hits this sequence of events.
> > There doesn't seem to be other IRQs asserted or serviced anywhere
> > in the near past; the last several were all IRQ14's.  But I can't
> > help feeling I'm not reading the log output correctly or something,
> > because that doesn't make sense.  Maybe there is there some kind
> > of a-few-instructions delay before a CPU interrupt is actually
> > deliviered after interrupts are enabled, or some delay in raising
> > IRQ14 after a hard drive operation is requested, and such delays
> > need to fall into a narrow window of opportunity left by UNIX?
> > 
> > I can get a disassembly of the UNIX kernel using a "coff"-enabled
> > build of GNU objdump, giving function names but not much else.
> > But I haven't studied it in enough detail to actually find the
> > relevant code path that is manipulating imr as described above.
> > However, this old post outlines some of the high level theory
> > of UNIX spl*() functions:
> > http://www.linuxmisc.com/29-unix-internals/4e6c1f6fa2e41670.htm
> > 
> > If anyone wants to look into this further, I can provide access to the
> > initial boot install floppy, at least.  Email me.  (Without the rest
> > of the install disks, it isn't much use for anything except testing
> > virtual machines like qemu against rare corner cases...)
> > 
> > ============
> > Alternative Approaches:
> > 
> > An alternative to this patch that might work (I haven't tried) would
> > be to have BIOS set the master's elcr register 0x04 bit, making IRQ2
> > level triggered instead of edge triggered.  I'm not sure what other
> > effects this might have.  Maybe it would actually be a more accurate
> > model (I haven't checked documentation; maybe "slave mode" of a
> > IRQ line into the master is supposed to be level triggered?)
> > 
> > Or perhaps find a way to model the minimum timescale that a interrupt
> > request needs to be active to be recognized?
> > 
> > Or maybe my analysis isn't correct; I wasn't able to find the
> > relevant code path in the UNIX kernel.

[snip]

> 
> Has to mention or even actively warn that it doesn't work with KVM and
> its in-kernel irqchip (as that PIC model lacks your hack).

I'll make an incremental patch to the documentation soon.

> 
> However, I strongly suspect you are nastily papering over an issue in
> some device model. So I would prefer to dig deeper before installing
> this in upstream (also due to its dependency on the userspace PIC model).

This is certainly possible.  I'm not an expert on the whole interrupt
subsystem design in a PC.  But other than the wild speculation above
(making IRQ2 level triggered via elcr, or some kind of timing preventing the
edge triggering from catching a very short blip), I'm not sure what
to look for.

- Matthew Ogilvie

Re: [Qemu-devel] [PATCH v2 6/6] i8259: add -no-spurious-interrupt-hack option

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3460 bytes --]

On 2012-08-24 10:05, Matthew Ogilvie wrote:
> On Fri, Aug 24, 2012 at 07:40:36AM +0200, Jan Kiszka wrote:
>> On 2012-08-23 08:24, Matthew Ogilvie wrote:
>>> This patch provides a way to optionally suppress spurious interrupts,
> 
> [snip]
> 
>>> I'm not sure why it only sporadically hits this sequence of events.
>>> There doesn't seem to be other IRQs asserted or serviced anywhere
>>> in the near past; the last several were all IRQ14's.  But I can't
>>> help feeling I'm not reading the log output correctly or something,
>>> because that doesn't make sense.  Maybe there is there some kind
>>> of a-few-instructions delay before a CPU interrupt is actually
>>> deliviered after interrupts are enabled, or some delay in raising
>>> IRQ14 after a hard drive operation is requested, and such delays
>>> need to fall into a narrow window of opportunity left by UNIX?
>>>
>>> I can get a disassembly of the UNIX kernel using a "coff"-enabled
>>> build of GNU objdump, giving function names but not much else.
>>> But I haven't studied it in enough detail to actually find the
>>> relevant code path that is manipulating imr as described above.
>>> However, this old post outlines some of the high level theory
>>> of UNIX spl*() functions:
>>> http://www.linuxmisc.com/29-unix-internals/4e6c1f6fa2e41670.htm
>>>
>>> If anyone wants to look into this further, I can provide access to the
>>> initial boot install floppy, at least.  Email me.  (Without the rest
>>> of the install disks, it isn't much use for anything except testing
>>> virtual machines like qemu against rare corner cases...)
>>>
>>> ============
>>> Alternative Approaches:
>>>
>>> An alternative to this patch that might work (I haven't tried) would
>>> be to have BIOS set the master's elcr register 0x04 bit, making IRQ2
>>> level triggered instead of edge triggered.  I'm not sure what other
>>> effects this might have.  Maybe it would actually be a more accurate
>>> model (I haven't checked documentation; maybe "slave mode" of a
>>> IRQ line into the master is supposed to be level triggered?)
>>>
>>> Or perhaps find a way to model the minimum timescale that a interrupt
>>> request needs to be active to be recognized?
>>>
>>> Or maybe my analysis isn't correct; I wasn't able to find the
>>> relevant code path in the UNIX kernel.
> 
> [snip]
> 
>>
>> Has to mention or even actively warn that it doesn't work with KVM and
>> its in-kernel irqchip (as that PIC model lacks your hack).
> 
> I'll make an incremental patch to the documentation soon.
> 
>>
>> However, I strongly suspect you are nastily papering over an issue in
>> some device model. So I would prefer to dig deeper before installing
>> this in upstream (also due to its dependency on the userspace PIC model).
> 
> This is certainly possible.  I'm not an expert on the whole interrupt
> subsystem design in a PC.  But other than the wild speculation above
> (making IRQ2 level triggered via elcr, or some kind of timing preventing the
> edge triggering from catching a very short blip), I'm not sure what
> to look for.

Sorry, but as long as we do not understand the problem better, I'm
against such a hack option in upstream. These things have barely any
users and can therefore easily break as no one tests them when
refactoring code. Not to speak of how this is introduce (new top-level
command line switches are "out of fashion").

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[Qemu-devel] [PATCH v3 0/3] Microport UNIX series (was: [PATCH v2 0/6] ...)

[Matthew Ogilvie]

This version is an incremental on top of version 2 to address
various concerns.  At least as of this moment, version 2 has
been applied upstream, so this version is incremental.

On Fri, Aug 24, 2012 at 07:44:16AM +0200, Jan Kiszka wrote:
> On 2012-08-24 05:58, malc wrote:
> > Applied, thanks.
>
> Err, does this comply with the -rcX process? Patch 6 alone has been on
> the list for less than a day. Only now I was able to comment on it, and
> I would prefer to not have it merged that easily.

Although I would prefer to apply these patches, I'm also a little
surprised how quickly they were accepted.  I had thought I had
already missed the merge window.

If the ultimate decision is to leave in some or all of the version 2
patches, then we should probably also include the corresponding
version 3 incremental patches.  Otherwise, if some or all of them
are reverted for the release, I can post a version 4 with version
3 squashed in later.

Overall, the first four patches of version 2 seem more like simple
bug fixes than the last two.  Maybe keep at least the first 4 (possilby
with just the first patch of version 3 as well)?


Matthew Ogilvie (3):
  debug printf (cirrus_vga): fixup unintended format change
  vga cga_hack=palette_blanking: narrower conditions for hack
  doc: mention that -no-spurious-interrupt-hack doesn't work with KVM

 hw/cirrus_vga.c | 2 +-
 hw/vga.c        | 5 +++--
 qemu-options.hx | 5 +++--
 3 files changed, 7 insertions(+), 5 deletions(-)

-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH 1/3] debug printf (cirrus_vga): fixup unintended format change

[Matthew Ogilvie]

I unintentionally dropped an "02" from one of the format strings
in commit 145c7c880ff520a9, as noted by Andreas Färber <afaerber@suse.de>.

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---

The "02" in debug code seems extremely low priority, but on the other
hand, there is no good reason to change it.

 hw/cirrus_vga.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 909899d..68c36f3 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2055,7 +2055,7 @@ static void cirrus_vga_mem_write(void *opaque,
 	}
     } else {
 #ifdef DEBUG_CIRRUS
-        printf("cirrus: mem_writeb " TARGET_FMT_plx " value %" PRIx64 "\n",
+        printf("cirrus: mem_writeb " TARGET_FMT_plx " value %02" PRIx64 "\n",
                addr, mem_value);
 #endif
     }
-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH 2/3] vga cga_hack=palette_blanking: narrower conditions for hack

[Matthew Ogilvie]

In commit 482f7bf86b43af9f, I mistakenly inverted the logic
I intended for ar_flip_flop.  I intended to allow the GMODE_BLANK
case as soon as any palette register was modified.

Also include minor tweak to documentation about how to list
multiple hacks on the command line.

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---
 hw/vga.c        | 5 +++--
 qemu-options.hx | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/vga.c b/hw/vga.c
index a65fc26..fb08dc0 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -1904,9 +1904,10 @@ static void vga_update_display(void *opaque)
     } else {
         full_update = 0;
         if (!(s->ar_index & 0x20) &&
-            /* extra CGA compatibility hacks (not in standard VGA */
+            /* extra CGA compatibility hacks (not in standard VGA) */
             (!(vga_cga_hacks & VGA_CGA_HACK_PALETTE_BLANKING) ||
-             (s->ar_index != 0 && s->ar_flip_flop))) {
+             s->ar_index != 0 ||
+             !s->ar_flip_flop)) {
             graphic_mode = GMODE_BLANK;
         } else {
             graphic_mode = s->gr[VGA_GFX_MISC] & VGA_GR06_GRAPHICS_MODE;
diff --git a/qemu-options.hx b/qemu-options.hx
index 2a6d829..b28e853 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -975,7 +975,7 @@ Valid optional properties are
 @item retrace=dumb|precise
 Select dumb (default) or precise VGA retrace logic, useful for some
 DOS games/demos.
-@item cga_hacks=@var{hack1}[+@var{hack2},[...]]
+@item cga_hacks=@var{hack1}[+@var{hack2}[+...]]
 Enable various extra CGA compatibility hacks for programs that are
 trying to directly set CGA modes without BIOS assistance nor
 real knowledge of EGA/VGA.  These might only work with -vga std.
-- 
1.7.10.2.484.gcd07cc5

[Qemu-devel] [PATCH 3/3] doc: mention that -no-spurious-interrupt-hack doesn't work with KVM

[Matthew Ogilvie]

Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
---

On Fri, Aug 24, 2012 at 07:40:36AM +0200, Jan Kiszka wrote:
> Has to mention or even actively warn that it doesn't work with KVM and
> its in-kernel irqchip (as that PIC model lacks your hack).

 qemu-options.hx | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index b28e853..d6bfc34 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1198,7 +1198,8 @@ STEXI
 Use it as a workaround for operating systems that drive PICs in a way that
 can generate spurious interrupts, but the OS doesn't handle spurious
 interrupts gracefully.  (e.g. late 80s/early 90s versions of ATT UNIX
-and derivatives)
+and derivatives)  Warning: This does not work with KVM's in-kernel
+PIC model.
 ETEXI
 
 HXCOMM Deprecated by -rtc
-- 
1.7.10.2.484.gcd07cc5

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[malc]

On Fri, 24 Aug 2012, Jan Kiszka wrote:

> On 2012-08-24 05:58, malc wrote:
> > On Thu, 23 Aug 2012, Matthew Ogilvie wrote:
> > 
> >> After applying this version 2 of this patch series, I can
> >> successfully run "Micoport UNIX System V/386, v 2.1" (ca 1987)
> >> under qemu.  (although not if I try to enable KVM)
> >>
> >> Version 1 of this series was posted about 4 weeks ago.  See
> >> http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654
> >>
> >> The patches are all independent, except that the documentation part
> >> of patch 5 (vga) adds onto patch 4 (retrace=) changes.
> > 
> > [..snip..]
> > 
> > Applied, thanks.
> 
> Err, does this comply with the -rcX process? Patch 6 alone has been on
> the list for less than a day. Only now I was able to comment on it, and
> I would prefer to not have it merged that easily.
> 

Where's the process documented? As for patch 6 i confess i haven't paid
enough attention and was under impression that this set was mainly about
adjusting the comment about mov crN behavior.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[Jan Kiszka]

On 2012-08-24 14:02, malc wrote:
> On Fri, 24 Aug 2012, Jan Kiszka wrote:
> 
>> On 2012-08-24 05:58, malc wrote:
>>> On Thu, 23 Aug 2012, Matthew Ogilvie wrote:
>>>
>>>> After applying this version 2 of this patch series, I can
>>>> successfully run "Micoport UNIX System V/386, v 2.1" (ca 1987)
>>>> under qemu.  (although not if I try to enable KVM)
>>>>
>>>> Version 1 of this series was posted about 4 weeks ago.  See
>>>> http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654
>>>>
>>>> The patches are all independent, except that the documentation part
>>>> of patch 5 (vga) adds onto patch 4 (retrace=) changes.
>>>
>>> [..snip..]
>>>
>>> Applied, thanks.
>>
>> Err, does this comply with the -rcX process? Patch 6 alone has been on
>> the list for less than a day. Only now I was able to comment on it, and
>> I would prefer to not have it merged that easily.
>>
> 
> Where's the process documented? As for patch 6 i confess i haven't paid
> enough attention and was under impression that this set was mainly about
> adjusting the comment about mov crN behavior.
> 

See http://wiki.qemu.org/Planning/1.2 e.g.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[malc]

On Fri, 24 Aug 2012, Jan Kiszka wrote:

> On 2012-08-24 14:02, malc wrote:
> > On Fri, 24 Aug 2012, Jan Kiszka wrote:
> > 
> >> On 2012-08-24 05:58, malc wrote:
> >>> On Thu, 23 Aug 2012, Matthew Ogilvie wrote:
> >>>
> >>>> After applying this version 2 of this patch series, I can
> >>>> successfully run "Micoport UNIX System V/386, v 2.1" (ca 1987)
> >>>> under qemu.  (although not if I try to enable KVM)
> >>>>
> >>>> Version 1 of this series was posted about 4 weeks ago.  See
> >>>> http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654
> >>>>
> >>>> The patches are all independent, except that the documentation part
> >>>> of patch 5 (vga) adds onto patch 4 (retrace=) changes.
> >>>
> >>> [..snip..]
> >>>
> >>> Applied, thanks.
> >>
> >> Err, does this comply with the -rcX process? Patch 6 alone has been on
> >> the list for less than a day. Only now I was able to comment on it, and
> >> I would prefer to not have it merged that easily.
> >>
> > 
> > Where's the process documented? As for patch 6 i confess i haven't paid
> > enough attention and was under impression that this set was mainly about
> > adjusting the comment about mov crN behavior.
> > 
> 
> See http://wiki.qemu.org/Planning/1.2 e.g.
> 

Thanks.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[Paolo Bonzini]

Il 24/08/2012 09:19, Peter Maydell ha scritto:
>> >
>> > Err, does this comply with the -rcX process? Patch 6 alone has been on
>> > the list for less than a day. Only now I was able to comment on it, and
>> > I would prefer to not have it merged that easily.
> Adding a new command line option certainly looks like a new
> feature rather than a bug fix to me, and really shouldn't
> be going in at this point in the release cycle in my opinion.
> I would suggest that these commits should all be reverted.

Patches 2 and 4 can stay, maybe 3 too.

Patch 1 needs a follow-up that Matthew already posted.

Paolo

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[Peter Maydell]

On 24 August 2012 14:39, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 24/08/2012 09:19, Peter Maydell ha scritto:
>>> > Err, does this comply with the -rcX process? Patch 6 alone has been on
>>> > the list for less than a day. Only now I was able to comment on it, and
>>> > I would prefer to not have it merged that easily.
>> Adding a new command line option certainly looks like a new
>> feature rather than a bug fix to me, and really shouldn't
>> be going in at this point in the release cycle in my opinion.
>> I would suggest that these commits should all be reverted.
>
> Patches 2 and 4 can stay, maybe 3 too.

I tend to be pretty conservative about what I thought ought to
go in during a freeze, and I also think it's much clearer to do
a clean revert of everything and then go through the process
properly from a fresh start.

-- PMM

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[Anthony Liguori]

malc <av1474@comtv.ru> writes:

> On Thu, 23 Aug 2012, Matthew Ogilvie wrote:
>
>> After applying this version 2 of this patch series, I can
>> successfully run "Micoport UNIX System V/386, v 2.1" (ca 1987)
>> under qemu.  (although not if I try to enable KVM)
>> 
>> Version 1 of this series was posted about 4 weeks ago.  See
>> http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654
>> 
>> The patches are all independent, except that the documentation part
>> of patch 5 (vga) adds onto patch 4 (retrace=) changes.
>
> [..snip..]
>
> Applied, thanks.

malc, please revert these patches.

They were not adequately reviewed and they also do not qualify for the
stage of the release we're in.

Regards,

Anthony Liguori

> -- 
> mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH v2 6/6] i8259: add -no-spurious-interrupt-hack option

[Anthony Liguori]

Matthew Ogilvie <mmogilvi_qemu@miniinfo.net> writes:

> This patch provides a way to optionally suppress spurious interrupts,
> as a workaround for systems described below:
>
> Some old operating systems do not handle spurious interrupts well,
> and qemu tends to generate them significantly more often than
> real hardware.

This is the wrong approach.  You add a LostTickPolicy property to the
i8259 device.

Regards,

Anthony Liguori

>
> Examples:
>   - Microport UNIX System V/386 v 2.1 (ca 1987)
>     (The main problem I'm fixing: Without this patch, it panics
>     sporadically when accessing the hard disk.)
>   - AT&T UNIX System V/386 Release 4.0 Version 2.1a (ca 1991)
>     See screenshot in "QEMU Official OS Support List":
>     http://www.claunia.com/qemu/objectManager.php?sClass=application&iId=9
>     (I don't have this system to test.)
>   - A report about OS/2 boot lockup from 2004 by Hampa Hug:
>     http://lists.nongnu.org/archive/html/qemu-devel/2004-09/msg00367.html
>     (My patch was partially inspired by his.)
>     Also: http://lists.nongnu.org/archive/html/qemu-devel/2005-06/msg00243.html
>     (I don't have this system to test.)
>
> Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
> ---
>
> Note: checkpatches.pl gives an error about initializing the global 
> "int no_spurious_interrupt_hack = 0;", even though existing lines
> near it are doing the same thing.  Should I give precedence to
> checkpatches.pl, or nearby code?
>
> There was no version 1 of this patch; this was the last thing I had to
> work around to get UNIX running.
>
> High level symptoms:
>    1. Despite using this UNIX system for nearly 10 years (ca 1987-1996)
>       on an early 80386, I don't remember ever seeing any crash like
>       this.  I vaguely remember I may have had one or two crashes for
>       which I don't have other explanations that perhaps could have
>       been this, but I don't remember the error messages to confirm it.
>    2. It is somewhat random when UNIX crashes when running in qemu.
>        - Sometimes it crashes the first time the floppy-based installer
>          tries to access the hard disk (partition table?).
>        - Other times (though fairly rarely), it actually finishes
>          formatting and copying the first disk's files to the
>          hard disk without crashing.
>        - On the other hand, I've never seen it successfully boot from
>          the hard disk without this patch.  An attempt to boot from
>          the hard drive always panics quite early.
>    3. I tried -win2k-hack instead, thinking maybe the hard disk is just
>       responding faster than UNIX expected.  But it doesn't seem
>       to have any effect.  UNIX still panics sporadically the same way.
>        - TANGENT: I was going to see if my patch provides an
>          alternative fix for installing Windows 2000, but
>          I was unable to reproduce the original -win2k-hack problem at
>          all (with neither -win2k-hack NOR this patch).  Maybe
>          some other change has fixed it some other way?  Or maybe
>          it is only an issue in configurations I didn't test?
>          (KVM instead of TCG?  Less RAM?  Something else?)
>             It might be worth doing a little more investigation,
>          and eliminating the -win2k-hack option if appropriate.
>    4. If I enable KVM, I get a different error very early in
>       bootup (in splx function instead of splint), and this patch
>       doesn't help.
>
> ============
> My low level analysis of what is going on:
>
> It is hard to track down all the details, but based on logging a
> lot of qemu IRQ stuff, and setting a breakpoint in the earliest
> panic-related UNIX function using gdb, it looks like:
>
>    1. It is near the end of servicing a previous IRQ14 from the
>       hard disk.
>    2. The processor has interrupts disabled (I think), while UNIX
>       clears the slave 8259's IMR (mask) register (sets it to 0), allowing
>       all interrupts to be passed on to the master.
>    3. While in that state, IRQ14 is raised (on the slave), which
>       gets propagated to the master (IRQ2), but the CPU
>       is not interrupted yet.
>    4. UNIX then masks the slave 8259's IMR register
>       completely (sets to 0xff).
>    5. Because the master elcr register is set (by BIOS; UNIX never
>       touches it) to edge trigger for IRQ2, the master latched on
>       to IRQ2 earlier, and continues to assert the processors INT line
>       (the env->interrupt_request&CPU_INTERRUPT_HARD bit) even
>       after all slave IRQs have been masked off (clearing the input
>       IRQ2).
>    6. Finally, UNIX enables CPU interrupts and the interrupt is delivered
>       to the CPU, which ends up as a spurious IRQ15 due to the
>       slave's imr register.  UNIX doesn't know what to do with
>       that, and panics/halts.
>
> I'm not sure why it only sporadically hits this sequence of events.
> There doesn't seem to be other IRQs asserted or serviced anywhere
> in the near past; the last several were all IRQ14's.  But I can't
> help feeling I'm not reading the log output correctly or something,
> because that doesn't make sense.  Maybe there is there some kind
> of a-few-instructions delay before a CPU interrupt is actually
> deliviered after interrupts are enabled, or some delay in raising
> IRQ14 after a hard drive operation is requested, and such delays
> need to fall into a narrow window of opportunity left by UNIX?
>
> I can get a disassembly of the UNIX kernel using a "coff"-enabled
> build of GNU objdump, giving function names but not much else.
> But I haven't studied it in enough detail to actually find the
> relevant code path that is manipulating imr as described above.
> However, this old post outlines some of the high level theory
> of UNIX spl*() functions:
> http://www.linuxmisc.com/29-unix-internals/4e6c1f6fa2e41670.htm
>
> If anyone wants to look into this further, I can provide access to the
> initial boot install floppy, at least.  Email me.  (Without the rest
> of the install disks, it isn't much use for anything except testing
> virtual machines like qemu against rare corner cases...)
>
> ============
> Alternative Approaches:
>
> An alternative to this patch that might work (I haven't tried) would
> be to have BIOS set the master's elcr register 0x04 bit, making IRQ2
> level triggered instead of edge triggered.  I'm not sure what other
> effects this might have.  Maybe it would actually be a more accurate
> model (I haven't checked documentation; maybe "slave mode" of a
> IRQ line into the master is supposed to be level triggered?)
>
> Or perhaps find a way to model the minimum timescale that a interrupt
> request needs to be active to be recognized?
>
> Or maybe my analysis isn't correct; I wasn't able to find the
> relevant code path in the UNIX kernel.
>
> ============
>
>  cpu-exec.c      | 12 +++++++-----
>  hw/i8259.c      | 18 ++++++++++++++++++
>  qemu-options.hx | 12 ++++++++++++
>  sysemu.h        |  1 +
>  vl.c            |  4 ++++
>  5 files changed, 42 insertions(+), 5 deletions(-)
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 134b3c4..c309847 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -329,11 +329,15 @@ int cpu_exec(CPUArchState *env)
>                                                            0);
>                              env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ);
>                              intno = cpu_get_pic_interrupt(env);
> -                            qemu_log_mask(CPU_LOG_TB_IN_ASM, "Servicing hardware INT=0x%02x\n", intno);
> -                            do_interrupt_x86_hardirq(env, intno, 1);
> -                            /* ensure that no TB jump will be modified as
> -                               the program flow was changed */
> -                            next_tb = 0;
> +                            if (intno >= 0) {
> +                                qemu_log_mask(CPU_LOG_TB_IN_ASM,
> +                                              "Servicing hardware INT=0x%02x\n",
> +                                              intno);
> +                                do_interrupt_x86_hardirq(env, intno, 1);
> +                                /* ensure that no TB jump will be modified as
> +                                   the program flow was changed */
> +                                next_tb = 0;
> +                            }
>  #if !defined(CONFIG_USER_ONLY)
>                          } else if ((interrupt_request & CPU_INTERRUPT_VIRQ) &&
>                                     (env->eflags & IF_MASK) && 
> diff --git a/hw/i8259.c b/hw/i8259.c
> index 6587666..7ecb7e1 100644
> --- a/hw/i8259.c
> +++ b/hw/i8259.c
> @@ -26,6 +26,7 @@
>  #include "isa.h"
>  #include "monitor.h"
>  #include "qemu-timer.h"
> +#include "sysemu.h"
>  #include "i8259_internal.h"
>  
>  /* debug PIC */
> @@ -193,6 +194,20 @@ int pic_read_irq(DeviceState *d)
>                  pic_intack(slave_pic, irq2);
>              } else {
>                  /* spurious IRQ on slave controller */
> +                if (no_spurious_interrupt_hack) {
> +                    /* Pretend it was delivered and acknowledged.  If
> +                     * it was spurious due to slave_pic->imr, then
> +                     * as soon as the mask is cleared, the slave will
> +                     * re-trigger IRQ2 on the master.  If it is spurious for
> +                     * some other reason, make sure we don't keep trying
> +                     * to half-process the same spurious interrupt over
> +                     * and over again.
> +                     */
> +                    s->irr &= ~(1<<irq);
> +                    s->last_irr &= ~(1<<irq);
> +                    s->isr &= ~(1<<irq);
> +                    return -1;
> +                }
>                  irq2 = 7;
>              }
>              intno = slave_pic->irq_base + irq2;
> @@ -202,6 +217,9 @@ int pic_read_irq(DeviceState *d)
>          pic_intack(s, irq);
>      } else {
>          /* spurious IRQ on host controller */
> +        if (no_spurious_interrupt_hack) {
> +            return -1;
> +        }
>          irq = 7;
>          intno = s->irq_base + irq;
>      }
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 03e13ec..57bb0b4 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1188,6 +1188,18 @@ Windows 2000 is installed, you no longer need this option (this option
>  slows down the IDE transfers).
>  ETEXI
>  
> +DEF("no-spurious-interrupt-hack", 0, QEMU_OPTION_no_spurious_interrupt_hack,
> +    "-no-spurious-interrupt-hack     disable delivery of spurious interrupts\n",
> +    QEMU_ARCH_I386)
> +STEXI
> +@item -no-spurious-interrupt-hack
> +@findex -no-spurious-interrupt-hack
> +Use it as a workaround for operating systems that drive PICs in a way that
> +can generate spurious interrupts, but the OS doesn't handle spurious
> +interrupts gracefully.  (e.g. late 80s/early 90s versions of ATT UNIX
> +and derivatives)
> +ETEXI
> +
>  HXCOMM Deprecated by -rtc
>  DEF("rtc-td-hack", 0, QEMU_OPTION_rtc_td_hack, "", QEMU_ARCH_I386)
>  
> diff --git a/sysemu.h b/sysemu.h
> index 65552ac..0170109 100644
> --- a/sysemu.h
> +++ b/sysemu.h
> @@ -117,6 +117,7 @@ extern int graphic_depth;
>  extern DisplayType display_type;
>  extern const char *keyboard_layout;
>  extern int win2k_install_hack;
> +extern int no_spurious_interrupt_hack;
>  extern int alt_grab;
>  extern int ctrl_grab;
>  extern int usb_enabled;
> diff --git a/vl.c b/vl.c
> index 16d04a2..6de41c1 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -204,6 +204,7 @@ CharDriverState *serial_hds[MAX_SERIAL_PORTS];
>  CharDriverState *parallel_hds[MAX_PARALLEL_PORTS];
>  CharDriverState *virtcon_hds[MAX_VIRTIO_CONSOLES];
>  int win2k_install_hack = 0;
> +int no_spurious_interrupt_hack = 0;
>  int usb_enabled = 0;
>  int singlestep = 0;
>  int smp_cpus = 1;
> @@ -3046,6 +3047,9 @@ int main(int argc, char **argv, char **envp)
>              case QEMU_OPTION_win2k_hack:
>                  win2k_install_hack = 1;
>                  break;
> +            case QEMU_OPTION_no_spurious_interrupt_hack:
> +                no_spurious_interrupt_hack = 1;
> +                break;
>              case QEMU_OPTION_rtc_td_hack: {
>                  static GlobalProperty slew_lost_ticks[] = {
>                      {
> -- 
> 1.7.10.2.484.gcd07cc5

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[malc]

On Mon, 27 Aug 2012, Anthony Liguori wrote:

> malc <av1474@comtv.ru> writes:
> 
> > On Thu, 23 Aug 2012, Matthew Ogilvie wrote:
> >
> >> After applying this version 2 of this patch series, I can
> >> successfully run "Micoport UNIX System V/386, v 2.1" (ca 1987)
> >> under qemu.  (although not if I try to enable KVM)
> >> 
> >> Version 1 of this series was posted about 4 weeks ago.  See
> >> http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654
> >> 
> >> The patches are all independent, except that the documentation part
> >> of patch 5 (vga) adds onto patch 4 (retrace=) changes.
> >
> > [..snip..]
> >
> > Applied, thanks.
> 
> malc, please revert these patches.
> 
> They were not adequately reviewed and they also do not qualify for the
> stage of the release we're in.

Number 2 was, and should stay, as the emulation wasn't correct before it,
don't really care about the rest.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[Anthony Liguori]

malc <av1474@comtv.ru> writes:

> On Mon, 27 Aug 2012, Anthony Liguori wrote:
>
>> malc <av1474@comtv.ru> writes:
>> 
>> > On Thu, 23 Aug 2012, Matthew Ogilvie wrote:
>> >
>> >> After applying this version 2 of this patch series, I can
>> >> successfully run "Micoport UNIX System V/386, v 2.1" (ca 1987)
>> >> under qemu.  (although not if I try to enable KVM)
>> >> 
>> >> Version 1 of this series was posted about 4 weeks ago.  See
>> >> http://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=15654
>> >> 
>> >> The patches are all independent, except that the documentation part
>> >> of patch 5 (vga) adds onto patch 4 (retrace=) changes.
>> >
>> > [..snip..]
>> >
>> > Applied, thanks.
>> 
>> malc, please revert these patches.
>> 
>> They were not adequately reviewed and they also do not qualify for the
>> stage of the release we're in.
>
> Number 2 was, and should stay, as the emulation wasn't correct before it,
> don't really care about the rest.

Okay, please revert the rest then.

Regards,

Anthony Liguori

>
> -- 
> mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH v2 6/6] i8259: add -no-spurious-interrupt-hack option

[Paolo Bonzini]

Il 27/08/2012 15:55, Anthony Liguori ha scritto:
>> > This patch provides a way to optionally suppress spurious interrupts,
>> > as a workaround for systems described below:
>> >
>> > Some old operating systems do not handle spurious interrupts well,
>> > and qemu tends to generate them significantly more often than
>> > real hardware.
> This is the wrong approach.  You add a LostTickPolicy property to the
> i8259 device.

Isn't the i8254 the one that would need a LostTickPolicy?

But this seems like a bug that is either in the i8259 emulation, or in
the firmware.  Your own suggestion of setting IRQ2 to level-triggered in
SeaBIOS is definitely a good one.

Paolo

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[malc]

On Mon, 27 Aug 2012, Anthony Liguori wrote:

> malc <av1474@comtv.ru> writes:
> 

[..snip..]

> >
> > Number 2 was, and should stay, as the emulation wasn't correct before it,
> > don't really care about the rest.
> 
> Okay, please revert the rest then.
> 

Done.

[..snip..]

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH v2 0/6] Running Microport UNIX (ca 1987)

[Anthony Liguori]

malc <av1474@comtv.ru> writes:

> On Mon, 27 Aug 2012, Anthony Liguori wrote:
>
>> malc <av1474@comtv.ru> writes:
>> 
>
> [..snip..]
>
>> >
>> > Number 2 was, and should stay, as the emulation wasn't correct before it,
>> > don't really care about the rest.
>> 
>> Okay, please revert the rest then.
>> 
>
> Done.

Thank you!

Regards,

Anthony Liguori

>
> [..snip..]
>
> -- 
> mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH v2 6/6] i8259: add -no-spurious-interrupt-hack option

[Anthony Liguori]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 27/08/2012 15:55, Anthony Liguori ha scritto:
>>> > This patch provides a way to optionally suppress spurious interrupts,
>>> > as a workaround for systems described below:
>>> >
>>> > Some old operating systems do not handle spurious interrupts well,
>>> > and qemu tends to generate them significantly more often than
>>> > real hardware.
>> This is the wrong approach.  You add a LostTickPolicy property to the
>> i8259 device.
>
> Isn't the i8254 the one that would need a LostTickPolicy?

You're right, I too quickly read this patch and misunderstood what it's
doing.

Regards,

Anthony Liguori

>
> But this seems like a bug that is either in the i8259 emulation, or in
> the firmware.  Your own suggestion of setting IRQ2 to level-triggered in
> SeaBIOS is definitely a good one.

>
> Paolo