On 23.10.2023 09:52, Roger Pau Monné wrote: > On Fri, Oct 20, 2023 at 04:16:16PM +0100, Andrew Cooper wrote: >> On 20/10/2023 3:50 pm, Durrant, Paul wrote: >>> On 20/10/2023 14:37, David Woodhouse wrote: >>> [snip] >>>>> >>>>> [0] >>>>> https://elixir.bootlin.com/linux/latest/source/drivers/tty/hvc/hvc_xen.c#L258 >>>> >>>> I'm not convinced I believe what the comment says there about evtchn 0 >>>> being theoretically valid. I don't believe zero is a valid evtchn#, is >>>> it? >>> >>> gfn 0 might be valid, but I'm also pretty sure evtchn 0 is not valid. >> >> GFN 0 very much is valid. >> >> evtchn 0 OTOH is explicitly not valid. From evtchn_init(): >> >> evtchn_from_port(d, 0)->state = ECS_RESERVED; >> >> >> However, the fields being 0 doesn't mean not available. That's the >> signal to saying "not connected yet", because that's what dom0 gets >> before xenconsoled starts up. > > Someone asked me the same a while back, and IIRC we don't state > anywhere in the public headers that event channel 0 is reserved, > however that has always? been part of the implementation. > > If we intend this to be reliable, we should add a define to the public > headers in order to signal that 0 will always be reserved.
I agree a comment should have been there; it's not clear to me what useful #define we could add. Jan
