From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics? Date: Wed, 25 Jan 2012 13:38:54 +0200 Message-ID: <4F1FE9CE.5050401@redhat.com> References: <4F1810AF.8010002@siemens.com> <20120119172802.GD11381@amt.cnet> <4F185535.1060908@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm , qemu-devel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45934 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752267Ab2AYLjE (ORCPT ); Wed, 25 Jan 2012 06:39:04 -0500 In-Reply-To: <4F185535.1060908@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/19/2012 07:39 PM, Jan Kiszka wrote: > On 2012-01-19 18:28, Marcelo Tosatti wrote: > > On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote: > >> Hi again, > >> > >> do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in > >> upstream? > >> > >> If yes: The underlying IOCTL is x86-only. Are other archs interested in > >> this long-term as well, ie. should the control become arch-independent? > >> > >> Jan > > > > Last time i asked about removal, Avi wished for it to remain. > > > > Then I guess he should comment on this after returning to work. :) -kvm-shadow-memory is becoming less meaningful for ordinary workloads since everything uses TDP these days. It's still meaningful for testing (forcing aggressive cache replacement), or perhaps nested virtualization. -- error compiling committee.c: too many arguments to function