[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ns16550: find the console UART on PCI when there is no legacy one


  • To: Benjamin Leggett <benjamin@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 23 Sep 2026 08:11:22 +0200
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 23 Sep 2026 06:11:47 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22.09.2026 20:43, Benjamin Leggett wrote:
> Amazon EC2 bare metal instances have no UART at the legacy I/O port
> 0x3f8. Their only serial port is a 16550-compatible PCI device (vendor
> 0x1d0f, device 0x8250) with its registers in the MMIO space of BAR 0.
> Today Xen has no console on these systems unless the command line
> names that device, and "com1=...,pci" cannot find it, because
> uart_config[] doesn't have it.
> 
> Add the device to uart_config[].

Is there a spec that you could point to here?

> Additionally, when the port that com1 describes is not present, scan PCI
> for a known UART before giving up. This way the same command line works on
> systems with and without a legacy UART, and a machine-specific "pci"
> option is not needed. The fallback does not run when the command line
> gave an I/O base, or when it already asked for a scan with "pci" or
> "amt", so explicit config keeps its current meaning. It is
> for com1 only: for com2, pci_uart_config() skips the first port it
> finds, so it can never match a single-port device.

This needs to be split to a separate patch, and not only because right
now you're doing two entirely unrelated things in a single change. The
addition of the Amazon device is likely uncontroversial, so presumably
can go in quickly. Doing a scan when none was asked for, otoh, is
potentially problematic: What if there's an issue during scanning? With
not having any output set up yet, we couldn't even indicate the problem,
and a possible crash would also go entirely silently.

> When the scan finds nothing, pci_uart_config() puts back the original
> base, and check_existence() does not test MMIO addresses.
> 
> On a system with a legacy UART, check_existence() passes and nothing
> changes.

This isn't really true, is it? You check ...

> @@ -1805,7 +1825,32 @@ static void __init ns16550_parse_port_config(
>      if ( uart->io_base == 0 )
>          PARSE_ERR("I/O base address must be specified.");
>      if ( !check_existence(uart) )
> -        PARSE_ERR("16550-compatible serial UART not present");
> +    {
> +        bool present = false;
> +
> +#ifdef NS16550_PCI
> +        /*
> +         * Some systems, EC2 bare metal among them, have no legacy UART and
> +         * carry their only serial port on PCI. Look for one before giving 
> up,
> +         * unless the command line named a base or already asked for a scan.
> +         * com1 only: for com2 the scan skips the first port it finds, so it
> +         * can never match a single-port device.
> +         */
> +        if ( uart == ns16550_com && !uart->io_base_set && !uart->pci_scanned 
> )

... ->io_base_set here, which can only be true when a command line option
provided the base address. A cmdline option like "com1=115200" doesn't,
and instead the value set by (on x86) __start_xen() is used. If that isn't
the correct address to use, check_existence() is (hopefully) going to fail.
(For example, I have a system where firmware mixes up COM1 and COM2
settings, which you may only notice after having played with things for a
while. In such a case it doesn't help if unexpected PCI bus scanning gets
in the way.)

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.