From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
devel@edk2.groups.io, ardb@kernel.org,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
Julien Grall <julien@xen.org>,
Leif Lindholm <quic_llindhol@quicinc.com>,
Sami Mujawar <sami.mujawar@arm.com>
Subject: Re: [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs
Date: Fri, 27 Oct 2023 12:57:10 +0200 [thread overview]
Message-ID: <wvggoelfonyt5ya5quslldhnuvsi5aua3e7nqc4ommznb6vmkc@gufduilx6uu7> (raw)
In-Reply-To: <9e698cf7-7e58-b32b-58e9-e18f54736f75@redhat.com>
Hi,
> So, for this purpose, only the following could have a chance of working:
>
> - Expose a new config option on the QEMU command line to the user,
> regarding the intended use of the serial port(s). This could be of any
> tolerable form (machine property, front-end (device) property, whatever
> -- anything that QEMU reviewers can accept).
>
> - In QEMU, generate both the DT and the ACPI tables accordingly. The
> ACPI tables would have to immediately *not* contain the UART-to-hide (so
> as to keep it secret from the guest OS). The DT at the same time would
> still have to expose the "runtime DEBUG UART", because edk2 would have
> to know where that UART was (and that it was meant specifically for OS
> runtime debug output).
>
> - Edk2 would have to patch the DT (we tend to do that already), because
> (in some configs) we do forward the DT to the guest OS. This need for
> patching could be lifted if QEMU adopted such a form of expression for
> the "runtime DEBUG UART" that would be ignored by Linux out of the box.
That approach looks best to me. It allows the user to specify on the
qemu command line what the ports should be used for, which is IMHO the
most convenient option. qemu generates the complete DSDT anyway, so
it's trivial to add/remove serial ports there, and for the DT we have
libfdt to do the work needed.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110201): https://edk2.groups.io/g/devel/message/110201
Mute This Topic: https://groups.io/mt/101834880/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
prev parent reply other threads:[~2023-10-27 10:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-08 15:39 [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs Laszlo Ersek
2023-10-08 15:39 ` [edk2-devel] [PATCH 1/9] ArmVirtPkg: introduce FdtSerialPortAddressLib Laszlo Ersek
2023-10-08 15:39 ` [edk2-devel] [PATCH 2/9] ArmVirtPkg/Fdt16550SerialPortHookLib: rebase to FdtSerialPortAddressLib Laszlo Ersek
2023-10-08 15:39 ` [edk2-devel] [PATCH 3/9] ArmVirtPkg: adjust whitespace in block scope declarations Laszlo Ersek
2023-10-08 15:39 ` [edk2-devel] [PATCH 4/9] ArmVirtPkg: adhere to the serial port selected by /chosen "stdout-path" Laszlo Ersek
2023-10-08 15:39 ` [edk2-devel] [PATCH 5/9] ArmVirtPkg: store separate console and debug PL011 addresses in GUID HOB Laszlo Ersek
2023-10-08 15:39 ` [edk2-devel] [PATCH 6/9] ArmVirtPkg: introduce DebugLibFdtPL011Uart Flash instance Laszlo Ersek
2023-10-08 15:39 ` [edk2-devel] [PATCH 7/9] ArmVirtPkg: introduce DebugLibFdtPL011Uart RAM instance Laszlo Ersek
2023-10-08 15:39 ` [edk2-devel] [PATCH 8/9] ArmVirtPkg: introduce DebugLibFdtPL011Uart DXE Runtime instance Laszlo Ersek
2023-10-08 15:39 ` [edk2-devel] [PATCH 9/9] ArmVirtPkg: steer DebugLib output away from SerialPortLib+console traffic Laszlo Ersek
2023-10-10 7:43 ` [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs Ard Biesheuvel
2023-10-10 15:33 ` Laszlo Ersek
2023-10-26 14:21 ` Peter Maydell
2023-10-26 14:46 ` Julien Grall
2023-10-26 14:55 ` Ard Biesheuvel
2023-10-26 15:36 ` Laszlo Ersek
2023-10-26 15:30 ` Laszlo Ersek
2023-10-26 15:19 ` Laszlo Ersek
2023-10-26 15:21 ` Ard Biesheuvel
2023-10-26 19:00 ` Laszlo Ersek
2023-10-27 10:57 ` Gerd Hoffmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=wvggoelfonyt5ya5quslldhnuvsi5aua3e7nqc4ommznb6vmkc@gufduilx6uu7 \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox