Re: [Qemu-devel] [PATCH v2 4/5] acpi: arm: add fw_cfg device node to dsdt

[Peter Maydell]

On 15 September 2015 at 14:42, Gabriel L. Somlo <address@hidden> wrote:
> On Tue, Sep 15, 2015 at 10:06:45AM +0800, Shannon Zhao wrote:
>> This looks fine to me. But from what you said, the kernel driver is not
>> in upstream kernel yet, so this would be applied after the kernel patch
>> applied in case of unexpected change.
>
> I guess that's ok if you're only talking about the arm side of things
> -- although I can't imagine how any of the above would need to change
> depending on what happens with the guest-side kernel sysfs driver...
> We're talking a node name ("FWCF"), a _HID ("QEMU0002"), and a mmio
> region (given to us by memmap[VIRT_FW_CFG]), and that's all there is
> to it...

The underlying requirement here is "we don't want patches until
the ABI is fixed". For ACPI and DTB on ARM the final arbiter of
the ABI seems to be the kernel (partly because the reviewers there
are better informed with the overall ACPI/DTB requirements).
I don't know who the final arbiter of the ACPI ABI for x86 is.

We've already had a couple of issues with problems with the ACPI
ABI for what appear to be very simple "just some registers and
an interrupt" type devices, including "is this the correct HID?".

> However, on the i386 side, this needs to go in *before* I can continue
> working on the guest-side kernel sysfs drivers. One of the
> requirements I got was not to probe IOports or MMIO registers blindly,
> but rather to use DT on arm and ACPI on i386 to first make sure fw_cfg
> is expected to be there, before tickling its registers :)

> So I need (at least the i386 part of) this series in qemu before I can
> move ahead with the (guest) kernel driver...

Why can't you work on your guest kernel driver using a set of
out-of-tree QEMU patches to test it with?

thanks
-- PMM