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
next prev parent 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).