On 05/16/2012 04:28 PM, Alexander Graf wrote: > On 05/16/2012 03:23 PM, Avi Kivity wrote: >> On 05/16/2012 04:05 PM, Alexander Graf wrote: >>> Hi Avi, >>> >>> There are a few bugs in 3.4 that really should be fixed before >>> people can >>> be all happy and fuzzy about KVM on PowerPC. These fixes are: >>> >>> * fix POWER7 bare metal with PR=y >>> * fix deadlock on HV=y book3s_64 mode in low memory cases >>> * fix invalid MMU scope of PR=y mode on book3s_64, possibly >>> leading to memory corruption >>> >>> This request and the patches are based on top of Linus's master >>> branch. Please >>> either send these to Linus to get them into 3.4.0 or to linux-stable >>> if it's too >>> late already. >>> >>> Alex >>> >>> The following changes since commit >>> 568b44559d7ca269d367e694c74eb4436e7e3ccf: >>> Srivatsa S. Bhat (1): >>> mn10300/CPU hotplug: Add missing call to notify_cpu_starting() >>> >>> are available in the git repository at: >>> >>> git://github.com/agraf/linux-2.6.git for-upstream-3.4 >>> >>> Alexander Graf (3): >>> KVM: PPC: Book3S: PR: Handle EMUL_ASSIST >>> KVM: PPC: Fix PR KVM on POWER7 bare metal >>> >> This one is already in 'next', which means it's queued for 3.5. While >> it won't bring about the end of the universe, please try to avoid this >> in the future by selecting the right branch to push into in advance >> (that's one of the consequences of the new workflow). > > Hm. I figured that there's a pretty high chance that the patches won't > make it for 3.4.0, so they'd have to go into 3.4-stable, which then > again means it's a lot easier to see which ones are still outstanding > there. I still maintain a -next queue in parallel where patches > destined for 3.5 go into. > > Which workflow would you prefer if not the one above? > For -rc/-stable patches, avoid queueing. If you have a patch, post it to the maintainers ASAP. It then becomes our problem (and a smaller problem too, since the less delays there are, the bigger the chances of making the intended release). A few days are fine of course. For mainstream patches, queuing is fine, but don't overdo it please. I enjoy pulling from you and am quite willing to pull several times per cycle. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
