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

[John Snow <jsnow@redhat.com>]

On 05/31/2015 03:54 PM, Mark Cave-Ayland wrote:
> 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.
> 

Great!

> 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 :(
> 

Bummer. On the other hand, the number of complaints I have seen is...
zero. So here's hoping it isn't the apocalypse.

> 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.
> 
> 
> ATB,
> 
> Mark.
> 

Sure thing. Had unexpected PTO last week, so give me a pinch to clear
the todo list and I'll get to testing the patchset.

--js