linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM/KVM: save and restore generic timer registers
Date: Thu, 20 Jun 2013 11:32:21 -0700	[thread overview]
Message-ID: <20130620183221.GE4563@lvm> (raw)
In-Reply-To: <51C339BD.2080600@arm.com>

[...]

> >>> +int kvm_arm_timer_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> >>> +{
> >>> +	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> >>> +	void __user *uaddr = (void __user *)(long)reg->addr;
> >>> +	u64 val;
> >>> +	int ret;
> >>> +
> >>> +	ret = copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id));
> >>> +	if (ret != 0)
> >>> +		return ret;
> >>> +
> >>> +	switch (reg->id) {
> >>> +	case KVM_REG_ARM_TIMER_CTL:
> >>> +		timer->cntv_ctl = val;
> >>> +		break;
> >>> +	case KVM_REG_ARM_TIMER_CNT:
> >>> +		vcpu->kvm->arch.timer.cntvoff = kvm_phys_timer_read() - val;
> >>
> >> I just realized what bothers me here: You're computing cntvoff on a per
> >> vcpu basis, while this is a VM property. Which means that as you're
> >> restoring vcpus, you'll be changing cntvoff - sounds like a bad idea to me.
> >>
> >> The counter is really global. Do we have a way to handle VM-wide
> >> registers? I think Christoffer was trying to some a similar thing with
> >> the GIC...
> >>
> > 
> > We do have a way, but it requires user space to create a device and keep
> > track of the device fd just to set/get a single register, which seems
> > like overkill to me.
> > 
> > I suggest you do one of two things:
> >  1. Whenever this value is written, make sure it's written across all
> >     vcpus, so guests always have a consistent view of time (be careful
> >     about synchronization here).
> >  2. Move the cntvoff value to the vm struct instead, so there's only one
> >     offset and a consistent view of time.  This may have an adverse
> >     effect on the world-switch code performance, but I suspect it would
> >     completely disappear in the noise.
> > 
> > I dont' feel strongly about either approach.
> 
> So it turns out I've completely forgotten about that - cntvoff is
> already per-VM (the indirection shows it). Doh.

right.... ahem.

> 
> So there is just one thing we absolutely need to make sure here: no vcpu
> can run before they've all had their timer restored, and hence a stable
> cntvoff. Otherwise two vcpus will have a different view of time.
> 
> Can we guarantee this?
> 

Do we need to?  User space is free to modify time and all sort of other
registers at any point during VM execution - it will just break the
guest that it's running.

I think the key here is that we expect the VM to be stopped for all
save/restore operations (we can enforce it if we want to, which I am
going to for the VGIC state, because we don't want to interfere with
consistent state being written to the hardware).

-Christoffer

  reply	other threads:[~2013-06-20 18:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-11 15:16 [PATCH v2] ARM/KVM: save and restore generic timer registers Andre Przywara
2013-06-19 21:16 ` Christoffer Dall
2013-06-20 10:10 ` Marc Zyngier
2013-06-20 17:09   ` Christoffer Dall
2013-06-20 17:19     ` Marc Zyngier
2013-06-20 18:32       ` Christoffer Dall [this message]
2013-06-20 18:39         ` Marc Zyngier
2013-06-20 19:29         ` Peter Maydell
2013-06-20 20:37           ` Christoffer Dall
2013-06-20 21:55             ` Alexander Graf
2013-06-20 21:59               ` Peter Maydell
2013-06-20 22:02                 ` Alexander Graf
2013-06-20 22:48                   ` Christoffer Dall
2013-07-05 14:08   ` Andre Przywara
2013-07-05 14:44     ` Marc Zyngier

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=20130620183221.GE4563@lvm \
    --to=christoffer.dall@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).