[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Fwd: Re: ahci doesn't work with qemu emulation

From: Andriy Gapon
Subject: [Qemu-devel] Fwd: Re: ahci doesn't work with qemu emulation
Date: Mon, 12 Sep 2011 10:57:37 +0300
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110907 Thunderbird/6.0.2


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 <address@hidden>
Message-ID: <address@hidden>
Date: Sun, 11 Sep 2011 17:37:53 +0300
From: Alexander Motin <address@hidden>
To: Andriy Gapon <address@hidden>
CC: FreeBSD-Current <address@hidden>
Subject: Re: ahci doesn't work with qemu emulation
References: <address@hidden>
In-Reply-To: <address@hidden>


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:

This patch workarounds the problem from the FreeBSD side:
, but I would prefer to see problem solved from the QEMU side.

Alexander Motin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]