From: Avi Kivity <avi@redhat.com>
To: ehrhardt@linux.vnet.ibm.com
Cc: kvm@vger.kernel.org, borntraeger@de.ibm.com, cotte@de.ibm.com,
heiko.carstens@de.ibm.com, schwidefsky@de.ibm.com,
Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH 3/3] kvm-s390: streamline memslot handling
Date: Sun, 24 May 2009 17:39:10 +0300 [thread overview]
Message-ID: <4A195C0E.3000900@redhat.com> (raw)
In-Reply-To: <1242826497-6797-4-git-send-email-ehrhardt@linux.vnet.ibm.com>
ehrhardt@linux.vnet.ibm.com wrote:
> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
>
> This patch relocates the variables kvm-s390 uses to track guest mem addr/size.
> As discussed dropping the variables at struct kvm_arch level allows to use the
> common vcpu->request based mechanism to reload guest memory if e.g. changes
> via set_memory_region.
> The kick mechanism introduced in this series is used to ensure running vcpus
> leave guest state to catch the update.
>
>
>
>
> rerun_vcpu:
> + if (vcpu->requests)
> + if (test_and_clear_bit(KVM_REQ_MMU_RELOAD, &vcpu->requests))
> + kvm_s390_vcpu_set_mem(vcpu);
> +
> /* verify, that memory has been registered */
> - if (!vcpu->kvm->arch.guest_memsize) {
> + if (!vcpu->arch.sie_block->gmslm) {
> vcpu_put(vcpu);
> + VCPU_EVENT(vcpu, 3, "%s", "no memory registered to run vcpu");
> return -EINVAL;
> }
x86 uses a double check: first we check vcpu->requests outside atomic
context, then we enter the critical section and check again for signals
and vcpu->requests.
This allows us (a) to do naughty things in vcpu->requests handlers, (b)
keep the critical section short.
Does this apply here?
> - /* update sie control blocks, and unlock all vcpus */
> + /* request update of sie control block for all available vcpus */
> for (i = 0; i < KVM_MAX_VCPUS; ++i) {
> if (kvm->vcpus[i]) {
> - kvm->vcpus[i]->arch.sie_block->gmsor =
> - kvm->arch.guest_origin;
> - kvm->vcpus[i]->arch.sie_block->gmslm =
> - kvm->arch.guest_memsize +
> - kvm->arch.guest_origin +
> - VIRTIODESCSPACE - 1ul;
> - mutex_unlock(&kvm->vcpus[i]->mutex);
> + set_bit(KVM_REQ_MMU_RELOAD, &kvm->vcpus[i]->requests);
> + kvm_s390_inject_sigp_stop(kvm->vcpus[i],
> + ACTION_RELOADVCPU_ON_STOP);
> }
> }
>
There already exists a loop which does this, see
make_all_cpus_request(). It uses an IPI (Marcelo, can't it use the
reschedule interrupt?). It has a couple of optimizations -- if the
request is already set, it skips the IPI, and it avoids the IPI for
vcpus out of guest mode. Maybe it could fit s390 too.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2009-05-24 14:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-20 13:34 [PATCH 0/3] kvm-s390: revised version of kvm-s390 guest memory handling ehrhardt
2009-05-20 13:34 ` [PATCH 1/3] kvm-s390: infrastructure to kick vcpus out of guest state ehrhardt
2009-05-20 13:34 ` [PATCH 2/3] kvm-s390: fix signal handling ehrhardt
2009-05-20 13:34 ` [PATCH 3/3] kvm-s390: streamline memslot handling ehrhardt
2009-05-24 14:39 ` Avi Kivity [this message]
2009-05-25 8:33 ` Christian Ehrhardt
2009-05-25 11:40 ` Christian Ehrhardt
2009-05-26 7:57 ` Avi Kivity
2009-05-26 8:31 ` Christian Bornträger
2009-05-26 9:27 ` Avi Kivity
2009-05-26 10:31 ` Christian Ehrhardt
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=4A195C0E.3000900@redhat.com \
--to=avi@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cotte@de.ibm.com \
--cc=ehrhardt@linux.vnet.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=schwidefsky@de.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.