From patchwork Sun Apr 28 08:32:18 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: jordan.l.justen@intel.com X-Patchwork-Id: 240255 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id D9D8A2C00BB for ; Mon, 29 Apr 2013 01:42:35 +1000 (EST) Received: from localhost ([::1]:49238 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWTkI-0007zn-1r for incoming@patchwork.ozlabs.org; Sun, 28 Apr 2013 11:42:34 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWN2E-00048Y-6V for qemu-devel@nongnu.org; Sun, 28 Apr 2013 04:32:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWN28-0006mH-E7 for qemu-devel@nongnu.org; Sun, 28 Apr 2013 04:32:38 -0400 Received: from mga14.intel.com ([143.182.124.37]:36510) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWN28-0006lq-8B for qemu-devel@nongnu.org; Sun, 28 Apr 2013 04:32:32 -0400 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 28 Apr 2013 01:32:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,566,1363158000"; d="scan'208";a="233796222" Received: from unknown (HELO jljusten-ivy.amr.corp.intel.com) ([10.255.12.60]) by AZSMGA002.ch.intel.com with ESMTP; 28 Apr 2013 01:32:30 -0700 From: Jordan Justen To: qemu-devel@nongnu.org Date: Sun, 28 Apr 2013 01:32:18 -0700 Message-Id: <1367137941-4310-4-git-send-email-jordan.l.justen@intel.com> X-Mailer: git-send-email 1.7.10.4 In-Reply-To: <1367137941-4310-1-git-send-email-jordan.l.justen@intel.com> References: <1367137941-4310-1-git-send-email-jordan.l.justen@intel.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 143.182.124.37 X-Mailman-Approved-At: Sun, 28 Apr 2013 11:42:00 -0400 Cc: Jordan Justen , Xiao Guangrong Subject: [Qemu-devel] [PATCH 3/6] kvm: workaround a possible KVM bug when using KVM_MEM_READONLY X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On a Linux 3.8.0 based kernel, I occasionally saw a situation where the memory region would continue to trap on memory read even though KVM_MEM_READONLY was set. I found that if I set the slot to a size of 0, and before setting the slot, it would then behave as expected. Signed-off-by: Jordan Justen Cc: Xiao Guangrong Reviewed-by: Xiao Guangrong --- kvm-all.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/kvm-all.c b/kvm-all.c index 95e6bf2..e2ddbcb 100644 --- a/kvm-all.c +++ b/kvm-all.c @@ -205,6 +205,13 @@ static int kvm_set_user_memory_region(KVMState *s, KVMSlot *slot) if (s->migration_log) { mem.flags |= KVM_MEM_LOG_DIRTY_PAGES; } + if (mem.flags & KVM_MEM_READONLY && mem.memory_size != 0) { + /* Workaround an issue with setting a READONLY slot. Set the + * slot size to 0 before setting the slot to the desired value. */ + mem.memory_size = 0; + kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem); + mem.memory_size = slot->memory_size; + } return kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem); }