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
