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
