[Top][All Lists]

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

Re: [Qemu-devel] [RFC 0/2] macio: split out unaligned DMA access into se

From: Mark Cave-Ayland
Subject: Re: [Qemu-devel] [RFC 0/2] macio: split out unaligned DMA access into separate functions
Date: Sun, 31 May 2015 20:54:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0

On 22/05/15 19:20, John Snow wrote:

> As a post-script, can Darwin/PPC use a different mechanism for ATA at
> all, or is macio the sole ATA interface we support here?
> I want to see if I can pinpoint when a "good" bath and when a bad path
> diverges with respect to the disk contents ...
> Or if you have other ideas on how to identify the transfer that causes
> the issue, I'm all ears.

After a fairly involved weekend, I've managed to track this one down. It
was an actually an issue with the chaining of write requests with
unaligned accesses, whereby alternating patterns of head, head/tail and
tail would end up overwriting the common remainder section and so copy
the wrong sector back to the disk.

The bad news is that this has definitely been broken since QEMU 2.1+ so
anyone using a Darwin/OS X PPC image is very likely to have an
installation that won't boot, or corruption in an image if it was
originally installed on an older QEMU version :(

Note that as I figured out what was happening my code was morphing into
a very similar pattern to that of
bdrv_co_do_preadv()/bdrv_co_do_pwritev() (except mine still calculated
with sectors) and so I bit the bullet and moved them over to match the
existing style. This has the advantage that the algorithm is similar to
an existing one, plus if unaligned block APIs become available in the
future then switching them over should be fairly trivial.

I'll post an updated patchset shortly. John, if you could confirm it
fixes the issue on your side that would be great.



reply via email to

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