From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PULL 0/5] ppc patch queue 2012-05-16 Date: Wed, 16 May 2012 15:28:04 +0200 Message-ID: <4FB3AB64.3060609@suse.de> References: <1337173519-6780-1-git-send-email-agraf@suse.de> <4FB3AA52.7090409@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org list" , kvm-ppc@vger.kernel.org, mtosatti@redhat.com To: Avi Kivity Return-path: Received: from cantor2.suse.de ([195.135.220.15]:40973 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967490Ab2EPN2J (ORCPT ); Wed, 16 May 2012 09:28:09 -0400 In-Reply-To: <4FB3AA52.7090409@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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? Alex