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. Thanks, M. -- Jazz is not dead. It just smells funny...
