Re: [PATCH for-6.2] hw/arm/virt_acpi_build: Generate DBG2 table

[Ard Biesheuvel]

On Tue, 10 Aug 2021 at 15:11, Samer El-Haj-Mahmoud
<Samer.El-Haj-Mahmoud@arm.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Eric Auger <eric.auger@redhat.com>
> > Sent: Tuesday, August 10, 2021 6:25 AM
> > To: Ard Biesheuvel <ardb@kernel.org>
> > Cc: eric.auger.pro@gmail.com; Michael S. Tsirkin <mst@redhat.com>; Igor
> > Mammedov <imammedo@redhat.com>; Philippe Mathieu-Daudé
> > <philmd@redhat.com>; Peter Maydell <peter.maydell@linaro.org>; Shannon
> > Zhao <shannon.zhaosl@gmail.com>; qemu-arm <qemu-arm@nongnu.org>;
> > qemu-devel@nongnu.org; Andrew Jones <drjones@redhat.com>;
> > gshan@redhat.com; Samer El-Haj-Mahmoud <Samer.El-Haj-
> > Mahmoud@arm.com>; Al Stone <ahs3@redhat.com>; jcm@redhat.com
> > Subject: Re: [PATCH for-6.2] hw/arm/virt_acpi_build: Generate DBG2 table
> >
> > Hello Ard,
> > On 8/10/21 11:36 AM, Ard Biesheuvel wrote:
> > > On Tue, 10 Aug 2021 at 10:31, Eric Auger <eric.auger@redhat.com> wrote:
> > >> ARM SBBR specification mandates DBG2 table (Debug Port Table 2).
> > >> this latter allows to describe one or more debug ports.
> > >>
> > >> Generate an DBG2 table featuring a single debug port, the PL011.
> > >>
> > >> The DBG2 specification can be found at:
> > >> https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-
> > debug-port-table?redirectedfrom=MSDN
> > >>
> > > Have the legal issues around this table been resolved in the mean
> > > time?
> > I don't know exactly what they are. Adding Al and Jon in the loop they
> > have more information about this.
> > How did you resolve the issue for EDK2
> > (DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c)?
> > >  Also, any clue why this table is mandatory to begin with? The
> > > SBBR has been very trigger happy lately with making things mandatory
> > > that aren't truly required from a functional perspective.
> > It seems there are kernel FW test suites that check all mandated tables
> > are available and they currently fail for ARM virt.
> > Indeed from a function pov, I don't know much about its usage on ARM.
> >
> > Maybe the SBBR spec should not flag the DBG2 as mandatory and test
> > suites shall be updated. I think this should be clarified at ARM then,
> > all the more so if there are legal issues as its spec is owned by Microsoft?
> >
>
> DBG2 has been required in SBBR since SBBR ver 1.0 (published 2016, with the 
> 0.9 draft since 2014)
> https://developer.arm.com/documentation/den0044/b/?lang=en
>
> SBBR requires DBG2 because Windows requires it on all systems: 
> https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-system-description-tables#debug-port-table-2-dbg2
>  , and Windows is one of the key OSes targeted by SBBR.
>
> The DBG2 (and SPCR) spec license issue has been resolved since August 2015. 
> Microsoft updated both specs with identical license language, giving patent 
> rights for implementations under the Microsoft Community Promise, and the 
> Open OWF 1.0. This Foundation.
>
> DBG2: 
> https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table
> SPCR: 
> https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table
>

Thanks Samer, for stating this on record here - and apologies for
suggesting that this was another frivolous addition to a recent SBBR
revision.

As for the difference between the two: SPCR describes the serial
console, which is an actual interactive console used for maintenance,
which exists in addition to the full blown Windows GUI, which is
always the primary interface.

DBG2 is used as a debug port, which is used for the kernel debugger,
if I am not mistaken. So SPCR and DBG2 are complementary, and it does
make sense to have both.