From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkDaW-0000B7-IK for qemu-devel@nongnu.org; Mon, 20 Apr 2015 11:26:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkDaT-0002x7-1Z for qemu-devel@nongnu.org; Mon, 20 Apr 2015 11:26:20 -0400 Received: from mail-la0-f50.google.com ([209.85.215.50]:35431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkDaS-0002wu-Qd for qemu-devel@nongnu.org; Mon, 20 Apr 2015 11:26:16 -0400 Received: by labbd9 with SMTP id bd9so129691857lab.2 for ; Mon, 20 Apr 2015 08:26:15 -0700 (PDT) Date: Mon, 20 Apr 2015 17:26:32 +0200 From: Christoffer Dall Message-ID: <20150420152632.GK6186@cbox> References: <1426705700-2564-1-git-send-email-drjones@redhat.com> <1426705833-2679-1-git-send-email-drjones@redhat.com> <1426705833-2679-2-git-send-email-drjones@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1426705833-2679-2-git-send-email-drjones@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH 1/3] KVM: promote KVM_MEMSLOT_INCOHERENT to uapi List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones Cc: peter.maydell@linaro.org, ard.biesheuvel@linaro.org, marc.zyngier@arm.com, catalin.marinas@arm.com, qemu-devel@nongnu.org, agraf@suse.de, pbonzini@redhat.com, lersek@redhat.com, kvmarm@lists.cs.columbia.edu, m.smarduch@samsung.com On Wed, Mar 18, 2015 at 03:10:31PM -0400, Andrew Jones wrote: > Also rename to KVM_MEM_UNCACHED. > > Signed-off-by: Andrew Jones > --- > Documentation/virtual/kvm/api.txt | 16 ++++++++++------ > arch/arm/include/uapi/asm/kvm.h | 1 + > arch/arm/kvm/arm.c | 1 + > arch/arm/kvm/mmu.c | 4 ++-- > arch/arm64/include/uapi/asm/kvm.h | 1 + > include/linux/kvm_host.h | 1 - > include/uapi/linux/kvm.h | 2 ++ > virt/kvm/kvm_main.c | 7 ++++++- > 8 files changed, 23 insertions(+), 10 deletions(-) > > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index 0007fef4ed814..a5a51403a7937 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -902,6 +902,7 @@ struct kvm_userspace_memory_region { > /* for kvm_memory_region::flags */ > #define KVM_MEM_LOG_DIRTY_PAGES (1UL << 0) > #define KVM_MEM_READONLY (1UL << 1) > +#define KVM_MEM_UNCACHED (1UL << 2) > > This ioctl allows the user to create or modify a guest physical memory > slot. When changing an existing slot, it may be moved in the guest > @@ -917,12 +918,15 @@ It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr > be identical. This allows large pages in the guest to be backed by large > pages in the host. > > -The flags field supports two flags: KVM_MEM_LOG_DIRTY_PAGES and > -KVM_MEM_READONLY. The former can be set to instruct KVM to keep track of > -writes to memory within the slot. See KVM_GET_DIRTY_LOG ioctl to know how to > -use it. The latter can be set, if KVM_CAP_READONLY_MEM capability allows it, > -to make a new slot read-only. In this case, writes to this memory will be > -posted to userspace as KVM_EXIT_MMIO exits. > +The flags field supports three flags: KVM_MEM_LOG_DIRTY_PAGES, > +KVM_MEM_READONLY, and KVM_MEM_UNCACHED. The first can be set to instruct > +KVM to keep track of writes to memory within the slot. See KVM_GET_DIRTY_LOG > +ioctl to know how to use it. The second can be set, if KVM_CAP_READONLY_MEM > +capability allows it, to make a new slot read-only. In this case, writes to > +this memory will be posted to userspace as KVM_EXIT_MMIO exits. The third can > +be set, if the KVM_CAP_UNCACHED_MEM capability allows it. This remaps the > +memory as uncached, i.e. userspace will always directly read/write RAM for > +this memory region. I would repeat the definition of the flag in the text here instead of referring to the 'first', 'second', and 'third' here; it's too hard to follow. Also, which combination of these flags are allowed? Can they all be set in combination or are they mutually exclusive or a bit of everything? Thanks, -Christoffer