On 20 June 2013 22:55, Alexander Graf <agraf@xxxxxxx> 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@xxxxxxxxxx> 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. thanks -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
