From patchwork Fri Nov 20 19:08:03 2009
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: SeaBIOS cdrom regression with Vista
X-Patchwork-Submitter: Kevin O'Connor <kevin@koconnor.net>
X-Patchwork-Id: 38936
Message-Id: <20091120190803.GA22484@morn.localdomain>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <kvm@vger.kernel.org>
Date: Fri, 20 Nov 2009 14:08:03 -0500
From: Kevin O'Connor <kevin@koconnor.net>
List-Id: qemu-devel.nongnu.org

On Fri, Nov 20, 2009 at 01:03:51PM -0500, Kevin O'Connor wrote:
> I've looked into this, and it looks like the cdrom is left in an odd
> state.  At this point, I think SeaBIOS is tickling a bug outside of
> seabios (eg, in Vista or qemu).  I would appreciate it someone with
> cdrom knowledge of qemu could help.
[...]
> SeaBIOS has a different ata drive detection mechanism than bochs - it
> needs it in order to work on real hardware.  So, this explains why
> bochs bios doesn't show this issue.  (Seabios tries to send an
> "identify packet device" and then an "identify device" command to
> detect a drive; bochs bios looks for a signature in the ata registers
> after an ata reset.)

It looks like I spoke too soon.  It appears the SeaBIOS init can leave
the ATA controller in an interrupts disabled state.  This appears to
confuse Vista.  So, this is a SeaBIOS bug - I'll implement a fix.

The patch below enables Vista to see the cdrom (though, it's not a
real fix).

-Kevin

--- a/src/ata.c
+++ b/src/ata.c
@@ -237,6 +237,7 @@ send_cmd(struct drive_s *drive_g, struct ata_pio_command *cmd)
         return -4;
     }
     if (!(status & ATA_CB_STAT_DRQ)) {
+    outb(ATA_CB_DC_HD15, iobase2+ATA_CB_DC);
         dprintf(6, "send_cmd : DRQ not set (status %02x)\n", status);
         return -5;
     }