| Message ID | CAHmME9qhe0ZemTkc2jkEO=_hu6PhvKUKGHC9QYTj2j+QHhNf8g@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | more serial ports on arm? | expand |
On 19 November 2018 at 23:46, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > Hey guys, > > I sort of lost track of the discussion, but what ever happened to > adding an extra serial port to the arm virt machine? I'm still > carrying around the attached patch to run build.wireguard.com and I'd > of course like to see a real solution upstream. It's still stuck, because unconditionally adding a second serial port to the virt board breaks some commonly used existing guest code (UEFI + Linux), and it's not clear to me what the best command line UI is for allowing the user to request the second serial port. thanks -- PMM
On Tue, Nov 20, 2018 at 11:08 AM Peter Maydell <peter.maydell@linaro.org> wrote: > It's still stuck, because unconditionally adding a second serial > port to the virt board breaks some commonly used existing guest > code (UEFI + Linux), and it's not clear to me what the best > command line UI is for allowing the user to request the second > serial port. Can the UI be the same more or less as for x86? Specify a second -serial, and then the machine gets one added? If it's in secure mode, then it's added as serial 3 instead of 2, to remain backwards compatible.
On Fri, 7 Dec 2018 at 04:43, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > On Tue, Nov 20, 2018 at 11:08 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > It's still stuck, because unconditionally adding a second serial > > port to the virt board breaks some commonly used existing guest > > code (UEFI + Linux), and it's not clear to me what the best > > command line UI is for allowing the user to request the second > > serial port. > > Can the UI be the same more or less as for x86? Specify a second > -serial, and then the machine gets one added? If it's in secure mode, > then it's added as serial 3 instead of 2, to remain backwards > compatible. Yeah, that was more or less my plan. I just haven't done the work of digging around to check whether it matches what other QEMU board models have done and whether there are any other hidden snags yet. thanks -- PMM
Hi Jason, On 12/7/18 5:42 AM, Jason A. Donenfeld wrote: > On Tue, Nov 20, 2018 at 11:08 AM Peter Maydell <peter.maydell@linaro.org> wrote: >> It's still stuck, because unconditionally adding a second serial >> port to the virt board breaks some commonly used existing guest >> code (UEFI + Linux), and it's not clear to me what the best >> command line UI is for allowing the user to request the second >> serial port. > > Can the UI be the same more or less as for x86? Specify a second > -serial, and then the machine gets one added? If it's in secure mode, > then it's added as serial 3 instead of 2, to remain backwards > compatible. You can use various -serial arguments. If a board supports 4 serials and you only want to see the 3rd (secure mode as your example) you could use: ./qemu -serial null -serial null -serial stdio serials #1 and #2 and #4 would be redirected to the null backend, thus ignored, and you bind the secure serial to your stdio.
On Mon, 10 Dec 2018 at 11:00, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > Hi Jason, > > On 12/7/18 5:42 AM, Jason A. Donenfeld wrote: > > On Tue, Nov 20, 2018 at 11:08 AM Peter Maydell <peter.maydell@linaro.org> wrote: > >> It's still stuck, because unconditionally adding a second serial > >> port to the virt board breaks some commonly used existing guest > >> code (UEFI + Linux), and it's not clear to me what the best > >> command line UI is for allowing the user to request the second > >> serial port. > > > > Can the UI be the same more or less as for x86? Specify a second > > -serial, and then the machine gets one added? If it's in secure mode, > > then it's added as serial 3 instead of 2, to remain backwards > > compatible. > > You can use various -serial arguments. > > If a board supports 4 serials and you only want to see the 3rd (secure > mode as your example) you could use: > > ./qemu -serial null -serial null -serial stdio That's the opposite of Jason's issue, which is that the 'virt' board only supports 1 serial port but he would like 2... thanks -- PMM
On 12/10/18 12:09 PM, Peter Maydell wrote: > On Mon, 10 Dec 2018 at 11:00, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: >> >> Hi Jason, >> >> On 12/7/18 5:42 AM, Jason A. Donenfeld wrote: >>> On Tue, Nov 20, 2018 at 11:08 AM Peter Maydell <peter.maydell@linaro.org> wrote: >>>> It's still stuck, because unconditionally adding a second serial >>>> port to the virt board breaks some commonly used existing guest >>>> code (UEFI + Linux), and it's not clear to me what the best >>>> command line UI is for allowing the user to request the second >>>> serial port. >>> >>> Can the UI be the same more or less as for x86? Specify a second >>> -serial, and then the machine gets one added? If it's in secure mode, >>> then it's added as serial 3 instead of 2, to remain backwards >>> compatible. >> >> You can use various -serial arguments. >> >> If a board supports 4 serials and you only want to see the 3rd (secure >> mode as your example) you could use: >> >> ./qemu -serial null -serial null -serial stdio > > That's the opposite of Jason's issue, which is that the 'virt' > board only supports 1 serial port but he would like 2... Oh sorry Jason, I misunderstood your question. Regards, Phil.
diff -ru qemu-3.0.0/hw/arm/virt.c qemu-3.0.0-modified/hw/arm/virt.c --- qemu-3.0.0/hw/arm/virt.c 2018-08-14 21:10:34.000000000 +0200 +++ qemu-3.0.0-modified/hw/arm/virt.c 2018-09-14 11:48:31.914772294 +0200 @@ -672,13 +672,7 @@ qemu_fdt_setprop(vms->fdt, nodename, "clock-names", clocknames, sizeof(clocknames)); - if (uart == VIRT_UART) { - qemu_fdt_setprop_string(vms->fdt, "/chosen", "stdout-path", nodename); - } else { - /* Mark as not usable by the normal world */ - qemu_fdt_setprop_string(vms->fdt, nodename, "status", "disabled"); - qemu_fdt_setprop_string(vms->fdt, nodename, "secure-status", "okay"); - } + qemu_fdt_setprop_string(vms->fdt, "/chosen", "stdout-path", nodename); g_free(nodename); } @@ -1497,11 +1491,11 @@ fdt_add_pmu_nodes(vms); + create_uart(vms, pic, VIRT_SECURE_UART, sysmem, serial_hd(1)); create_uart(vms, pic, VIRT_UART, sysmem, serial_hd(0)); if (vms->secure) { create_secure_ram(vms, secure_sysmem); - create_uart(vms, pic, VIRT_SECURE_UART, secure_sysmem, serial_hd(1)); } vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64);