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!
Thanks,
--Gabriel
