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 15:48:44 -0700 [thread overview]
Message-ID: <20130620224844.GM4563@lvm> (raw)
In-Reply-To: <7BA55D0B-D754-4FD2-BD4C-6223AA063E27@suse.de>
On Fri, Jun 21, 2013 at 12:02:02AM +0200, Alexander Graf wrote:
>
> On 20.06.2013, at 23:59, Peter Maydell wrote:
>
> > On 20 June 2013 22:55, Alexander Graf <agraf@suse.de> wrote:
> >>
> >> On 20.06.2013, at 22:37, Christoffer Dall wrote:
> >>
> >>> On Thu, Jun 20, 2013 at 08:29:30PM +0100, Peter Maydell wrote:
> >>>> On 20 June 2013 19:32, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> >>>>> Marc wrote:
> >>>>>> 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.
> >>>>
> >>>> Note that QEMU will stop all CPUs before doing a migration or
> >>>> similar operation. However there is a monitor command to query
> >>>> the current CPU registers etc which won't try to stop the VM
> >>>> first. So we might try to read vcpu registers (though I hope we
> >>>> don't allow writing them).
> >>>>
> >>> Sounds like we need to add a -EBUSY return on SET_ONE_REG if the VM is
> >>> running.
> >>
> >> The ONE_REG API should already be protected here, as it does
> >> vcpu_load() in kvm_vcpu_ioctl(). So a separate thread can't possibly
> >> do ONE_REG accesses while another thread has the same vcpu running.
> >
> > Doesn't protect you against confusion due to another thread running
> > a different vcpu in the same vm, though.
>
> Ah, different ONE_REG API. Can't you just notify all vcpus to exit and refresh their timers? That's what kvm_make_request() is there for, no?
>
yes you can, but I don't think it's worth the trouble to add the code in
the kernel to fix a case where user space does something completely
broken, which does not muck with the hardware or host state, but can
only break the guest.
I didn't realize that ONE_REG does vcpu_load() (or, I probably did once,
and forgot) so that means we're good.
Conclusion on this patch: address Marc's comment to move the user space
interface handling out of arch_timer.c and we should be good.
Thanks,
-Christoffer
next prev parent reply other threads:[~2013-06-20 22:48 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
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 [this message]
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=20130620224844.GM4563@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).