qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marcello Sylverster Bauer <sylv@sylv.io>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org, imammedo@redhat.com, ani@anisinha.ca,
	Patrick Rudolph <patrick.rudolph@9elements.com>
Subject: Re: PCI Hotplug ACPI device names only 3 characters long
Date: Tue, 5 Sep 2023 19:45:12 +0200	[thread overview]
Message-ID: <bfd8c202-0ceb-47c2-8e9c-9547bd4bdd5f@sylv.io> (raw)
In-Reply-To: <20230905123447-mutt-send-email-mst@kernel.org>

Hi Michael,

On 9/5/23 18:44, Michael S. Tsirkin wrote:
> On Tue, Sep 05, 2023 at 05:05:33PM +0200, Marcello Sylverster Bauer wrote:
>> Greetings,
>>
>> I'm currently working on a project to support Intel IPU6 in QEMU via VFIO so
>> that the guest system can access the camera. This requires extending the
>> ACPI device definition so that the guest knows how to access the camera.
>>
>> However, I cannot extend the PCI devices because their names are not 4
>> characters long and therefore do not follow the ACPI specification.
>>
>> When I use '-acpitable' to include my own SSDT for the IPU6 PCI device, it
>> does not allow me to declare the device as an External Object because it
>> automatically adds padding underscores.
>>
>> e.g.
>> Before:
>> ```
>> External(_SB.PCI0.S18.SA0, DeviceObj)
>> ```
>> After:
>> ```
>> External(_SB.PCI0.S18_.SA0_, DeviceObj)
>> ```
>>
>> Adding the underscore padding is hard coded in iASL and also in QEMU when
>> parsing an ASL file. (see: build_append_nameseg())
>>
>> So here are my questions:
>> 1. Is there a solution to extend the ACPI PCI device using '-acpitable'
>> without having to patch iASL or QEMU?
>> 2. Are there any plans to change the names to comply with the ACPI spec?
>> (e.g. use "S%.03X" format string instead)
>>
>> Thanks
>> Marcello
> 
> 
> 1.  All names in ACPI are always exactly 4 characters long. _ is a legal character
>      but names beginning with _ are reserved.

Exactly, which is why I want to address this issue here. Currently, Qemu 
generates ACPI device names with only 3 characters. (See 
build_append_pci_bus_devices() in hw/i386/acpi-build.c).
For example, the device I want to append entries to has the path 
"_SB.PCI0.S18.SA0", but I can't because of the two auto-generated 
devices with only 3 characters in their names.

> There's no rule in ACPI
>      spec that says they need to follow S%.03X or any other specific format.
>      I'm pretty sure we do follow the ACPI specification in this but feel free to
>      prove me wrong.

You have misunderstood me. Currently, Qemu uses the following format to 
create PCI ACPI devices:

```
aml_name("S%.02X", devfn)
```

My question is whether we should change it to something that results in 
a 4 character name like "S%.03X" or "S%.02X_".

I have tested it and it works fine as long as any hardcoded path 
references are adjusted. But I'm not 100% sure if this could cause any 
regressions.

> 2.  You can probably add something to existing ACPI devices using Scope().

I'm pretty sure the external object is required when loading a separate 
SSDT, but I'll try by just using scopes.

>      I would not advise relying on this - current names are not a stable
>      interface that we guarantee across QEMU versions.
>      If adding this functionality is desirable, I think we'll need some new interface
>      to set a stable ACPI name. Maybe using aliases.

Currently I'm just working on a PoW to get IPU6 working in QEMU, so 
instability is fine.

Thanks,
Marcello

> 
> 


  reply	other threads:[~2023-09-05 17:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-05 15:05 PCI Hotplug ACPI device names only 3 characters long Marcello Sylverster Bauer
2023-09-05 15:09 ` Philippe Mathieu-Daudé
2023-09-05 15:21   ` Marcello Sylverster Bauer
2023-09-05 16:44 ` Michael S. Tsirkin
2023-09-05 17:45   ` Marcello Sylverster Bauer [this message]
2023-09-05 20:43     ` Michael S. Tsirkin
2023-09-06  8:19       ` Igor Mammedov
2023-09-06 10:45         ` Marcello Sylverster Bauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bfd8c202-0ceb-47c2-8e9c-9547bd4bdd5f@sylv.io \
    --to=sylv@sylv.io \
    --cc=ani@anisinha.ca \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=patrick.rudolph@9elements.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).