[Top][All Lists]

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH 0/4] macio: change DMA methods over t

From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 0/4] macio: change DMA methods over to offset/len implementation
Date: Tue, 02 Jun 2015 00:18:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0

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 <address@hidden>
>> 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)?

> But that's an unsatisfying response, so how about:
> Tested-by: John Snow <address@hidden>
> 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.



reply via email to

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