Re: [Qemu-devel] [PATCH stable-1.1 00/26] Initial tree and candidates for stable-1.1

[Michael Roth]

On Mon, Jun 25, 2012 at 05:14:08PM +0200, Kevin Wolf wrote:
> Am 25.06.2012 16:14, schrieb Michael Roth:
> > On Mon, Jun 25, 2012 at 02:58:40PM +0200, Kevin Wolf wrote:
> >> Am 23.06.2012 02:33, schrieb Michael Roth:
> >>> Hi everyone,
> >>>
> >>> I've set up a tree for stable-1.1 at:
> >>>
> >>> git://github.com/mdroth/qemu.git stable-1.1
> >>>
> >>> That is simply the initial commit for v1.1.0
> >>>
> >>> I've set up a staging tree for the first batch of commits at:
> >>>
> >>> git://github.com/mdroth/qemu.git stable-1.1-staging
> >>>
> >>> This should capture everything explicitly tagged for stable/1.1. I've also
> >>> pulled in relevant build fixes and a handful of applicable bug fixes.
> >>>
> >>> Please let me know if I've missed any patches, or if any of these 
> >>> shouldn't be
> >>> applied.
> >>>
> >>> Testing so far has been all-target builds on x86, make check, qemu-test, 
> >>> and
> >>> installation + old(current stable-1.1)->new and new->old migration for
> >>> fc15/fc16/winxp. I plan on doing a more extensive final round of testing 
> >>> later
> >>> next week before committing, as that will more or less be QEMU v1.1.1
> >>>
> >>> For the next release I plan on doing weekly or bi-weekly testing of staged
> >>> patches and emails of this sort before committing to stable-1.1, 
> >>> depending on
> >>> the number of patches and code churn, and will continue working off my
> >>> stable-1.1-staging tree on github for those.
> >>
> >> Please consider as well:
> >>
> >> 4bb9c939a57103898f5a51aa6a7336eb3320d923 ahci: SATA FIS is 20 bytes...
> > 
> > I originally had this in the queue but it looks like the only effect is
> > to avoid allocating/initializing an extra 16 bytes on the stack. I
> > didn't see any other potential side-effects so decided to drop it. Let
> > me know if I'm missing something though.
> 
> When I reviewed it, I didn't fully understand if it really matters, but
> it does corrupt some other state. It's possible that the overwritten
> data isn't used anyway before it's recreated, but as I wasn't sure, I
> thought backporting an easy fix wouldn't hurt.

You're right, I'd missed the potential for clobbering 8 bytes of RES_FIS_SDBFIS
(which is stored in the same buffer at offset RES_FIS_RFIS + 24). I must've
misread the change in initialization as only affecting the temporary buffer
whose size had been reduced as part of the patch.

Applied to staging, thanks.

> 
> Kevin
>