From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1lN2cT-0003kv-MO for mharc-grub-devel@gnu.org; Thu, 18 Mar 2021 20:04:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59292) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lN2cS-0003ki-3l for grub-devel@gnu.org; Thu, 18 Mar 2021 20:04:00 -0400 Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]:39572) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lN2cL-000884-S6 for grub-devel@gnu.org; Thu, 18 Mar 2021 20:03:59 -0400 Received: by mail-ot1-x32a.google.com with SMTP id h6-20020a0568300346b02901b71a850ab4so6898632ote.6 for ; Thu, 18 Mar 2021 17:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficientek-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=NvJIiVkzKpEmVOuuAxB6rGwAkgtISA/HDYyf2S5loEo=; b=YnSj+u0vs8hcF49KvyQB2FD5sLlW98vccsyN3m6mEJI4ER1CGqzYhtEAcU5a8fLNHv Dcu4+VorZ/UUO5Y2nVmnY/0ezcfpQRV5QeuqK/t5ykw7Mt9g4+28XTInb67u/lQzErn2 qUC3mE6vMc82IFl+PrNfZUuVieDcGd4Um0KOdYB3HctoejM51eWQnUFlce94GP6Xx2J7 jdgpn6odvA60NBlvQ/1PMwqms0/t/fQ3PuHX2lSj4s21ReJfJfB6By80vzuIq4OqveLg kNnwuvkeM3pTPPY7oEOjO/WDaVvo+3LBYM7LGLtzUPVAzKvwrlw5x15h0LDfbtv+G9Lf fQ+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=NvJIiVkzKpEmVOuuAxB6rGwAkgtISA/HDYyf2S5loEo=; b=GYPLb4uJV0onIhYBUepVKsUcfHm3LJu0lJjPLjJosVjzadmMUQAGhnZnbxvr3xZKG9 nVMlUba/AnFOEwbec/j8eyHQQi1dByYzqHgJQhTX3LTmKpsXhGnPyXTx++mTpQdm9P9h InEOdaszvfTn/vt2as8pxDMG8k8jOYDRUL8aSvpZzuaZi1C2D5rwN+lri2YUol+BBlV0 dmgpqoIaBZJcwc4koeSkaW1Y5DkdqCJRF2o7PDWXF/F8vSuZ1GSZsMu+JbyUSo1qJP4k n+FG4R1k937kmd2YABC8hDbKl2Ba6scmbvWljAUlVRL/WSeMIqzVlfViL9Qa6eHEkoCr hwbQ== X-Gm-Message-State: AOAM530JGTq52IFoUQ+WsC4K1OeHxW+Fk32K9XgY3ufbHQ7cXRdNWwpY 7HA3n+kDjdClpJLwam8QDx+blpzH2ux0w8/j X-Google-Smtp-Source: ABdhPJxIkKl6ktn4M80n4VweshYX8MYs42c9kooTh0I6F8czf1NlctKqZKICpLU+nXVzfS54wLfnUw== X-Received: by 2002:a05:6830:20d2:: with SMTP id z18mr6827179otq.260.1616112231647; Thu, 18 Mar 2021 17:03:51 -0700 (PDT) Received: from crass-HP-ZBook-15-G2 ([2605:a601:ab16:db00:2d8f:7736:b0ad:4a36]) by smtp.gmail.com with ESMTPSA id y143sm863791oie.50.2021.03.18.17.03.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Mar 2021 17:03:51 -0700 (PDT) Date: Thu, 18 Mar 2021 19:03:46 -0500 From: Glenn Washburn To: Benjamin Herrenschmidt Cc: The development of GNU GRUB , Matthias Lange Subject: Re: [PATCH 0/5] serial: Add MMIO & SPCR support for AWS EC2 metal instances Message-ID: <20210318190346.11570717@crass-HP-ZBook-15-G2> In-Reply-To: <20210318220728.495970-1-benh@kernel.crashing.org> References: <20210318220728.495970-1-benh@kernel.crashing.org> Reply-To: development@efficientek.com X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2607:f8b0:4864:20::32a; envelope-from=development@efficientek.com; helo=mail-ot1-x32a.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 00:04:00 -0000 Hey Ben, On Fri, 19 Mar 2021 09:07:23 +1100 Benjamin Herrenschmidt wrote: > (Apologies if that got sent twice, there was an issue with my setup > yesterday causing it to be sent with the wrong From: line) > > This series adds support for the serial console of AWS EC2 "metal" x86 > instances to grub. This requires two improvements: > > - Support for MMIO accesses to the 8250 serial port. This adds the > basic plumbing, a function to register an MMIO based port, and > support for configuring an MMIO port by using the string "mmio" > followed by a hex address for the --port directive. [Q: Should we > instead add a --mmio directive ? Can we make two such options > mutually exclusive with the current infrastructure ?] > > - Support for setting up a default port using the ACPI SPCR table if > present. This series will make this happen if the command "serial" is > used without arguments. In that case, SPCR will be used if present, > otherwise grub will revert to com0 with default settings as before. > > This work started originally from Matthias Lange series > https://marc.info/?l=grub-devel&m=148775823217022&w=2 > > However, I ended up rewriting most of it using a different approach > which I felt was less invasive and simpler, as I don't expect we will > be collecting more 'backends' for ns8250.c among other things. > > I did not keep Matthias original support for OXSEMI PCI uart. This can > be fairly easily added on top, however, I believe a better approach > would be to define a syntax to the "serial" command to define a PCI > UART by seg/bus/dev/fn with options to set the base clock. > > We could also add a table of "known" ones as we go based in vid/did > similar to what Linux does. None of this was necessary for my purpose > and I lack the ability/time to test this setup, but it would be easy > to add it on top of this series. > > This was tested using SPCR on an actual c5.metal instance, and using > explicit instanciation via serial -p mmioXXXXXXXX on a modified qemu > hacked to create MMIO PCI serial ports. When you say a modified qemu, was that a source level change? I'm curious how hard it would be to add this test to the current GRUB make check tests (many of which already use qemu). Of course, if they source of qemu was modified, then its probably a deal breaker (until it could be accepted upstream). Also I haven't looked into it, but seems like it might not be hard to add a separate test for the part using the SPCR table via qemu (perhaps using the "-acpitable" arg). Also, could you add to the documentation on the usage of these changes? New functionality should in general come with new tests (when feasible) and additions to the documentation. Thanks for contributing, Glenn