Re: [Qemu-devel] [PATCH 0/4] macio: change DMA methods over to offset/len implementation

[John Snow <jsnow@redhat.com>]

On 06/01/2015 07:18 PM, Mark Cave-Ayland wrote:
> On 02/06/15 00:09, John Snow wrote:
> 
>> On 05/31/2015 04:05 PM, Mark Cave-Ayland wrote:
>>> This patchset follows on from my recent work on fixing issues with the
>>> macio controller, and remodels the new pmac_dma_read() and pmac_dma_write()
>>> functions in a similar manner to the unaligned block functions.
>>>
>>> With this in place, long chains of overlapping unaligned requests as used
>>> by OS X/Darwin will now work correctly without introducting torn sector
>>> errors when writing to disk.
>>>
>>> Also included are some tidy-ups as a result of the above changes.
>>>
>>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>>>
>>> Mark Cave-Ayland (4):
>>>   macio: switch pmac_dma_read() over to new offset/len implementation
>>>   macio: switch pmac_dma_write() over to new offset/len implementation
>>>   macio: update comment/constants to reflect the new code
>>>   macio: remove remainder_len DBDMA_io property
>>>
>>>  hw/ide/macio.c             |  271 +++++++++++++++++---------------------------
>>>  include/hw/ppc/mac_dbdma.h |    4 +-
>>>  2 files changed, 105 insertions(+), 170 deletions(-)
>>>
>>
>> More 32/64bit printf string problems:
>>
>> macio.c:81:  sector_num is int64_t (PRId64)
>> macio.c:93:  sector_num
>>              head_bytes is size_t (%zu)
>> macio.c:107: sector_num
>>              tail_bytes is size_t (%zu)
>> macio.c:147: sector_num
>> macio.c:160: sector_num
>> macio.c:178: sector_num
> 
> Ah oops. Do you need me to correct? And do you have a quick way of
> testing a 32-bit build on a 64-bit OS? (-m32)?
> 

Unfortunately that's the best I've got. For my particular case I tend to
use this:

./configure --enable-debug '--extra-cflags=-m32
-I/usr/lib/glib-2.0/include' '--extra-ldflags=-m32 -L/usr/lib/iscsi'
--disable-glusterfs

and that helps guide my F21 through the unholy machinations necessary to
produce a 32-ish bit build. I've tried to fix this in the past, but I
keep running into edge cases for e.g. cross compilation and issues with
how different distros handle multi-lib/multi-arch, so it remains sort of
hacky and bad.

Wait to send v2 until after I look at the series a little more
carefully, in case there's something else.

>> But that's an unsatisfying response, so how about:
>>
>> Tested-by: John Snow <jsnow@redhat.com>
>>
>> Fixes the problem as far as I can tell. I'll comb it in a little more
>> detail later. Have you tested this patchset with OSX et al to make sure
>> it doesn't introduce any obvious regression on that side of things?
> 
> Most of the work was done on Darwin (which definitely does unaligned
> accesses) and I booted an OS X CDROM through to the point where the hard
> disk started installing, so I'm reasonably confident in the patch. And
> more so that it's based upon the existing block alignment code in io.c.
> 
> Basically the point of fixing up the -M g3beige/mac99 loadvm/savevm
> (which is almost there except for DBDMA) in the last release was to help
> debug this. At least I could get to a point where I could start QEMU
> with -loadvm, run a single cp command and then md5 the results to check
> for errors rather than having to wait for an entire OS install.
> 

If it's good enough for the mac-minded among us, it's good enough for me!

> 
> ATB,
> 
> Mark.
> 

Thanks again!
--js