On Tue, Apr 26, 2011 at 9:53 PM, Paul Brook paul@codesourcery.com wrote:
Hm. Fast/wide and synchronous should be no problem (unless there are certain timings expected).
Fast should be a non-issue. Wide may be a problem if we get odd sized transfers wrong. IIUC wide transfers are initiated by the target (disk) and qemu never does this, so should not be a problem either.
After a bit experimenting it turend out that I was wrong about synchronous. This seems to be the problem. The comment in the OpenSolaris esp driver http://src.opensolaris.org/source/xref/xen-gate/onnv-3.4/usr/src/uts/sun/io/... also explains one reason why:
/* * Set up to send synch. negotiating message. This is getting * a bit tricky as we dma out the identify message and * send the other messages via the fifo buffer. */
Looks like the qemu esp doesn't support mixing dma/fifo messages.
Tagged command is a bigger issue, since afaik none of QEMU's HBAs support it.
Other QEMU HBAs (LSI53C895A) do support tagged command queueing, however the ESP does not.
By my reading qemu esp emulation is missing proper handling of MESSAGE phases. It assumes only a single IDENTIFY byte is sent, probably interpreting subsequent SIMPLE queue tags as the start of the command block. Implementing full command queueing is fairly tricky. However a stub implementation that accepts the tag but avoids disconnecting (force sequential execution of commands) should be somewhat simpler.
This seems to be necessary too because the OpenSolaris driver seems to use at least two tags:
esp->e_cur_msgout[i++] = sp->cmd_tag[0]; esp->e_cur_msgout[i++] = sp->cmd_tag[1];
Artyom