On Thu, Jan 31, 2019 at 02:52:11PM +0000, Marc Zyngier wrote: > On 31/01/2019 12:57, Andrew Jones wrote: > > On Thu, Jan 31, 2019 at 12:51:56PM +0100, Christoffer Dall wrote: > > [...] > > >> I don't think there's anything very unconventional here. > > > > Normally if a thread observes a change to vcpu->requests, then we ensure a > > change to some accompanying data is also observable. We're reversing that > > here, which adds a need for additional barriers and a strict request > > checking order. > > > >> > >> Let's try this: If you have a better way of implementing this, how > >> about you write a patch? > > > > It would just be this patch minus the unnecessary barriers. I can send it > > if you like, but I wouldn't want to change the authorship for such a small > > change. > > Having these barriers makes it explicit (at least to me) what data we > expect to be visible in other threads and in which order. You keep > saying that order doesn't matter and we disagree on this. Yes, you've > listed cases where we can survive things coming in out of order, but > that's not a proof that we don't need them. > > So at the end of the day, and unless you can prove that the barriers are > not necessary by providing the same form of validation tool, I'm > inclined to go with the verified approach. I don't know how to compile and run the litmus test, but I'd be happy to try if given some pointers. If I did know how, I would add vcpu->mode to the P1 inputs and some additional lines that look similar to what's in "Ensuring Requests Are Seen" of Documentation/virtual/kvm/vcpu-requests.rst Even without the litmus test please allow me to try again to describe why I think the barriers may be removed. Any vcpu we're attempting to power on must be on its way to sleep with a SLEEP request, or already be sleeping. This means that it's outside guest mode, or will be shortly. If the vcpu observes power_off=false in vcpu_req_sleep(), whether it was awaken or never even got to sleep, we know that observation is taking place with vcpu->mode != IN_GUEST_MODE. We now no longer need to be concerned with the relationship between power_off and the RESET vcpu request. Now we just need to be certain that if another thread made a RESET vcpu request at some point since the powering off of the vcpu (the requesting for it to sleep), then there's no way to miss the reset request before the vcpu reenters guest mode. And of that we are certain. Thanks, drew
