On Fri, Oct 18, 2019 at 02:02:52PM +0200, Andrew Jones wrote: > On Thu, Oct 17, 2019 at 05:17:59PM -0400, Masayoshi Mizuma wrote: > > Hi Drew, > > > > Thank you for posting the patches, they seems to work well > > because the softlockup is gone and the timestamp jump of > > dmesg and ftrace record also disappeared after the guest > > is virsh resume'ed. > > > > Let me add comments. > > I think the kvm-adjvtime behavior should be the default. > > How about introducing 'kvm-noadjvtime' parameter instead? > > kvm-noadjvtime is to provide the old behavior. > > > > That is because the time jump occurs timeout for timers even though > > the timer doesn't reach the timeout in the guest time. > > > > For example, below flow shows that user and/or kernel sets timer A > > for +10 sec and B for +20 sec in Guest, then Guest is suspended and > > it passes 60 sec, then Guest is resumed. Timer A and B go off because > > the Guest timestamp (TS) is jumped to 63. That is unexpected timer > > behavior for Guest. > > > > Host TS(sec) Guest TS(sec) Event > > ============ ============= ============================= > > 00 00 Guest: Set timer A for +10 sec > > 01 01 Guest: Set timer B for +20 sec > > 03 03 Host: virsh suspend Guest > > 63 63 Host: virsh resume Guest > > Guest: Timer A and B go off > > > > I believe kvm-adjvtime behavior is as following. So Time A > > and B go off as expected time. So, kvm-adjvtime behavior should > > be the default. > > > > Host TS(sec) Guest TS(sec) Event > > ============ ============= ============================= > > 00 00 Guest: Set timer A for +10 sec > > 01 01 Guest: Set timer B for +20 sec > > 03 03 Host: virsh suspend guest > > 63 03 Host: virsh resume guest > > 70 10 Guest: Timer A goes off > > 81 21 Guest: Timer B goes off > > > > Thanks for the testing Masa. Your timer test is another good example of > what can happen when a guest is paused. I'm sure there are many other ways > a pause could be problematic as well, especially if the guest has devices > passed through to it that it's actively using. I also don't expect > kvm-adjvtime to solve all those problems (like, for example, potential > problems with passthrough devices, networks, etc.) This means that guest > pausing should only be done by host admins that are intimately familiar > with the guest OS, workload, and network connections. They should be sure > that it can tolerate and recover from the pauses. Since the admins need to > make the decision to pause at all, then I think it's fair for them to also > decide if they want to try and mitigate some of the issues with > kvm-adjvtime, i.e. require them to enable it, rather than have it on by > default.
make sense to me, thanks. > Also, if we choose to enable it by default, then we'll need to > deal with the compatibility issues that come with changing a behavior. > That's not impossible, as this feature could be disabled for older > machine types, but it's messy. I agree with you, we shouldn't add such messy codes to resolve the compatibility issues... > > All that said, I won't argue too hard against kvm-adjvtime being on by > default, but let's see if others like Peter or Marc want to chime in on > it too. Yeah, I look forward to their comments. Thanks, Masa
