From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RnrO9-00056l-2O for qemu-devel@nongnu.org; Thu, 19 Jan 2012 07:46:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RnrO7-00050l-LL for qemu-devel@nongnu.org; Thu, 19 Jan 2012 07:46:44 -0500 Received: from david.siemens.de ([192.35.17.14]:27949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RnrO7-00050b-3X for qemu-devel@nongnu.org; Thu, 19 Jan 2012 07:46:43 -0500 Message-ID: <4F1810AF.8010002@siemens.com> Date: Thu, 19 Jan 2012 13:46:39 +0100 From: Jan Kiszka MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] qemu-kvm upstreaming: Do we want -kvm-shadow-memory semantics? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: kvm Cc: qemu-devel 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 -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux