On Mon, Oct 23, 2023 at 10:05:48AM +0200, Jan Beulich wrote: > 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.
`EVTCHN_PORT_INVALID 0` or some such, but a comment would also be fine, the point is to be part of the public interface. Thanks, Roger.
