Re: [Qemu-ppc] [Qemu-devel] [PULL 075/118] macio: handle non-block ATAPI DMA transfers

[Kevin Wolf]

Am 24.06.2014 um 00:41 hat Mark Cave-Ayland geschrieben:
> On 23/06/14 20:26, BALATON Zoltan wrote:
> 
> (add Kevin to CC)
> 
> >>>I'm afraid as you're the only person that can boot MorphOS this far
> >>>then we need you to diagnose and suggest a suitable alternative by
> >>>comparing the before and after output. Since MacOS is already a
> >>>supported client then if no solution can be found then it is likely
> >>>that this patch will be reverted :(
> >>
> >>So should I revert the patch for now? We're already in soft freeze.
> 
> Well let's see if Zoltan can make any headway with debugging over
> the next few days; if there's no progress by the weekend then sadly
> my recommendation would be to revert in time for -rc0 as this
> definitely causes intermittent boot failures in Darwin for me.
> 
> >It would be nicer if it could be fixed instead of reverting. You could
> >help detangling the macio.c code for a start.
> 
> Just to clarify here: the macio/DBDMA code is quite complicated, but
> this is because this device has to work around to the fact that
> currently the DMA I/O routines currently need sector alignment
> whereas macio requires byte-level alignment. There has been quite a
> lot of work at the lower levels to support byte-level alignment (see
> Kevin's series at
> http://lists.gnu.org/archive/html/qemu-devel/2014-01/msg02163.html)
> but until we can specify transfers to byte granularity in the
> dma_bdrv_*() APIs then there isn't much we can do to clean up the
> macio.c code.
> 
> Kevin, are there any plans to bubble the byte-granularity block
> layer changes up to the dma_bdrv_*() APIs in the near future?

Not to my knowledge.

Block devices allowing byte-granularity accesses (or can you even call
them block devices any more then?) seem to be something rather uncommon.
So far this macio thing seems to be the only one that needs such
functionality. Which probably means that if you guys don't do the
conversion, nobody will.

> Please bear in mind that QEMU supports a large number of OSs, and
> there is already an enthusiastic group of people using Alex's OS X
> work (see emaculation for many examples) so introducing an
> intermittent fault on a supported OS is not an option here.
> 
> I should also re-emphasise that Alex/Andreas work on many different
> parts of QEMU, and my work is currently unsponsored so while we are
> all keen to improve QEMU to the point where it can emulate new OSs
> such as MorphOS, it's not the case that we can simply drop what we
> are doing at the time to focus on an issue that affects a single OS
> which is new and currently unsupported.
> 
> Now I think it's fair to say that I've spent quite a few hours
> helping you and coming up with the original version of this patch,
> and I'm glad that you are now seeing success with this. But what is
> important to us right now heading towards a release is that patches
> don't cause any regressions.

Yes, I think you're making an important point here.

Kevin