Re: [Qemu-devel] [PATCH v5 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

On Tue, Nov 24, 2015 at 10:38:18AM -0700, Eric Blake wrote: > On 11/24/2015 09:55 AM, Gabriel L. Somlo wrote: > > On Tue, Nov 24, 2015 at 04:14:50AM +0800, kbuild test robot wrote: > > >> > >>drivers/firmware/qemu_fw_cfg.c: In function 'fw_cfg_cmdline

Re: [Qemu-devel] [PATCH v5 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

On Tue, Nov 24, 2015 at 04:14:50AM +0800, kbuild test robot wrote: > Hi Gabriel, > > [auto build test WARNING on v4.4-rc2] > [also build test WARNING on next-20151123] > [cannot apply to robh/for-next] > > url: > https://github.com/0day-ci/linux/commits/Gabriel-L-Som

Re: [Qemu-devel] [PATCH v5 0/6] fw_cfg: spec update, misc. cleanup, optimize read

On Tue, Nov 24, 2015 at 08:21:45AM +0100, Gerd Hoffmann wrote: > On Mo, 2015-11-23 at 09:18 -0500, Gabriel L. Somlo wrote: > > Ping ? > > > > I can send out v6 and fix the commit blurb typo in patch 6/6 pointed > > out by Laszlo (unless the series is already winding it

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

tectures besides ARM and x86 ? If so, is there a way to additionally provide offsets (and sizes), besides just the overall range ? If we are NOT planning to ever do DT or ACPI outside x86 and ARM, then nevermind I said anything :) Thanks much, --Gabriel On Fri, Nov 13, 2015 at 09:57:13PM -

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

On Mon, Nov 23, 2015 at 08:46:33PM +0100, Laszlo Ersek wrote: > On 11/23/15 20:31, Gabriel L. Somlo wrote: > > Couple of items: > > > > 1. Ping ? :) > > > > 2. Thank you markmb for your R-b ! > > > > 3. If anyone's had a chance to look over the

Re: [Qemu-devel] [PATCH v5 0/6] fw_cfg: spec update, misc. cleanup, optimize read

Ping ? I can send out v6 and fix the commit blurb typo in patch 6/6 pointed out by Laszlo (unless the series is already winding its way toward eventually being applied). Please advise. Thanks, --Gabriel On Thu, Nov 05, 2015 at 09:32:46AM -0500, Gabriel L. Somlo wrote: > New since

[Qemu-devel] [PATCH v5 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

gister + * + * e.g.: + * fw_cfg.ioport=2@0x510:0:1 (the default on x86) + * or + * fw_cfg.mmio=0xA@0x902:8:0 (the default on arm) + */ + +#include +#include +#include +#include +#include +#include + +MODULE_AUTHOR("Gabriel L. Somlo <so...@cmu.edu&

[Qemu-devel] [PATCH v5 2/4] kobject: export kset_find_obj() for module use

From: Gabriel Somlo Signed-off-by: Gabriel Somlo --- lib/kobject.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/kobject.c b/lib/kobject.c index 7cbccd2..90d1be6 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -861,6 +861,7 @@ struct kobject

[Qemu-devel] [PATCH v5 4/4] devicetree: update documentation for fw_cfg ARM bindings

From: Gabriel Somlo Remove fw_cfg hardware interface details from Documentation/devicetree/bindings/arm/fw-cfg.txt, and replace them with a pointer to the authoritative documentation in the QEMU source tree. Signed-off-by: Gabriel Somlo Cc: Laszlo Ersek

[Qemu-devel] [PATCH v5 0/4] SysFS driver for QEMU fw_cfg device

Allow access to QEMU firmware blobs, passed into the guest VM via the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name, size, and fw_cfg key), as well as the raw binary blob data may be accessed. The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was selected based on

[Qemu-devel] [PATCH v5 3/4] firmware: create directory hierarchy for sysfs fw_cfg entries

From: Gabriel Somlo Each fw_cfg entry of type "file" has an associated 56-char, nul-terminated ASCII string which represents its name. While the fw_cfg device doesn't itself impose any specific naming convention, QEMU developers have traditionally used path name semantics (i.e.

Re: [Qemu-devel] [PATCH v5 4/4] devicetree: update documentation for fw_cfg ARM bindings

On Mon, Nov 23, 2015 at 05:35:51PM +0100, Laszlo Ersek wrote: > On 11/23/15 16:57, Gabriel L. Somlo wrote: > > From: Gabriel Somlo <so...@cmu.edu> > > > > Remove fw_cfg hardware interface details from > > Documentation/devicetree/bindings/arm/fw-cfg.txt, &g

Re: [Qemu-devel] [PATCH v4 4/4] devicetree: update documentation for fw_cfg ARM bindings

On Wed, Nov 18, 2015 at 02:04:24PM +0100, François Revol wrote: > On 17/11/2015 23:14, Rob Herring wrote: > > On Mon, Nov 16, 2015 at 2:38 AM, Paolo Bonzini wrote: > >> > >> > >> On 15/11/2015 03:07, Rob Herring wrote: > >>> We generally don't want DT docs to depend on other

Re: [Qemu-devel] [PATCH v4 4/4] devicetree: update documentation for fw_cfg ARM bindings

On Tue, Nov 17, 2015 at 04:14:42PM -0600, Rob Herring wrote: > On Mon, Nov 16, 2015 at 2:38 AM, Paolo Bonzini wrote: > > > > > > On 15/11/2015 03:07, Rob Herring wrote: > >> We generally don't want DT docs to depend on other kernel documentation. > > > > DT docs do not

Re: [Qemu-devel] [PATCH v4 4/4] devicetree: update documentation for fw_cfg ARM bindings

On Mon, Nov 16, 2015 at 09:38:18AM +0100, Paolo Bonzini wrote: > On 15/11/2015 03:07, Rob Herring wrote: > > We generally don't want DT docs to depend on other kernel documentation. > > DT docs do not contain a copy of the data sheets, either. There is no > reason to say how to use the device

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

or the node name, and "FWCF0001" >>>> for _HID; no idea whether that's appropriate, or how else I should >>>> figure out what to use instead... >>>> >>>> Also, using scope "\\_SB", based on where fw_cfg shows up in the >>>> out

[Qemu-devel] [PATCH v5 1/5] fw_cfg: expose control register size in fw_cfg.h

Expose the size of the control register (FW_CFG_CTL_SIZE) in fw_cfg.h. Add comment to fw_cfg_io_realize() pointing out that since the 8-bit data register is always subsumed by the 16-bit control register in the port I/O case, we use the control register width as the *total* width of the (classic,

[Qemu-devel] [PATCH v5 3/5] acpi: pc: add fw_cfg device node to ssdt

Add a fw_cfg device node to the ACPI SSDT. While the guest-side firmware can't utilize this information (since it has to access the hard-coded fw_cfg device to extract ACPI tables to begin with), having fw_cfg listed in ACPI will help the guest kernel keep a more accurate inventory of in-use IO

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

Add a fw_cfg device node to the ACPI DSDT. This is mostly informational, as the authoritative fw_cfg MMIO region(s) are listed in the Device Tree. However, since we are building ACPI tables, we might as well be thorough while at it... Signed-off-by: Gabriel Somlo Reviewed-by:

[Qemu-devel] [PATCH v5 5/5] fw_cfg: document ACPI device node information

Signed-off-by: Gabriel Somlo Reviewed-by: Laszlo Ersek --- docs/specs/fw_cfg.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt index 2099ad9..5414140 100644 --- a/docs/specs/fw_cfg.txt +++

[Qemu-devel] [PATCH v4 3/4] firmware: create directory hierarchy for sysfs fw_cfg entries

From: Gabriel Somlo Each fw_cfg entry of type "file" has an associated 56-char, nul-terminated ASCII string which represents its name. While the fw_cfg device doesn't itself impose any specific naming convention, QEMU developers have traditionally used path name semantics (i.e.

[Qemu-devel] [PATCH v4 4/4] devicetree: update documentation for fw_cfg ARM bindings

From: Gabriel Somlo Remove redundant details from Documentation/devicetree/bindings/arm/fw-cfg.txt, and replace them with a pointer to the more comprehensive fw_cfg documentation privided by Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg, leaving the specific ARM DTB node

[Qemu-devel] [PATCH v4 0/4] SysFS driver for QEMU fw_cfg device

From: "Gabriel Somlo" Allow access to QEMU firmware blobs, passed into the guest VM via the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name, size, and fw_cfg key), as well as the raw binary blob data may be accessed. The SysFS access location is

[Qemu-devel] [PATCH v4 2/4] kobject: export kset_find_obj() for module use

From: Gabriel Somlo Signed-off-by: Gabriel Somlo --- lib/kobject.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/kobject.c b/lib/kobject.c index 7cbccd2..90d1be6 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -861,6 +861,7 @@ struct kobject

[Qemu-devel] [PATCH v4 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

ptional) offset of control register + * := (optional) offset of data register + * + * e.g.: + * fw_cfg.ioport=2@0x510:0:1 (the default on x86) + * or + * fw_cfg.mmio=0xA@0x902:8:0 (the default on arm) + */ + +#include +#include +#include +#include +#include

[Qemu-devel] [PATCH v5 2/5] pc: fw_cfg: move ioport base constant to pc.h

Move BIOS_CFG_IOPORT define from pc.c to pc.h, and rename it to FW_CFG_IO_BASE. Cc: Marc Marí Signed-off-by: Gabriel Somlo Reviewed-by: Laszlo Ersek --- hw/i386/pc.c | 5 ++--- include/hw/i386/pc.h | 2 ++ 2 files changed, 4

[Qemu-devel] [PATCH v5 0/6] fw_cfg: spec update, misc. cleanup, optimize read

gt;>- Patch 3/4 additionally removes the now-redundant offset argument >>> from the read callback prototype. >>> >>>- Finally, 4/4 consolidates (non-DMA) reads, minimizing the number >>> of times redundant sanity checks are perfor

[Qemu-devel] [PATCH v5 6/6] fw_cfg: replace ioport data read with generic method

IOPort read access is limited to one byte at a time by fw_cfg_comb_valid(). As such, fw_cfg_comb_read() may safely ignore its size argument (which will always be 1), and simply call its fw_cfg_read() helper function once, returning 8 bits via the least significant byte of a 64-bit return value.

[Qemu-devel] [PATCH v5 2/6] fw_cfg: amend callback behavior spec to once per select

Currently, the fw_cfg internal API specifies that if an item was set up with a read callback, the callback must be run each time a byte is read from the item. This behavior is both wasteful (most items do not have a read callback set), and impractical for bulk transfers (e.g., DMA read). At the

[Qemu-devel] [PATCH v5 4/6] fw_cfg: avoid calculating invalid current entry pointer

When calculating a pointer to the currently selected fw_cfg item, the following is used: FWCfgEntry *e = >entries[arch][s->cur_entry & FW_CFG_ENTRY_MASK]; When s->cur_entry is FW_CFG_INVALID, we are calculating the address of a non-existent element in s->entries[arch][...], which is undefined.

[Qemu-devel] [PATCH v5 3/6] fw_cfg: remove offset argument from callback prototype

Read callbacks are now only invoked at item selection, before any data is read. As such, the value of the offset argument passed to the callback will always be 0. Also, the two callback instances currently in use both leave their offset argument unused. This patch removes the offset argument from

[Qemu-devel] [PATCH v5 5/6] fw_cfg: add generic non-DMA read method

Introduce fw_cfg_data_read(), a generic read method which works on all access widths (1 through 8 bytes, inclusive), and can be used during both IOPort and MMIO read accesses. To maintain legibility, only fw_cfg_data_mem_read() (the MMIO data read method) is replaced by this patch. The new method

[Qemu-devel] [PATCH v5 1/6] fw_cfg: move internal function call docs to header file

Move documentation for fw_cfg functions internal to qemufrom docs/specs/fw_cfg.txt to the fw_cfg.h header file, next to their prototype declarations, formatted as doc-comments. NOTE: Documentation for fw_cfg_add_callback() is completely dropped by this patch, as that function has been eliminated

Re: [Qemu-devel] [PATCH v4 5/6] fw_cfg: add generic non-DMA read method

On Thu, Nov 05, 2015 at 01:23:15PM +0100, Laszlo Ersek wrote: > On 11/04/15 17:35, Gabriel L. Somlo wrote: > > On Wed, Nov 04, 2015 at 04:04:09PM +0100, Laszlo Ersek wrote: > >> On 11/03/15 22:40, Gabriel L. Somlo wrote: > >>> Introduce fw_cfg_data_read(), a g

Re: [Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device

On Mon, Oct 05, 2015 at 03:18:05PM +0200, Paolo Bonzini wrote: > > > On 05/10/2015 14:50, Peter Maydell wrote: > > If you want to try to support "firmware might also be reading > > fw_cfg at the same time as the kernel" this is a (painful) > > problem regardless of how the kernel figures out

Re: [Qemu-devel] [PATCH v4 5/6] fw_cfg: add generic non-DMA read method

On Wed, Nov 04, 2015 at 04:04:09PM +0100, Laszlo Ersek wrote: > On 11/03/15 22:40, Gabriel L. Somlo wrote: > > Introduce fw_cfg_data_read(), a generic read method which works > > on all access widths (1 through 8 bytes, inclusive), and can be > > used during both IOPort a

Re: [Qemu-devel] [PATCH v3 4/5] fw_cfg: add generic non-DMA read method

On Tue, Nov 03, 2015 at 11:53:55AM +0100, Laszlo Ersek wrote: > Thank you for splitting out this patch; it makes it easier to review. > However, > > On 11/03/15 01:35, Gabriel L. Somlo wrote: > > Introduce fw_cfg_data_read(), a generic read method which works > > on all ac

[Qemu-devel] [PATCH v4 2/6] fw_cfg: amend callback behavior spec to once per select

Currently, the fw_cfg internal API specifies that if an item was set up with a read callback, the callback must be run each time a byte is read from the item. This behavior is both wasteful (most items do not have a read callback set), and impractical for bulk transfers (e.g., DMA read). At the

Re: [Qemu-devel] [PATCH v3 4/5] fw_cfg: add generic non-DMA read method

On Tue, Nov 03, 2015 at 10:35:36PM +0100, Laszlo Ersek wrote: > On 11/03/15 18:55, Gabriel L. Somlo wrote: > > On Tue, Nov 03, 2015 at 11:53:55AM +0100, Laszlo Ersek wrote: > >> Thank you for splitting out this patch; it makes it easier to review. > >> However, > >

Re: [Qemu-devel] [PATCH v3 4/5] fw_cfg: add generic non-DMA read method

On Tue, Nov 03, 2015 at 10:35:36PM +0100, Laszlo Ersek wrote: > On 11/03/15 18:55, Gabriel L. Somlo wrote: > > On Tue, Nov 03, 2015 at 11:53:55AM +0100, Laszlo Ersek wrote: > >> Thank you for splitting out this patch; it makes it easier to review. > >> However, > >

[Qemu-devel] [PATCH v4 0/6] fw_cfg: spec update, misc. cleanup, optimize read

Finally, 4/4 consolidates (non-DMA) reads, minimizing the number >> of times redundant sanity checks are performed, particularly for >> wide (> byte) sized reads. Gabriel L. Somlo (6): fw_cfg: move internal function call docs to header file fw_cfg: amend callback

[Qemu-devel] [PATCH v4 1/6] fw_cfg: move internal function call docs to header file

Move documentation for fw_cfg functions internal to qemu from docs/specs/fw_cfg.txt to the fw_cfg.h header file, next to their prototype declarations, formatted as doc-comments. NOTE: Documentation for fw_cfg_add_callback() is completely dropped by this patch, as that function has been eliminated

[Qemu-devel] [PATCH v4 6/6] fw_cfg: replace ioport data read with generic method

IOPort read access is limited to one byte at a time by fw_cfg_comb_valid(). As such, fw_cfg_comb_read() may safely ignore its size argument (which will always be 1), and simply call its fw_cfg_read() helper function once, returning 8 bits via the least significant byte of a 64-bit return value.

[Qemu-devel] [PATCH v4 4/6] fw_cfg: avoid calculating invalid current entry pointer

When calculating a pointer to the currently selected fw_cfg item, the following is used: FWCfgEntry *e = >entries[arch][s->cur_entry & FW_CFG_ENTRY_MASK]; When s->cur_entry is FW_CFG_INVALID, we are calculating the address of a non-existent element in s->entries[arch][...], which is undefined.

[Qemu-devel] [PATCH v4 5/6] fw_cfg: add generic non-DMA read method

Introduce fw_cfg_data_read(), a generic read method which works on all access widths (1 through 8 bytes, inclusive), and can be used during both IOPort and MMIO read accesses. To maintain legibility, only fw_cfg_data_mem_read() (the MMIO data read method) is replaced by this patch. The new method

[Qemu-devel] [PATCH v4 3/6] fw_cfg: remove offset argument from callback prototype

Read callbacks are now only invoked at item selection, before any data is read. As such, the value of the offset argument passed to the callback will always be 0. Also, the two callback instances currently in use both leave their offset argument unused. This patch removes the offset argument from

Re: [Qemu-devel] [PATCH v2 1/4] fw_cfg: move internal function call docs to header file

On Mon, Nov 02, 2015 at 02:41:58PM +0100, Laszlo Ersek wrote: > Three (well, two n' half) comments: > > On 10/28/15 18:20, Gabriel L. Somlo wrote: > > Move documentation for fw_cfg functions internal to qemu from > > docs/specs/fw_cfg.txt to the fw_cfg.h header file, next t

Re: [Qemu-devel] [PATCH v2 2/4] fw_cfg: amend callback behavior spec to once per select

On Mon, Nov 02, 2015 at 03:16:47PM +0100, Laszlo Ersek wrote: > Comments below: > > On 10/28/15 18:20, Gabriel L. Somlo wrote: > > Currently, the fw_cfg internal API specifies that if an item was set up > > with a read callback, the callback must be run each time a byte is r

[Qemu-devel] [PATCH v3 0/5] fw_cfg: spec update, misc. cleanup, optimize read

- Patch 3/4 additionally removes the now-redundant offset argument > from the read callback prototype. > >- Finally, 4/4 consolidates (non-DMA) reads, minimizing the number > of times redundant sanity checks are performed, particularly for > wide

[Qemu-devel] [PATCH v3 4/5] fw_cfg: add generic non-DMA read method

Introduce fw_cfg_data_read(), a generic read method which works on all access widths (1 through 8 bytes, inclusive), and can be used during both IOPort and MMIO read accesses. To maintain legibility, only fw_cfg_data_mem_read() (the MMIO data read method) is replaced by this patch. The new method

[Qemu-devel] [PATCH v3 1/5] fw_cfg: move internal function call docs to header file

Move documentation for fw_cfg functions internal to qemu from docs/specs/fw_cfg.txt to the fw_cfg.h header file, next to their prototype declarations, formatted as doc-comments. NOTE: Documentation for fw_cfg_add_callback() is completely dropped by this patch, as that function has been eliminated

[Qemu-devel] [PATCH v3 5/5] fw_cfg: replace ioport data read with generic method

IOPort read access is limited to one byte at a time by fw_cfg_comb_valid(). As such, fw_cfg_comb_read() may safely ignore its size argument (which will always be 1), and simply call its fw_cfg_read() helper function once, returning 8 bits via the least significant byte of a 64-bit return value.

[Qemu-devel] [PATCH v3 2/5] fw_cfg: amend callback behavior spec to once per select

Currently, the fw_cfg internal API specifies that if an item was set up with a read callback, the callback must be run each time a byte is read from the item. This behavior is both wasteful (most items do not have a read callback set), and impractical for bulk transfers (e.g., DMA read). At the

[Qemu-devel] [PATCH v3 3/5] fw_cfg: remove offset argument from callback prototype

Read callbacks are now only invoked at item selection, before any data is read. As such, the value of the offset argument passed to the callback will always be 0. Also, the two callback instances currently in use both leave their offset argument unused. This patch removes the offset argument from

[Qemu-devel] [PATCH v2 1/4] fw_cfg: move internal function call docs to header file

Move documentation for fw_cfg functions internal to qemu from docs/specs/fw_cfg.txt to the fw_cfg.h header file, next to their prototype declarations, formatted as doc-comments. Suggested-by: Peter Maydell Cc: Laszlo Ersek Cc: Gerd Hoffmann

[Qemu-devel] [PATCH v2 0/4] fw_cfg: spec update, read optimization, misc. cleanup

iel Gabriel L. Somlo (4): fw_cfg: move internal function call docs to header file fw_cfg: amend callback behavior spec to once per select fw_cfg: remove offset argument from callback prototype fw_cfg: streamline (non-DMA) read operations docs/specs/fw_cfg.txt |

[Qemu-devel] [PATCH v2 4/4] fw_cfg: streamline (non-DMA) read operations

Replace fw_cfg_comb_read(), fw_cfg_data_mem_read(), and fw_cfg_read() with a single method, fw_cfg_data_read(), which works on all possible read sizes (single- or multi-byte). The new method also eliminates redundant validity checks caused by multi-byte reads repeatedly invoking the old

[Qemu-devel] [PATCH v2 2/4] fw_cfg: amend callback behavior spec to once per select

Currently, the fw_cfg internal API specifies that if an item was set up with a read callback, the callback must be run each time a byte is read from the item. This behavior is both wasteful (most items do not have a read callback set), and impractical for bulk transfers (e.g., DMA read). At the

[Qemu-devel] [PATCH v2 3/4] fw_cfg: remove offset argument from callback prototype

Read callbacks are now only invoked at item selection, before any data is read. As such, the value of the offset argument passed to the callback will always be 0. Also, the two callback instances currently in use both leave their offset argument unused. This patch removes the offset argument from

Re: [Qemu-devel] [PATCH v3 4/5] Enable fw_cfg DMA interface for ARM

On Tue, Oct 27, 2015 at 01:43:39PM +0100, Laszlo Ersek wrote: > On 10/27/15 12:11, Gerd Hoffmann wrote: > > Hi, > > > >>> My hypothesis (which I guess I'm volunteering to verify, unless we > >>> end up rejecting this immediately as a bad idea, for some reason that > >>> I have missed), is that

Re: [Qemu-devel] [PATCH v3 4/5] Enable fw_cfg DMA interface for ARM

On Mon, Oct 26, 2015 at 02:38:11PM +0100, Laszlo Ersek wrote: > On 10/26/15 13:49, Gabriel L. Somlo wrote: > > On Mon, Oct 26, 2015 at 10:48:08AM +, Stefan Hajnoczi wrote: > >> On Thu, Oct 22, 2015 at 05:22:16PM -0400, Gabriel L. Somlo wrote: > >>> I wa

Re: [Qemu-devel] [PATCH v3 4/5] Enable fw_cfg DMA interface for ARM

On Mon, Oct 26, 2015 at 10:48:08AM +, Stefan Hajnoczi wrote: > On Thu, Oct 22, 2015 at 05:22:16PM -0400, Gabriel L. Somlo wrote: > > I was re-reading the documentation for fw_cfg_add_file_callback(), > > and noticed that non-dma read operations check for the presence &g

Re: [Qemu-devel] [PATCH v3 4/5] Enable fw_cfg DMA interface for ARM

On Sat, 19 Sep 2015, Laszlo Ersek wrote: > Got some good news: with those two fixups in place (register block > size corrected, and dma_enabled set via device property), I could > test the AAVMF / ArmVirtPkg / > patches. > > On my APM Mustang, downloading a decompressed kernel (14,475,776 >

[Qemu-devel] [PATCH] fw_cfg: move internal function call docs to header file

Move documentation for fw_cfg functions internal to qemu from docs/specs/fw_cfg.txt to the fw_cfg.h header file, next to their prototype declarations, formatted as doc-comments. Suggested-by: Peter Maydell Cc: Laszlo Ersek Cc: Gerd Hoffmann

Re: [Qemu-devel] [PATCH v4] fw_cfg: insert string blobs via qemu cmdline

On Thu, Oct 15, 2015 at 05:50:03PM +0200, Laszlo Ersek wrote: > On 10/15/15 11:24, Gerd Hoffmann wrote: > > On Mi, 2015-10-14 at 16:22 +0200, Laszlo Ersek wrote: > >> Paolo, > >> > >> On 09/29/15 18:29, Gabriel L. Somlo wrote: > >>> Allow users

Re: [Qemu-devel] [PATCH v4 3/5] acpi: pc: add fw_cfg device node to ssdt

On Thu, Oct 01, 2015 at 01:33:50PM +0200, Igor Mammedov wrote: > On Thu, 1 Oct 2015 10:27:15 +0200 > Laszlo Ersek <ler...@redhat.com> wrote: > > > On 10/01/15 09:02, Igor Mammedov wrote: > > > On Sun, 27 Sep 2015 17:29:00 -0400 > > > "Gabriel L. Som

Re: [Qemu-devel] [PATCH v3 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

On Tue, Oct 06, 2015 at 10:54:42AM -0700, Andy Lutomirski wrote: > On Sat, Oct 3, 2015 at 4:28 PM, Gabriel L. Somlo <so...@cmu.edu> wrote: > > From: Gabriel Somlo <so...@cmu.edu> > > > > Make fw_cfg entries of type "file" available via sysfs. Entries >

Re: [Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device

On Mon, Oct 05, 2015 at 11:00:36AM +0100, Mark Rutland wrote: > On Sat, Oct 03, 2015 at 07:28:05PM -0400, Gabriel L. Somlo wrote: > > From: "Gabriel Somlo" <so...@cmu.edu> > > > > Allow access to QEMU firmware blobs, passed into the guest VM via > > the

Re: [Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device

On Mon, Oct 05, 2015 at 01:50:47PM +0100, Peter Maydell wrote: > On 5 October 2015 at 13:40, Gabriel L. Somlo <so...@cmu.edu> wrote: > > In addition, Michael's comment earlier in the thread suggests that > > even my current acpi version isn't sufficiently "orthodox"

Re: [Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device

On Mon, Oct 05, 2015 at 01:56:47PM +0100, Mark Rutland wrote: > On Mon, Oct 05, 2015 at 08:43:46AM -0400, Gabriel L. Somlo wrote: > > On Mon, Oct 05, 2015 at 01:23:33PM +0100, Mark Rutland wrote: > > > On Mon, Oct 05, 2015 at 01:48:52PM +0200, Paolo Bonzini wrote: > > >

Re: [Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device

On Mon, Oct 05, 2015 at 01:23:33PM +0100, Mark Rutland wrote: > On Mon, Oct 05, 2015 at 01:48:52PM +0200, Paolo Bonzini wrote: > > > > > > On 05/10/2015 12:00, Mark Rutland wrote: > > > Some of the keys in the example look like they'd come from other sources > > > (e.g. the *-tables entries),

Re: [Qemu-devel] [PATCH v3 2/4] firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver

On Sun, Oct 04, 2015 at 04:24:00PM -0400, Gabriel L. Somlo wrote: > On Sun, Oct 04, 2015 at 10:54:57AM +0300, Michael S. Tsirkin wrote: > > On Sat, Oct 03, 2015 at 07:28:07PM -0400, Gabriel L. Somlo wrote: > > > > > > Instead of blindly probing fw_cfg registe

Re: [Qemu-devel] [PATCH v3 2/4] firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver

On Sun, Oct 04, 2015 at 10:54:57AM +0300, Michael S. Tsirkin wrote: > On Sat, Oct 03, 2015 at 07:28:07PM -0400, Gabriel L. Somlo wrote: > > From: Gabriel Somlo <so...@cmu.edu> > > > > Instead of blindly probing fw_cfg registers at known IOport and MMIO > >

[Qemu-devel] [PATCH v3 2/4] firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver

From: Gabriel Somlo Instead of blindly probing fw_cfg registers at known IOport and MMIO locations, use the ACPI subsystem to determine whether a QEMU fw_cfg device is present, and, if found, to initialize it. This limits portability to architectures which support ACPI (x86 and

[Qemu-devel] [PATCH v3 4/4] firmware: create directory hierarchy for sysfs fw_cfg entries

From: Gabriel Somlo Each fw_cfg entry of type "file" has an associated 56-char, nul-terminated ASCII string which represents its name. While the fw_cfg device doesn't itself impose any specific naming convention, QEMU developers have traditionally used path name semantics (i.e.

[Qemu-devel] [PATCH v3 3/4] kobject: export kset_find_obj() for module use

From: Gabriel Somlo Signed-off-by: Gabriel Somlo --- lib/kobject.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/kobject.c b/lib/kobject.c index 3e3a5c3..bea2c9b 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -842,6 +842,7 @@ struct kobject

[Qemu-devel] [PATCH v3 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

iguration (fw_cfg) device in + * sysfs (read-only, under "/sys/firmware/qemu_fw_cfg/..."). + * + * Copyright 2015 Carnegie Mellon University + */ + +#include +#include +#include +#include + +MODULE_AUTHOR("Gabriel L. Somlo <so...@cmu.edu>"); +MODULE_DESCRIPTION("QEMU f

[Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device

From: "Gabriel Somlo" Allow access to QEMU firmware blobs, passed into the guest VM via the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name, size, and fw_cfg key), as well as the raw binary blob data may be accessed. The SysFS access location is

[Qemu-devel] qemu-system-arm command line question

Hi Rich, On Tue, Jul 14, 2015 at 07:48:30PM +0100, Richard W.M. Jones wrote: > On Tue, Jul 14, 2015 at 02:23:14PM -0400, Gabriel L. Somlo wrote: > > On Tue, Jul 14, 2015 at 10:43:46AM +0100, Richard W.M. Jones wrote: > > > On Mon, Jul 13, 2015 at 04:09:37PM -0400, Gabr

Re: [Qemu-devel] qemu-system-arm command line question

On Fri, Oct 02, 2015 at 07:37:37PM +0100, Richard W.M. Jones wrote: > On Fri, Oct 02, 2015 at 02:15:20PM -0400, Gabriel L. Somlo wrote: > > Trying to adapt the command line used with 32-bit arm, I ran: > > > > bin/qemu-system-aarch64 -M virt,accel=tcg -m 2048 -cpu corte

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

On Wed, Sep 30, 2015 at 02:22:26PM +0200, Laszlo Ersek wrote: > On 09/30/15 13:13, Peter Maydell wrote: > > On 30 September 2015 at 11:21, Laszlo Ersek wrote: > >> However: if Gabriel has no access to actual aarch64 hardware (ie. cannot > >> run KVM guests), then I don't think

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

On Wed, Sep 30, 2015 at 12:21:08PM +0200, Laszlo Ersek wrote: > On 09/30/15 11:59, Ard Biesheuvel wrote: > > On 29 September 2015 at 20:26, Gabriel L. Somlo <so...@cmu.edu> wrote: > >> On Tue, Sep 29, 2015 at 12:40:16PM +0200, Laszlo Ersek wrote: > >>> On 09

Re: [Qemu-devel] [PATCH v4 3/5] acpi: pc: add fw_cfg device node to ssdt

On Thu, Oct 01, 2015 at 01:52:59PM +0200, Laszlo Ersek wrote: > On 10/01/15 13:33, Igor Mammedov wrote: > > On Thu, 1 Oct 2015 10:27:15 +0200 > > Laszlo Ersek <ler...@redhat.com> wrote: > > > >> On 10/01/15 09:02, Igor Mammedov wrote: > >>> On

Re: [Qemu-devel] [PATCH v4 3/5] acpi: pc: add fw_cfg device node to ssdt

On Wed, Sep 30, 2015 at 03:01:13PM +0200, Paolo Bonzini wrote: > > > On 30/09/2015 02:18, Gabriel L. Somlo wrote: > > Yes, we're OK. Throughout it all I *meant* to write 0x0B (bee), but my > > brain sometimes mistakenly makes me write 0x08 (eight) instead. Sorry

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

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 p

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

On Tue, Sep 29, 2015 at 01:27:38PM +0300, 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 no

Re: [Qemu-devel] [PATCH v4 3/5] acpi: pc: add fw_cfg device node to ssdt

On Tue, Sep 29, 2015 at 12:33:40PM +0200, Laszlo Ersek wrote: > On 09/27/15 23:29, Gabriel L. Somlo wrote: > > Add a fw_cfg device node to the ACPI SSDT, on machine types > > pc-*-2.5 and up. While the guest-side BIOS can't utilize > > this information (since it has to

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

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 sinc

Re: [Qemu-devel] [PATCH v4 3/5] acpi: pc: add fw_cfg device node to ssdt

On Tue, Sep 29, 2015 at 06:55:01PM +0200, Laszlo Ersek wrote: > On 09/29/15 18:46, Gabriel L. Somlo wrote: > > On Tue, Sep 29, 2015 at 12:33:40PM +0200, Laszlo Ersek wrote: > >> On 09/27/15 23:29, Gabriel L. Somlo wrote: > >>> Add a fw_cfg device node to the ACPI S

[Qemu-devel] [PATCH v4] fw_cfg: insert string blobs via qemu cmdline

Allow users to provide custom fw_cfg blobs with ascii string payloads specified directly on the qemu command line. Suggested-by: Jordan Justen Suggested-by: Laszlo Ersek Signed-off-by: Gabriel Somlo Reviewd-by: Laszlo Ersek

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

On Tue, Sep 29, 2015 at 12:40:16PM +0200, Laszlo Ersek wrote: > On 09/27/15 23:29, Gabriel L. Somlo wrote: > > Add a fw_cfg device node to the ACPI DSDT. This is mostly > > informational, as the authoritative fw_cfg MMIO region(s) > > are listed in the Device Tree. However,

Re: [Qemu-devel] [PATCH v4 3/5] acpi: pc: add fw_cfg device node to ssdt

On Tue, Sep 29, 2015 at 07:28:39PM +0200, Laszlo Ersek wrote: > On 09/29/15 19:19, Gabriel L. Somlo wrote: > > On Tue, Sep 29, 2015 at 06:55:01PM +0200, Laszlo Ersek wrote: > >> On 09/29/15 18:46, Gabriel L. Somlo wrote: > >>> On Tue, Sep 29, 2015 at 12:33:

Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline

On Mon, Sep 28, 2015 at 03:30:28PM +0200, Laszlo Ersek wrote: > On 09/27/15 00:55, Gabriel L. Somlo wrote: > > Allow users to provide custom fw_cfg blobs with ascii string > > payloads specified directly on the qemu command line. > > > > Suggested-by: Jordan Justen

Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline

On Mon, Sep 28, 2015 at 01:46:33PM -0600, Eric Blake wrote: > On 09/28/2015 07:30 AM, Laszlo Ersek wrote: > > >> > >> +Small enough items may be provided directly as strings on the command > >> +line, using the syntax: > >> + > >> +-fw_cfg [name=],content= > >> + > > > > Please consider

[Qemu-devel] [PATCH v2] fw_cfg: insert string blobs via qemu cmdline

Allow users to provide custom fw_cfg blobs with ascii string payloads specified directly on the qemu command line. Suggested-by: Jordan Justen Suggested-by: Laszlo Ersek Signed-off-by: Gabriel Somlo --- new in v2: - clarify

Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline

On Mon, Sep 28, 2015 at 11:05:32PM +0200, Laszlo Ersek wrote: > On 09/28/15 22:56, Laszlo Ersek wrote: > > On 09/28/15 22:00, Eric Blake wrote: > >> On 09/28/2015 01:51 PM, Gabriel L. Somlo wrote: > >>> On Mon, Sep 28, 2015 at 01:46:33PM -0600, Eric Blake wrote:

[Qemu-devel] [PATCH v3] fw_cfg: insert string blobs via qemu cmdline

Allow users to provide custom fw_cfg blobs with ascii string payloads specified directly on the qemu command line. Suggested-by: Jordan Justen Suggested-by: Laszlo Ersek Signed-off-by: Gabriel Somlo Reviewd-by: Laszlo Ersek

Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline

On Tue, Sep 29, 2015 at 12:08:14AM +0200, Laszlo Ersek wrote: > On 09/28/15 23:45, Gabriel L. Somlo wrote: > > On Mon, Sep 28, 2015 at 11:05:32PM +0200, Laszlo Ersek wrote: > >> On 09/28/15 22:56, Laszlo Ersek wrote: > >>> On 09/28/15 22:00, Eric Blake wrote: > >

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

gt; Also, using scope "\\_SB", based on where fw_cfg shows up in the >>> output of "info qtree". Again, if that's wrong, please point me in >>> the right direction. >>> >>> Re. 3/3 (also mentioned after the commit blurb in the patch itself), &

[Qemu-devel] [PATCH v4 1/5] fw_cfg: expose control register size in fw_cfg.h

Expose the size of the control register (FW_CFG_SIZE, renamed to FW_CFG_CTL_SIZE) in fw_cfg.h. Add comment to fw_cfg_io_realize() pointing out that since the 8-bit data register is always subsumed by the 16-bit control register in the port I/O case, we use the control register width as the *total*

<    1   2   3   4   5   6   7   8   >