Re: [Qemu-devel] [PATCH v4 0/5] add ACPI node for fw_cfg on pc and arm

[Laszlo Ersek]

On 09/29/15 21:04, Gabriel L. Somlo wrote:
> On Tue, Sep 29, 2015 at 05:15:25PM +0300, Michael S. Tsirkin wrote:
>> On Tue, Sep 29, 2015 at 03:59:28PM +0200, Laszlo Ersek wrote:
>>> On 09/29/15 12:27, Michael S. Tsirkin wrote:
>>>> On Sun, Sep 27, 2015 at 05:28:57PM -0400, Gabriel L. Somlo wrote:
>>>>> New since v3:
>>>>>
>>>>>   - rebased to work on top of 87e896ab (introducing pc-*-25 classes),
>>>>>     inserting fw_cfg acpi node only for machines >= 2.5.
>>>>>
>>>>>   - reintroduce _STA with value 0x0B (bit 2 for u/i visibility turned
>>>>>     off to avoid Windows complaining -- thanks Igor for catching that!)
>>>>>
>>>>> If there's any other feedback besides questions regarding the
>>>>> appropriateness of "QEMU0002" as the value of _HID, please don't hesitate!
>>>>>
>>>>> Thanks much,
>>>>>   --Gabriel
>>>>
>>>> How does /proc/ioports look before and after this patch?
>>>
>>> ... I vaguely remember that /proc/ioports and /proc/iomem tracks only
>>> actual allocations by drivers. So the driver is supposed to get the
>>> resources from ACPI, but until a driver actually allocates the ports (I
>>> fail to recall the exact Linux APIs ATM -- apologies), the registers
>>> might not show up in these pseudo-files.
>>>
>>> OTOH Gabriel is working on a guest kernel driver that would look at ACPI
>>> I think...
>>>
>>> Laszlo
>>
>> What does the driver do? I hope it doesn't poke at _CRS ...
> 
> I mentioned this elsewhere in the thread, but since I didn't
> address your _CRS remark explicitly:
> 
> The driver I'm working on (guest-)kernel-side serves to
> access fw_cfg blob metadata and raw content in sysfs (look
> at /sys/firmware/dmi/entries/... for something similar).
> 
> The driver is written, tested, and works great, but right now
> it has a list of port-io and mmio (base + size) pairs which
> I'm probing in decreasing order of probability:
> 
>       1. io-port on i386 (and sun4u)
>       2. mmio on arm
>       3. mmio on ppc/mac
>       4. mmio on sun4m
> 
> from its module_init function.
> 
> The arm guys basically said "No, you can't do that, use DT to first
> *know* for sure you have fw_cfg before touching its mmio registers".
> 
> I've sort of assumed that's valid on i386 as well, and that I should
> query ACPI for a fw_cfg node (and yes, use whatever is in _CRS to
> set the value of the io-port (or mmio) base, and width).
> 
> That means dropping support for ppc/mac and sun4m since there's no DT
> or ACPI there. I'm also not quite sure how I'd query ACPI during a
> module_init function, so if you know of any examples I could use for
> inspiratin, I'd be really thankful for a pointer :)
> 
> Anyhow, that's the story, any further comments and clues much
> appreciated!

I'd recommend looking at acpi_dev_get_resources(),
acpi_dev_resource_io(), etc in "drivers/acpi/resource.c", but I think
that's exactly what Michael said he hoped your kernel code wouldn't
do... I'm a bit confused about that, admittedly.

Also, if you go the ACPI way, your kernel driver will have to probe /
bind the device based on _HID -- see eg.
"drivers/platform/x86/pvpanic.c" (which is the guest driver for the
pvpanic device, QEMU0001).

Thanks
Laszlo