From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDQNh-00020p-Um for qemu-devel@nongnu.org; Mon, 10 Oct 2011 20:39:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDQNf-00053X-9b for qemu-devel@nongnu.org; Mon, 10 Oct 2011 20:39:41 -0400 Received: from ozlabs.org ([203.10.76.45]:60743) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDQNe-00053P-VR for qemu-devel@nongnu.org; Mon, 10 Oct 2011 20:39:39 -0400 Date: Tue, 11 Oct 2011 11:39:33 +1100 From: David Gibson Message-ID: <20111011003933.GF12250@truffala.fritz.box> References: <1317368353-30201-1-git-send-email-david@gibson.dropbear.id.au> <95EA8947-05BF-4356-84B0-3D47E0DEAD82@suse.de> <20111010233914.GB12250@truffala.fritz.box> <75746972-F821-4A0F-A9D1-A2A1ABEB848B@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75746972-F821-4A0F-A9D1-A2A1ABEB848B@suse.de> Subject: Re: [Qemu-devel] [0/4] pseries: Support and improvements for KVM Book3S-HV support (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: QEMU Developers , Avi Kivity On Tue, Oct 11, 2011 at 02:20:48AM +0200, Alexander Graf wrote: > > On 11.10.2011, at 01:39, David Gibson wrote: > > > On Fri, Oct 07, 2011 at 08:57:49AM +0200, Alexander Graf wrote: > >> > >> On 30.09.2011, at 09:39, David Gibson wrote: > >> > >>> Alex Graf has added support for KVM acceleration of the pseries > >>> machine, using his Book3S-PR KVM variant, which runs the guest in > >>> userspace, emulating supervisor operations. Recent kernels now have > >>> the Book3S-HV KVM variant which uses the hardware hypervisor features > >>> of recent POWER CPUs. Alex's changes to qemu are enough to get qemu > >>> working roughly with Book3S-HV, but taking full advantage of this mode > >>> needs more work. This patch series makes a start on better exploiting > >>> Book3S-HV. > >>> > >>> Even with these patches, qemu won't quite be able to run on a current > >>> Book3S-HV KVM kernel. That's because current Book3S-HV requires guest > >>> memory to be backed by hugepages, but qemu refuses to use hugepages > >>> for guest memory unless KVM advertises CAP_SYNC_MMU, which Book3S-HV > >>> does not currently do. We're working on improvements to the KVM code > >>> which will implement CAP_SYNC_MMU and allow smallpage backing of > >>> guests, but they're not there yet. So, in order to test Book3S-HV for > >>> now you need to either: > >>> > >>> * Hack the host kernel to lie and advertise CAP_SYNC_MMU even though > >>> it doesn't really implement it. > >>> > >>> or > >>> > >>> * Hack qemu so it does not check for CAP_SYNC_MMU when the -mem-path > >>> option is used. > >>> > >>> Bot approaches are ugly and unsafe, but it seems we can generally get > >>> away with it in practice. Obviously this is only an interim hack > >>> until the proper CAP_SYNC_MMU support is ready. > >> > >> I would prefer the latter. We could even #ifdef it for TARGET_PPC. > > > > Well, I don't see either approach as being remotely mergable. So it's > > really up to each individual person playing with it which hack is > > easier for them to apply temporarily while waiting for the proper > > solution to come along. > > Not sure. Why not make it a warning instead of failure on PPC and > give people at least the chance to play with it? Because it can trigger a serious kernel bug... As far as I can tell, the fact that we haven't hit the crash/race on PPC so far is pure luck, not that we're actually less vulnerable to it. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson