Re: Problems in PV dom0 on recent x86 hardware

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.07.2024 12: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

With

        OperationRegion (SUSC, SystemMemory, 0xFEEC2100, 0x30)
        Field (SUSC, ByteAcc, Lock, Preserve)
        {
            SCMD,   8, 
            ...

and

            Method (SECM, 1, Serialized)
            {
                Local0 = 0x64
                While (((\_SB.SCMD != 0x00) && (Local0 != 0x00)))
                {
                    Sleep (0x01)
                    Local0--
                }

                \_SB.SCMD = Arg0
                ...

it is clear that granting read access isn't going to be enough.

>From /proc/iomem I also can't see that Linux would have marked as reserved
that region in any way. I'm really uncertain as to whether what Lenovo are
doing here is actually legitimate. If it was, I currently have no good
idea what to do about it.

Jan