From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52642) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zh0mm-0008WG-VY for qemu-devel@nongnu.org; Tue, 29 Sep 2015 15:42:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zh0mh-0001Zy-Tn for qemu-devel@nongnu.org; Tue, 29 Sep 2015 15:42:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zh0Sx-00027W-7M for qemu-devel@nongnu.org; Tue, 29 Sep 2015 15:21:31 -0400 References: <1443389342-2186-1-git-send-email-somlo@cmu.edu> <20150929132638-mutt-send-email-mst@redhat.com> <560A9940.3060207@redhat.com> <20150929171458-mutt-send-email-mst@redhat.com> <20150929190413.GB23832@HEDWIG.INI.CMU.EDU> From: Laszlo Ersek Message-ID: <560AE4B5.8020504@redhat.com> Date: Tue, 29 Sep 2015 21:21:25 +0200 MIME-Version: 1.0 In-Reply-To: <20150929190413.GB23832@HEDWIG.INI.CMU.EDU> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 0/5] add ACPI node for fw_cfg on pc and arm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" , "Michael S. Tsirkin" Cc: peter.maydell@linaro.org, drjones@redhat.com, matt.fleming@intel.com, ehabkost@redhat.com, ard.biesheuvel@linaro.org, zhaoshenglong@huawei.com, qemu-devel@nongnu.org, leif.lindholm@linaro.org, kevin@koconnor.net, kraxel@redhat.com, pbonzini@redhat.com, imammedo@redhat.com, markmb@redhat.com, rth@twiddle.net 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