Re: Problems in PV dom0 on recent x86 hardware

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Jul 09, 2024 at 09:08:11AM -0400, Jason Andryuk wrote:
> On 2024-07-09 06:56, Jürgen Groß wrote:
> > On 09.07.24 09:01, Jan Beulich wrote:
> > > On 09.07.2024 08:36, Jürgen Groß wrote:
> > > > On 09.07.24 08:24, Jan Beulich wrote:
> > > > > On 08.07.2024 23:30, Jason Andryuk wrote:
> > > > > >    From the backtrace, it looks like the immediate case
> > > > > > is just trying to
> > > > > > read a 4-byte version:
> > > > > > 
> > > > > >    >>>> [   44.575541]  ucsi_acpi_dsm+0x53/0x80
> > > > > >    >>>> [   44.575546]  ucsi_acpi_read+0x2e/0x60
> > > > > >    >>>> [   44.575550]  ucsi_register+0x24/0xa0
> > > > > >    >>>> [   44.575555]  ucsi_acpi_probe+0x162/0x1e3
> > > > > > 
> > > > > > int ucsi_register(struct ucsi *ucsi)
> > > > > > {
> > > > > >            int ret;
> > > > > > 
> > > > > >            ret = ucsi->ops->read(ucsi, UCSI_VERSION, &ucsi->version,
> > > > > >                                  sizeof(ucsi->version));
> > > > > > 
> > > > > > ->read being ucsi_acpi_read()
> > > > > > 
> > > > > > However, the driver also appears write to adjacent addresses.
> > > > > 
> > > > > There are also corresponding write functions in the driver, yes, but
> > > > > ucsi_acpi_async_write() (used directly or indirectly) similarly calls
> > > > > ucsi_acpi_dsm(), which wires through to acpi_evaluate_dsm(). That's
> > > > > ACPI object evaluation, which isn't obvious without seeing the
> > > > > involved AML whether it might write said memory region.
> > > > 
> > > > I guess an ACPI dump would help here?
> > > 
> > > Perhaps, yes.
> > 
> > It is available in the bug report:
> > 
> > https://bugzilla.opensuse.org/show_bug.cgi?id=1227301
> 
> After acpixtract & iasl:
> 
> $ grep -ir FEEC *
> dsdt.dsl:   OperationRegion (ECMM, SystemMemory, 0xFEEC2000, 0x0100)
> ssdt16.dsl: OperationRegion (SUSC, SystemMemory, 0xFEEC2100, 0x30)
> 
> 
> from the DSDT:
>     Scope (\_SB.PCI0.LPC0.EC0)
>     {
>         OperationRegion (ECMM, SystemMemory, 0xFEEC2000, 0x0100)
>         Field (ECMM, AnyAcc, Lock, Preserve)
>         {
>             TWBT,   2048
>         }
> 
>         Name (BTBF, Buffer (0x0100)
>         {
>              0x00                                             // .
>         })
>         Method (BTIF, 0, NotSerialized)
>         {
>             BTBF = TWBT /* \_SB_.PCI0.LPC0.EC0_.TWBT */
>             Return (BTBF) /* \_SB_.PCI0.LPC0.EC0_.BTBF */
>         }
>     }
> 
> From SSDT16:
> DefinitionBlock ("", "SSDT", 2, "LENOVO", "UsbCTabl", 0x00000001)
> {
>     External (_SB_.PCI0.LPC0.EC0_, DeviceObj)
> 
>     Scope (\_SB)
>     {
>         OperationRegion (SUSC, SystemMemory, 0xFEEC2100, 0x30)
>         Field (SUSC, ByteAcc, Lock, Preserve)
>         {
> 
> 
> This embedded controller (?) seems to live at 0xfeec2xxx.

I've done some further research on this, and my current hypothesis is
that the region defined in 0xfeec2xxx contains at least the UCSI
shared mailbox, used for communication between ACPI and the OSPM.

This is a regular RAM region (iow: not MMIO), that's used to send and
receive UCSI commands with the mediation of ACPI.

The specification that defines the interface can be found at:

https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/bios-implementation-of-ucsi.pdf

If my suspicion is correct, this is a purely software defined
interface, and hence not related to the chipset or the CPU in any way.

I will attempt to contact Lenovo to figure out which of their systems
place the mailbox in the 0xfeecxxxx range, and how we can detect
this.

I think such memory range should likely be defined in the memory map
with type EfiACPIMemoryNVS, so that we know it's presence and can map
it into the guest.  Otherwise this won't work with PVH dom0.

Regards, Roger.