From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: Xiao Guangrong <guangrong.xiao@linux.intel.com>,
rkrcmar@redhat.com, bdas@redhat.com,
linux-s390 <linux-s390@vger.kernel.org>
Subject: Re: [RFC PATCH 00/11] KVM: multiple address spaces (for SMM)
Date: Wed, 20 May 2015 10:31:58 +0200 [thread overview]
Message-ID: <555C467E.5060106@de.ibm.com> (raw)
In-Reply-To: <1431956923-35602-1-git-send-email-pbonzini@redhat.com>
Am 18.05.2015 um 15:48 schrieb Paolo Bonzini:
> This implements Avi's suggestion of having two separate kvm_memslots for
> regular and SMM operation, corresponding to different address spaces.
>
> All in all, the surgery is limited even though there are a few preparatory
> patches that touch all architectures.
>
> The amount of added code for the vcpu-specific versions of kvm_read_guest
> and kvm_write_guest is smaller, and duplication is limited to a couple of
> functions. Even the rmap parts, which scared me a lot when the first
> version OOPSed on me, :) are actually very easy.
>
> Patches 1-6 are preparatory cleanups that can be applied separately,
> while the others will be posted in v2 of the SMM patches.
>
> Patches 7-8 add the new functions (this time in virt/kvm/kvm_main.c).
> Architectures can then define a function kvm_arch_vcpu_memslots_id that
> returns the active address space id for a given VCPU. The address space
> ID must be passed to KVM_SET_USER_MEMORY_REGION and KVM_GET_DIRTY_LOG,
> using the high 16 bits of the slot id.
>
> Patch 9 then does VCPU-specific accesses in x86, and patch 10 loops
> over the SMM slots as well on memslot iterations.
>
> Patch 11 then introduces the SMRAM address space, which is very simple
> after all the legwork.
>
> Thanks for the reviews,
So in essence this allows to have each vcpu in separate address space if
necessary. These address space might overlap or be identical and allow
permutations by having different memslots for each address space.
And we can have several address spaces per vcpu. Correct?
This might be useful for kvm on s390 (e.g. we did the ucontrol thing that
also has one guest address space per vcpu). I need to have a look at that.
Christian
next prev parent reply other threads:[~2015-05-20 8:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-18 13:48 [RFC PATCH 00/11] KVM: multiple address spaces (for SMM) Paolo Bonzini
2015-05-18 13:48 ` [PATCH 01/11] KVM: introduce kvm_alloc/free_memslots Paolo Bonzini
2015-05-18 13:48 ` [PATCH 02/11] KVM: use kvm_memslots whenever possible Paolo Bonzini
2015-05-18 13:48 ` [PATCH 03/11] KVM: const-ify uses of struct kvm_userspace_memory_region Paolo Bonzini
2015-05-18 13:48 ` [PATCH 04/11] KVM: add memslots argument to kvm_arch_memslots_updated Paolo Bonzini
2015-05-18 13:48 ` [PATCH 05/11] KVM: add "new" argument to kvm_arch_commit_memory_region Paolo Bonzini
2015-05-18 13:48 ` [PATCH 06/11] KVM: x86: pass kvm_mmu_page to gfn_to_rmap Paolo Bonzini
2015-05-20 8:30 ` Xiao Guangrong
2015-05-20 9:07 ` Paolo Bonzini
2015-05-18 13:48 ` [PATCH 07/11] KVM: add vcpu-specific functions to read/write/translate GFNs Paolo Bonzini
2015-05-18 13:48 ` [PATCH 08/11] KVM: implement multiple address spaces Paolo Bonzini
2015-05-19 13:32 ` Radim Krčmář
2015-05-19 16:19 ` Paolo Bonzini
2015-05-19 18:28 ` Radim Krčmář
2015-05-20 7:07 ` Paolo Bonzini
2015-05-20 15:46 ` Radim Krčmář
2015-05-20 18:17 ` Paolo Bonzini
2015-05-18 13:48 ` [PATCH 09/11] KVM: x86: use vcpu-specific functions to read/write/translate GFNs Paolo Bonzini
2015-05-18 13:48 ` [PATCH 10/11] KVM: x86: work on all available address spaces Paolo Bonzini
2015-05-18 13:48 ` [PATCH 11/11] KVM: x86: add SMM to the MMU role, support SMRAM address space Paolo Bonzini
2015-05-20 8:34 ` Xiao Guangrong
2015-05-20 8:57 ` Paolo Bonzini
2015-05-20 8:31 ` Christian Borntraeger [this message]
2015-05-20 8:58 ` [RFC PATCH 00/11] KVM: multiple address spaces (for SMM) Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=555C467E.5060106@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=bdas@redhat.com \
--cc=guangrong.xiao@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).