linux-s390.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Wed, 7 Feb 2018 22:35:50 +0100	[thread overview]
Message-ID: <402a12fb-28ec-c11a-de72-222fde27517b@redhat.com> (raw)
In-Reply-To: <438d8539-44fa-2661-ea04-a0642c48c9fa@linux.vnet.ibm.com>

On 07.02.2018 21:08, Collin L. Walling wrote:
> On 02/07/2018 06:46 AM, David Hildenbrand wrote:
>> For now, we don't take care of over/underflows. Especially underflows
>> are critical:
>>
>> Assume the epoch is currently 0 and we get a sync request for delta=1,
>> meaning the TOD is moved forward by 1 and we have to fix it up by
>> subtracting 1 from the epoch. Right now, this will leave the epoch
>> index untouched, resulting in epoch=-1, epoch_idx=0, which is wrong.
>>
>> We have to take care of over and underflows, also for the VSIE case. So
>> let's factor out calculation into a separate function.
>>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>>   arch/s390/kvm/kvm-s390.c | 32 +++++++++++++++++++++++++++++---
>>   1 file changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index d007b737cd4d..c2b62379049e 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -179,6 +179,28 @@ int kvm_arch_hardware_enable(void)
>>   static void kvm_gmap_notifier(struct gmap *gmap, unsigned long start,
>>   			      unsigned long end);
>>
>> +static void kvm_clock_sync_scb(struct kvm_s390_sie_block *scb, u64 delta)
>> +{
>> +	u64 delta_idx = 0;
>> +
>> +	/*
>> +	 * The TOD jumps by delta, we have to compensate this by adding
>> +	 * -delta to the epoch.
>> +	 */
>> +	delta = -delta;
>> +
>> +	/* sign-extension - we're adding to signed values below */
>> +	if ((s64)delta < 0)
>> +		delta_idx = 0xff;
>> +
>> +	scb->epoch += delta;
>> +	if (scb->ecd & ECD_MEF) {
>> +		scb->epdx += delta_idx;
>> +		if (scb->epoch < delta)
>> +			scb->epdx += 1;
>> +	}
>> +}
>> +
> 
> Is the sync always a jump forward? Do we need to worry about a borrow 
> from the epdx in case of underflow?

I can jump forward and backwards, so delta can be positive or negative,
resulting in -delta being positive or negative.

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)

(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.

This is also guaranteed by the way we calculate and update these numbers.

The only special case is if somebody would be using
set_on_reg/get_one_reg with KVM_REG_S390_EPOCHDIFF, setting different
values - very unlikely and bad.

> 
>> +			}
>>   			if (vcpu->arch.cputm_enabled)
>>   				vcpu->arch.cputm_start += *delta;
>>   			if (vcpu->arch.vsie_block)
>> -				vcpu->arch.vsie_block->epoch -= *delta;
>> +				kvm_clock_sync_scb(vcpu->arch.vsie_block,
>> +						   *delta);
>>   		}
>>   	}
>>   	return NOTIFY_OK;
> 


-- 

Thanks,

David / dhildenb

  reply	other threads:[~2018-02-07 21:35 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 [this message]
2018-02-07 22:43       ` Collin L. Walling
2018-02-08 12:15         ` David Hildenbrand
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=402a12fb-28ec-c11a-de72-222fde27517b@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).