On 07/05/14 10:56, BALATON Zoltan wrote:
The majority of the complexity of this code is to do with calculating
non block-aligned DMA requests with regard to IDE transfers and making
sure that unaligned requests (i.e. those that are not a multiple of
the 512 byte block size) are correctly copied to RAM between transfers.
Thanks for the explanation but I still don't see what should be the fix
for the problem I have. Where is this translation coming from:
sector_num = (s->lba << 2) + (s->io_buffer_index >> 9)
and why is it not correct for lba=-1? Where is lba set to -1 and where
should the lba=-1 case handled?
I believe s->lba is the LBA sector reference for the first sector of
the IDE transfer (multiplied by 4 to convert from internal
representation to sectors), while s->io_buffer_index is the current
seek() position in bytes within the IDE transfer buffer.
So for example, the OS may request an IDE transfer of 0x200 bytes but
configure DBDMA to copy the results to RAM as a 0x198 size chunk and a
0x2 size chunk. After the first 0x198 chunk is transferred,
s->io_buffer_index would be set to 0x198 to indicate the next buffer
position required for the remaining unaligned access.
I'm not sure if your problem related to s->lba == -1 should be solved
just for macio or higher up in the block layer, but the block people
will be on qemu-devel and not qemu-ppc so you should definitely CC the
main list to get their feedback on this.
Also if you want to test changes to this code, I highly recommend
sourcing a copy of the old darwinppc-602.iso file as both that and PPC
OS X generate huge sets of unaligned accesses in this way.
I've downloaded this and the latest 802 version of these images and
tried it with my OpenBIOS modifications. They seem to get to the same
point as with the stock QEMU version. Neither of them give me a login
prompt though with or without modifications to OpenBIOS. Are these
supposed to work or working as much as before is enough of a test?
Those ISOs only boot for me with the default -M g3beige, but darwin is
a huge culprit for these unaligned accesses. My point was that if you
are making changes in this area, if you can still boot the darwin
images then that would be a good test that any changes you make are
working correctly :)
P.S. I'm not sure but I think recently Kevin posted patches to
qemu-devel which may remove the requirement for block-aligned
accesses, so if these patches have been applied then it might be
possible to simplify this code quite significantly.
I could not identify such patches in the commit log but I'm not sure
what to look for.
Here is the series I was thinking of:
http://lists.gnu.org/archive/html/qemu-devel/2014-01/msg02163.html and
to quote from the initial paragraph:
"This patch series adds code to the block layer that allows performing
I/O requests in smaller granularities than required by the host backend
(most importantly, O_DIRECT restrictions). It achieves this for reads
by rounding the request to host-side block boundary, and for writes by
performing a read-modify-write cycle (and serialising requests
touching the same block so that the RMW doesn't write back stale data)."
Alex, would you say that with these patches then the majority of the
hacks in macio required for unaligned accesses could go away?