[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] ns16550c: avoid crash in ns16550_endboot in PV shim mode
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Mon, 23 Oct 2023 09:52:25 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EWuSkg4H/5wCyVt4WNJy2f/fCJA1bOdZB4QcT0QLqfo=; b=YixOc9tGhOOkjw14mUX+QxauwlqSuWJSgECRHMZzOefGF9NuAmyD1v7+NuCSnImfW9SQyxfKWF18UZAzQjTg0FDEityb+KqKWXHN5FI2M3DqIbYYGYujieJS6EDk7WaB8Gykgyq2QTw2LRLhWbPcv+R9+NmCDCWAc/Z3eGHmMFxdmvPwQLT7lIxRJ687z9qWTP2WH/qD/ark215buga+zYRMYnc69GGeaEN60oU6CKEiFF55jqL/uyIA3snET5scPT4y2XPtEIrJTGtkRtOCIoLJ6m8iA74dcCFZfozigVgBnNwL21snS5p/62k1A1F55d5jUzmRoIYVzAT5milSMQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ilwvlfGMiTaKX9b5gOMIkXpUWLyD6OoOkJp6bf/KDWBA0Gco/Zo8J4gRBbYRkM8Y+dpplqU8JCPUGCo3xfEgy3s7ykip/YAfx0EFPM6+nt/MHQQhe36ODEcG714HLH64FcrBe/hlx2OhcSVMrm+GM0r3T99H8a/TbFfu1CanyQrJChKciF4+xynWI+HR4sUvxG6YKoH4FABFpLUDnLXTguPxJVfGH0Jtju1TaOjEvJvm69KxoWundZ8NjASWoj++lO2d9qgqWHBQIFgD1waHxYJWHDuMWb0gqkJ8IJSq2wuSDusBYVcbRut2t32MdSSHi7HNAOLoX+cjUU/kYlP3/Q==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 23 Oct 2023 07:52:41 +0000
- Ironport-data: A9a23:pTlt8aIyb+fnIr0zFE+R0JQlxSXFcZb7ZxGr2PjKsXjdYENS1DBRz TNMCm2DPvbcamH3f40jO4Tl9R8BvpPRmNViGwtlqX01Q3x08seUXt7xwmUcnc+xBpaaEB84t ZV2hv3odp1coqr0/0/1WlTZhSAhk/nOHvylULKs1hlZHWdMUD0mhQ9oh9k3i4tphcnRKw6Ws Jb5rta31GWNglaYCUpKrfrYwP9TlK6q4mhB5gZkPaojUGL2zBH5MrpOfcldEFOgKmVkNrbSb /rOyri/4lTY838FYj9yuu+mGqGiaue60Tmm0hK6aYD76vRxjnVaPpIAHOgdcS9qZwChxLid/ jnvWauYEm/FNoWU8AgUvoIx/ytWZcWq85efSZSzXFD6I+QrvBIAzt03ZHzaM7H09c5qC2AWq qI0KAkAf1ennN+c5KiJV7Jz05FLwMnDZOvzu1lG5BSAVLMMZ8CGRK/Ho9hFwD03m8ZCW+7EY NYUYiZuaxKGZABTPlAQC9Q1m+LAanvXKmUE7g7K4/dnpTGNnGSd05C0WDbRUsaNSshP2F6Ru 0rN/njjAwFcP9uaodaA2iv22LCfwX6nCer+EpWTxtQ1hFCixVAXETwIc3CGsaG6hkKHDoc3x 0s8v3BGQbIJ3FymSJzxUgO1pFaAvwUAQJxAHusi8gaPx6HIpQGDCQA5oiVpbdUnsIo8Q2ws3 1rQxtfxX2Ux4PuSVG6X8aqSoXWqIy8JIGQeZCgCCwwY/93kp4J1hRXKJjp+LJOIYhTOMWmY6 1i3QOIW3t3/UeZjO32HwG36
- Ironport-hdrordr: A9a23:8uJ30K0WFSUEDgmbVIZHPAqjBHYkLtp133Aq2lEZdPU0SKGlfq GV7ZEmPHrP4gr5N0tOpTntAse9qBDnhPxICOsqXYtKNTOO0AeVxelZhrcKqAeQeBEWmNQ96U 9hGZIOcuEZDzJB/LvHCN/TKadd/DGFmprY+ts31x1WPGVXgzkL1XYANu6ceHcGIzVuNN4CO7 e3wNFInDakcWR/VLXBOpFUN9KzweEijfjdEGc7OyI=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.
Roger.
|