[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems in PV dom0 on recent x86 hardware
- To: Jürgen Groß <jgross@xxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
- From: Jason Andryuk <jason.andryuk@xxxxxxx>
- Date: Tue, 9 Jul 2024 09:08:11 -0400
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LlpqXmSyRDgkU25hc8SLHYu2bhD4WWJ4MtJWsEyMHzI=; b=KlpFPFCoMRiHVzHGwKgaMNs8vaqQ7BKC9phAVw1gNAVteQ4OwC6UjSknvpJ7g+gkj6t85HFCTczcPgqtywcnwOZtmLo/i/zzsX3odonlebMx93AoiwINTiZEMPs/TloWcay4CcYT7AFbEdF/+TAJaSpcPp90dQOC+aDI3N5GELWYHGR1nj7Le4VEvQmSEIq6eYV6JTPU5h4fZEu0zZY26c+rDCn4imRssOkEhqRCATArSZOJy6XEeE1eVv/YLceX9NGhNc54YC76HUSwMOtnTfq2w3rmoYJNAPin2f1TiPYK7dOXfMjdzJ+cuzL4kep3WaXk6aySfnaglQbTM0fUeQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GzfFn8P1aaEt74rEpTpskRA18oSgJ6E1VsSrs7lh+PB6jmZhExunMG2N+l6LoH3OtIGL+xSTn/u2Gql7MBbJ6tSvmZ/Ax0tDh34mvtXWJON0vcSzF17lv4B1Km0i9d43BM+krZ/ceFymH3UOcvSxL5g0HXEg9RIKIMrCdZBfyL/xZdpwgak++2t8e6g1tY1e8rH52/zK5BVojcHDemAgUOerir9sI9xfFF6pqQqPcCAws6Kwhr+BP37DaDby3NskT7Fr7i40AY8evBUrwFZ9qRbxDiqPZPhY0yajiM6AlHxUnh/j6778KDrv55a7+PMFCIP2YUU8vT5VAGRsv5S84g==
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Tue, 09 Jul 2024 13:08:29 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.
Regards,
Jason
|
