Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"

[Jan Beulich <jbeulich@suse.com>]

On 03.04.2024 15:27, Daniel P. Smith wrote:
> On 4/3/24 08:05, Jan Beulich wrote:
>> On 03.04.2024 13:10, Daniel P. Smith wrote:
>>> On 4/3/24 02:16, Jan Beulich wrote:
>>>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>>>>    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?
>>>
>>> Again, you have not expressed why it shouldn't be able to do so.
>>
>> See above - not its resource, nor its guest's.
> 
> It is a resource provided to a domain that the domain can send/raise an 
> event to and a backing domain that can bind to it, ie. the two 
> parameters that must be passed to the allocation call.

Before writing this particular part of your reply, did you look as
evtchn_send()? Sending on such ports is similarly denied without
involving XSM. For a good reason, stated in the accompanying comment.
It is therefore simply inconsistent to allow any kind of other
operation on such ports. Hence the patch that Andrew now deems needs
reverting.

In fact I view these ports living in the guest's event channel space
as similarly inappropriate as the ioreq pages - until a few years
back - living in the guest's GFN space.

Jan