qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jason Baron <jbaron@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: Kevin Wolf <kwolf@redhat.com>,
	aliguori@us.ibm.com, mst@redhat.com, jan.kiszka@siemens.com,
	qemu-devel@nongnu.org, lcapitulino@redhat.com,
	yamahata@valinux.co.jp, alex.williamson@redhat.com,
	pbonzini@redhat.com, afaerber@suse.de, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH] ahci: properly reset PxCMD on HBA reset
Date: Fri, 31 Aug 2012 15:15:08 -0400	[thread overview]
Message-ID: <20120831191507.GG12212@redhat.com> (raw)
In-Reply-To: <128F51EA-270A-41FA-A284-530EB6599C41@suse.de>

On Fri, Aug 31, 2012 at 12:04:59PM -0700, Alexander Graf wrote:
> On 31.08.2012, at 07:23, Jason Baron wrote:
> 
> > On Fri, Aug 31, 2012 at 12:12:22PM +0200, Kevin Wolf wrote:
> >> Am 23.08.2012 23:09, schrieb Jason Baron:
> >>> While testing q35, I found that windows 7 (specifically, windows 7 ultimate
> >>> with sp1 x64), wouldn't install because it can't find the cdrom or disk drive.
> >>> The failure message is: 'A required cd/dvd device driver is missing. If you
> >>> have a driver floppy disk, CD, DVD, or USB flash drive, please insert it now.'
> >>> This can also be reproduced on piix by adding an ahci controller, and
> >>> observing that windows 7 does not see any devices behind it.
> >>> 
> >>> The problem is that when windows issues a HBA reset, qemu does not reset the
> >>> individual ports' PxCMD register. Windows 7 then reads back the PxCMD register
> >>> and presumably assumes that the ahci controller has already been initialized.
> >>> Windows then never sets up the PxIE register to enable interrupts, and thus it
> >>> never gets irqs back when it sends ata device inquiry commands.
> >>> 
> >>> I believe this change brings qemu into ahci 1.3 specification compliance.
> >>> 
> >>> Section 10.4.3 HBA Reset:
> >>> 
> >>> "
> >>> When GHC.HR is set to '1', GHC.AE, GHC.IE, the IS register, and all port
> >>> register fields (except PxFB/PxFBU/PxCLB/PxCLBU) that are not HwInit in the
> >>> HBA's register memory space are reset.
> >>> "
> >>> 
> >>> I've also re-tested Fedora 16 and 17 to verify that they continue to work with
> >>> this change.
> >>> 
> >>> Signed-off-by: Jason Baron <jbaron@redhat.com>
> >>> ---
> >>> hw/ide/ahci.c |    1 +
> >>> 1 files changed, 1 insertions(+), 0 deletions(-)
> >>> 
> >>> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> >>> index 9fe89a5..06c236f 100644
> >>> --- a/hw/ide/ahci.c
> >>> +++ b/hw/ide/ahci.c
> >>> @@ -1199,6 +1199,7 @@ void ahci_reset(AHCIState *s)
> >>>         pr->irq_stat = 0;
> >>>         pr->irq_mask = 0;
> >>>         pr->scr_ctl = 0;
> >>> +        pr->cmd = 0;
> >>>         ahci_reset_port(s, i);
> >>>     }
> >>> }
> >>> 
> >> 
> >> In ahci_init() we have:
> >> 
> >>  ad->port_regs.cmd = PORT_CMD_SPIN_UP | PORT_CMD_POWER_ON;
> >> 
> >> Why is resetting to 0 in ahci_reset() correct? I think we can still get
> >> this part committed for 1.2 after you either explain why 0 is right or
> >> send a fixed version.
> >> 
> > 
> > Good catch. I just tried out the following instead in ahci_reset():
> > 
> > pr->cmd = PORT_CMD_SPIN_UP | PORT_CMD_POWER_ON;
> > 
> > And it continues to make Windows7 find the ahci disks. I'd like to do a
> > little more testing, but I will send an updated path.
> 
> Since we reset on init, we can just shove it there completely, right?
> 
> 

Actually, we don't call reset on init. I'm thinking for 1.2, we can just
add the fix to the reset path, and as Kevin suggested in 1.3, we will
look to add a call to ahci_reset() in the init path.

Thanks,

-Jason

  reply	other threads:[~2012-08-31 19:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-23 21:09 [Qemu-devel] [PATCH] ahci: properly reset PxCMD on HBA reset Jason Baron
2012-08-24  4:39 ` Alexander Graf
2012-08-30 19:59   ` Jason Baron
2012-08-30 20:38     ` Alexander Graf
2012-08-24 14:18 ` Luiz Capitulino
2012-08-24 14:34   ` Alexander Graf
2012-08-24 15:32     ` Luiz Capitulino
2012-08-31 10:12 ` Kevin Wolf
2012-08-31 14:23   ` Jason Baron
2012-08-31 19:04     ` Alexander Graf
2012-08-31 19:15       ` Jason Baron [this message]
2012-08-31 20:29         ` Alexander Graf
2012-08-31 20:46           ` Jason Baron
2012-08-31 20:54           ` Jason Baron
2012-09-01  6:25             ` Alexander Graf
2012-09-04 20:12               ` Jason Baron

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20120831191507.GG12212@redhat.com \
    --to=jbaron@redhat.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kwolf@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yamahata@valinux.co.jp \
    /path/to/YOUR_REPLY

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

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