From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzS5q-0005BW-Hx for qemu-devel@nongnu.org; Mon, 01 Jun 2015 11:57:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzS5l-0000I7-JR for qemu-devel@nongnu.org; Mon, 01 Jun 2015 11:57:38 -0400 Message-ID: <556C80E9.6030908@redhat.com> Date: Mon, 01 Jun 2015 11:57:29 -0400 From: John Snow MIME-Version: 1.0 References: <1425939893-14404-1-git-send-email-mark.cave-ayland@ilande.co.uk> <555F6D89.4090309@redhat.com> <555F727A.2030404@ilande.co.uk> <555F7367.5080103@redhat.com> <556B66F2.1070607@ilande.co.uk> In-Reply-To: <556B66F2.1070607@ilande.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/2] macio: split out unaligned DMA access into separate functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, kwolf@redhat.com, stefanha@redhat.com, agraf@suse.de 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