On 14.05.2024 11:51, Andrew Cooper wrote: > On 14/05/2024 10:25 am, Jan Beulich wrote: >> On 03.04.2024 08:16, Jan Beulich wrote: >>> On 02.04.2024 19:06, Andrew Cooper wrote: >>>> The commit makes a claim without any kind of justification. >>> Well, what does "have no business" leave open? >>> >>>> The claim is false, and the commit broke lsevtchn in dom0. >>> Or alternatively lsevtchn was doing something that was never meant to work >>> (from Xen's perspective). >>> >>>> It is also quite >>>> obvious from XSM_TARGET that it has broken device model stubdoms too. >>> Why would that be "obvious"? What business would a stubdom have to look at >>> Xen's side of an evtchn? >>> >>>> Whether to return information about a xen-owned evtchn is a matter of >>>> policy, >>>> and it's not acceptable to short circuit the XSM on the matter. >>> I can certainly accept this as one possible view point. As in so many cases >>> I'm afraid I dislike you putting it as if it was the only possible one. >>> >>> In summary: The supposed justification you claim is missing in the original >>> change is imo also missing here then: What business would any entity in the >>> system have to look at Xen's side of an event channel? Back at the time, 3 >>> people agreed that it's "none". >> You've never responded to this reply of mine, or its follow-up. You also >> didn't chime in on the discussion Daniel and I were having. I consider my >> objections unaddressed, and in fact I continue to consider the change to >> be wrong. Therefore it was inappropriate for you to commit it; it needs >> reverting asap. If you're not going to do so, I will. > > You tried defending breaking a utility with "well it shouldn't exist then". > > You don't have a leg to stand on, and two maintainers of relevant > subsystems here just got tired of bullshit being presented in place of > any credible argument for having done the change in the way you did.
Please can you finally get into the habit of not sending rude replies? > The correct response was "Sorry I broke things. Lets revert this for > now to unbreak, and I'll see about reworking it to not intentionally > subvert Xen's security mechanism". I'm sorry, but I didn't break things. I made things more consistent with the earlier change, as pointed out before: With your revert, evtchn_status() is now (again) inconsistent with e.g. evtchn_send(). If you were serious about this being something that needs leaving to XSM, you'd have adjusted such further uses of consumer_is_xen() as well. But you aren't. You're merely insisting on lsevtchn needing to continue to work in a way it should never have worked, with a patch to improve the situation already pending. Just to state a very basic principle here again: Xen-internal event channels ought to either be fully under XSM control when it comes to domains attempting to access them (in whichever way), or they should truly be Xen-internal, with access uniformly prevented. To me the former option simply makes very little sense. > As it stands, you're 2-1 outvoted, and wasted any sympathy I may have > had for the principle of the change based on the absurdity of your > arguments. No, pending objections are pending objections. Daniel's responses didn't eliminate them. As a separate aspect: I can't assume anymore that it is just coincidence that you taking such a controversial action is at a time when I'm away. Jan
