Re: [PATCH] ns16550c: avoid crash in ns16550_endboot in PV shim mode

["Roger Pau Monné" <roger.pau@citrix.com>]

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.