From: David Hildenbrand <david@redhat.com>
To: "Collin L. Walling" <walling@linux.vnet.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
Cornelia Huck <cohuck@redhat.com>,
Janosch Frank <frankja@linux.vnet.ibm.com>
Subject: Re: [PATCH RFC 4/6] KVM: s390: consider epoch index on TOD clock syncs
Date: Thu, 8 Feb 2018 13:15:55 +0100 [thread overview]
Message-ID: <bd8ce1fc-6ed9-5c4c-0912-0c9bac36b015@redhat.com> (raw)
In-Reply-To: <65719abd-37bb-c9ca-88d5-ecb230696a04@linux.vnet.ibm.com>
>> The rules of unsigned addition should make sure that all cases are
>> covered. (I tried to find a counter example but wasn't able to find one)
>
> Agreed. I just wrote down a few edge cases myself... it seems to check
> out nicely.
>
>>
>> (Especially, this is the same code pattern as found in
>> arch/s390/kvm/vsie.c:register_shadow_scb(), which also adds two signed
>> numbers.)
>>
>>>> /*
>>>> * This callback is executed during stop_machine(). All CPUs are therefore
>>>> * temporarily stopped. In order not to change guest behavior, we have to
>>>> @@ -194,13 +216,17 @@ static int kvm_clock_sync(struct notifier_block *notifier, unsigned long val,
>>>> unsigned long long *delta = v;
>>>>
>>>> list_for_each_entry(kvm, &vm_list, vm_list) {
>>>> - kvm->arch.epoch -= *delta;
>>>> kvm_for_each_vcpu(i, vcpu, kvm) {
>>>> - vcpu->arch.sie_block->epoch -= *delta;
>>>> + kvm_clock_sync_scb(vcpu->arch.sie_block, *delta);
>>>> + if (i == 0) {
>>>> + kvm->arch.epoch = vcpu->arch.sie_block->epoch;
>>>> + kvm->arch.epdx = vcpu->arch.sie_block->epdx;
>>> Are we safe by setting the kvm epochs to the sie epochs wrt migration?
>> Yes, in fact they should be the same for all VCPUs, otherwise we are in
>> trouble. The TOD has to be the same over all VCPUs.
>>
>> So we should always have
>> - kvm->arch.epoch == vcpu->arch.sie_block->epoch
>> - kvm->arch.epdx == vcpu->arch.sie_block->epdx
>> for all VCPUs, otherwise their TOD could differ.
>
> Perhaps then this could be shortened to calculate the epochs only once,
> then set
> each vcpu to those values instead ofcalculating on each iteration?
>
I had that before, but changed it to this. Especially because some weird user
space could set the epochs differently on different CPUs (e.g. for testing
purposes or IDK).
So something like this is not shorter and possibly performs less calculations
list_for_each_entry(kvm, &vm_list, vm_list) {
kvm_for_each_vcpu(i, vcpu, kvm) {
- kvm_clock_sync_scb(vcpu->arch.sie_block, *delta);
if (i == 0) {
+ kvm_clock_sync_scb(vcpu->arch.sie_block, *delta);
kvm->arch.epoch = vcpu->arch.sie_block->epoch;
kvm->arch.epdx = vcpu->arch.sie_block->epdx;
+ } else {
+ vcpu->arch.sie_block->epoch = kvm->arch.epoch;
+ vcpu->arch.sie_block->epdx = kvm->arch.epdx;
}
if (vcpu->arch.cputm_enabled)
vcpu->arch.cputm_start += *delta;
I'll let the Maintainers decide :)
> I imagine the number of iterations would never be large enough to cause any
> considerable performance hits, though.
Thanks!
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2018-02-08 12:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-07 11:46 [PATCH RFC 0/6] KVM: s390: Multiple-epoch facility fixes David Hildenbrand
2018-02-07 11:46 ` [PATCH RFC 1/6] KVM: s390: take care of clock-comparator sign control David Hildenbrand
2018-02-07 13:47 ` Collin L. Walling
2018-02-07 13:58 ` David Hildenbrand
2018-02-07 14:06 ` Christian Borntraeger
2018-02-16 9:45 ` Christian Borntraeger
2018-02-07 11:46 ` [PATCH RFC 2/6] KVM: s390: provide only a single function for setting the tod David Hildenbrand
2018-02-07 20:13 ` Collin L. Walling
2018-02-07 20:15 ` Collin L. Walling
2018-02-07 21:42 ` David Hildenbrand
2018-02-07 11:46 ` [PATCH RFC 3/6] KVM: s390: consider epoch index on hotplugged CPUs David Hildenbrand
2018-02-15 13:09 ` Cornelia Huck
2018-02-16 9:50 ` Christian Borntraeger
2018-02-07 11:46 ` [PATCH RFC 4/6] KVM: s390: consider epoch index on TOD clock syncs David Hildenbrand
2018-02-07 20:08 ` Collin L. Walling
2018-02-07 21:35 ` David Hildenbrand
2018-02-07 22:43 ` Collin L. Walling
2018-02-08 12:15 ` David Hildenbrand [this message]
2018-02-07 11:46 ` [PATCH RFC 5/6] KVM: s390: no need to inititalize kvm->arch members to 0 David Hildenbrand
2018-02-15 13:25 ` Cornelia Huck
2018-02-07 11:46 ` [PATCH RFC 6/6] KVM: s390: generalize kvm_s390_get_tod_clock_ext() David Hildenbrand
2018-02-15 14:08 ` Cornelia Huck
2018-02-15 14:14 ` David Hildenbrand
2018-02-15 14:17 ` Cornelia Huck
2018-02-15 14:25 ` David Hildenbrand
2018-02-07 11:50 ` [PATCH RFC 0/6] KVM: s390: Multiple-epoch facility fixes David Hildenbrand
[not found] <b25f6e5e-a5e6-54fc-910e-ad2e6e83bbb1@redhat.com>
2018-02-20 15:56 ` [PATCH RFC 4/6] KVM: s390: consider epoch index on TOD clock syncs Christian Borntraeger
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=bd8ce1fc-6ed9-5c4c-0912-0c9bac36b015@redhat.com \
--to=david@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=frankja@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=walling@linux.vnet.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 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).