* [Qemu-devel] Fwd: Re: ahci doesn't work with qemu emulation
[not found] <4E6CC7C1.9050102@FreeBSD.org>
@ 2011-09-12 7:57 ` Andriy Gapon
0 siblings, 0 replies; only message in thread
From: Andriy Gapon @ 2011-09-12 7:57 UTC (permalink / raw)
To: qemu-devel
Guys,
could you please take a look at the following patch for qemu ahci emulation?
The patch is from the FreeBSD AHCI developer/maintainer.
If it looks OK, then we will submit it according to the rules.
Thank you!
-------- Original Message --------
Sender: Alexander Motin <mavbsd@gmail.com>
Message-ID: <4E6CC7C1.9050102@FreeBSD.org>
Date: Sun, 11 Sep 2011 17:37:53 +0300
From: Alexander Motin <mav@FreeBSD.org>
To: Andriy Gapon <avg@FreeBSD.org>
CC: FreeBSD-Current <freebsd-current@FreeBSD.org>
Subject: Re: ahci doesn't work with qemu emulation
References: <4E632972.7080409@FreeBSD.org>
In-Reply-To: <4E632972.7080409@FreeBSD.org>
Hi.
On 04.09.2011 10:32, Andriy Gapon wrote:
> ahcich0: Timeout on slot 0 port 0
> ahcich0: is 00000005 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr 00000000
> cmd 1000c017
> ahcich0: AHCI reset...
> ahcich0: SATA connect time=0us status=00000113
> ahcich0: AHCI reset: device found
> ahcich0: AHCI reset: device ready after 0ms
> (aprobe0:ahcich0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
> (aprobe0:ahcich0:0:0:0): CAM status: Command timeout
> (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000
>
> I guess that this is a problem with the emulation - some unsupported command or
> reliance on some specific behavior of a driver (e.g. a Linux driver), but still
> would be nice to have it working for testing / experimentation purposes.
>
> Example of how a disk behind an AHCI controller can be specified to qemu-devel:
> qemu-system-x86_64 ... -drive id=disk,file=disk.img,if=none -device ahci,id=ahci
> -device ide-drive,drive=disk,bus=ahci.0
I've reproduced the problem. I believe the problem is in QEMU's AHCI
emulation. As I see, it clears port's Interrupt Enable register each
time when reset of any level happens. Is is reasonable for the global
controller reset. It is probably not good, but acceptable for our driver
for the port hard reset. But it is IMO wrong for the device soft reset.
None of real hardware I know behaves that way.
This patch to QEMU fixes the problem for me:
http://people.freebsd.org/~mav/qemu.ahci.patch
This patch workarounds the problem from the FreeBSD side:
http://people.freebsd.org/~mav/qemu.ahci.freebsd.patch
, but I would prefer to see problem solved from the QEMU side.
--
Alexander Motin
^ permalink raw reply [flat|nested] only message in thread