qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Andrew Jones <drjones@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>"Richard W.M. Jones"
	<rjones@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 4/7] arm: add fw_cfg to "virt" board
Date: Fri, 12 Dec 2014 14:41:39 +0100	[thread overview]
Message-ID: <548AF093.5040708@redhat.com> (raw)
In-Reply-To: <CAFEAcA_HRT_WwunmAhpOpWejxz8tkp8CocZaGiYJAFWfw7Pksw@mail.gmail.com>

On 12/12/14 13:55, Peter Maydell wrote:
> On 9 December 2014 at 01:13, Laszlo Ersek <lersek@redhat.com> wrote:
>> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
>> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
>> board.
>>
>> Because MMIO access is slow on ARM KVM, we enable the guest, with
>> fw_cfg_init_data_memwidth(), to transfer up to 8 bytes with a single
>> access. This has been measured to speed up transfers up to 7.5-fold,
>> relative to single byte data access, on both ARM KVM and x86_64 TCG.
>>
>> The mmio register block of fw_cfg is advertized in the device tree. As
>> base address we pick 0x09020000, which conforms to the comment preceding
>> "a15memmap": it falls in the miscellaneous device I/O range 128MB..256MB,
>> and it is aligned at 64KB. The DTB properties follow the documentation in
>> the Linux source file "Documentation/devicetree/bindings/arm/fw-cfg.txt".
>>
>> fw_cfg automatically exports a number of files to the guest; for example,
>> "bootorder" (see fw_cfg_machine_reset()).
>>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>>     v3:
>>     - enable 8-byte wide access to fw_cfg MMIO data port [Drew]
>>     - expose the exact size of the fused region in the DTB [Peter]
>>     - reorder data register and control register so that we can keep the
>>       region contiguous and still conform to alignment requirements [Laszlo]
>>
>>  hw/arm/virt.c | 21 +++++++++++++++++++++
>>  1 file changed, 21 insertions(+)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 314e55b..274aaae 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -67,8 +67,9 @@ enum {
>>      VIRT_GIC_CPU,
>>      VIRT_UART,
>>      VIRT_MMIO,
>>      VIRT_RTC,
>> +    VIRT_FW_CFG,
>>  };
>>
>>  typedef struct MemMapEntry {
>>      hwaddr base;
>> @@ -106,8 +107,9 @@ static const MemMapEntry a15memmap[] = {
>>      [VIRT_GIC_DIST] =   { 0x08000000, 0x00010000 },
>>      [VIRT_GIC_CPU] =    { 0x08010000, 0x00010000 },
>>      [VIRT_UART] =       { 0x09000000, 0x00001000 },
>>      [VIRT_RTC] =        { 0x09010000, 0x00001000 },
>> +    [VIRT_FW_CFG] =     { 0x09020000, 0x0000000a },
>>      [VIRT_MMIO] =       { 0x0a000000, 0x00000200 },
>>      /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */
>>      /* 0x10000000 .. 0x40000000 reserved for PCI */
>>      [VIRT_MEM] =        { 0x40000000, 30ULL * 1024 * 1024 * 1024 },
>> @@ -518,8 +520,25 @@ static void create_flash(const VirtBoardInfo *vbi)
>>      qemu_fdt_setprop_cell(vbi->fdt, nodename, "bank-width", 4);
>>      g_free(nodename);
>>  }
>>
>> +static void create_fw_cfg(const VirtBoardInfo *vbi)
>> +{
>> +    hwaddr base = vbi->memmap[VIRT_FW_CFG].base;
>> +    hwaddr size = vbi->memmap[VIRT_FW_CFG].size;
>> +    char *nodename;
>> +
>> +    fw_cfg_init_data_memwidth(0, 0, base + 8, base, 8);
> 
> fw_cfg_init_data_memwidth() adds a bunch of FW_CFG keys
> (bootsplash stuff, reboot timeouts, etc). Are you happy that
> they all make sense to export on ARM? (I guess we're already doing
> that on the other non-x86 fw_cfg users.)

Yes, some of those I'm actually happy about (because I can immediately
retrieve them in the firmware, without doing more qemu work); and the
rest doesn't hurt (I might utilize them later on).

> 
> Assuming so,
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> 
> -- PMM
> 

Thanks!
Laszlo

  reply	other threads:[~2014-12-12 13:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-09  1:12 [Qemu-devel] [PATCH v3 0/7] fw_cfg, bootorder, and UEFI+'-kernel' on arm/virt Laszlo Ersek
2014-12-09  1:12 ` [Qemu-devel] [PATCH v3 1/7] fw_cfg: max access size and region size are the same for MMIO data reg Laszlo Ersek
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 2/7] fw_cfg: introduce the "data_memwidth" property Laszlo Ersek
2014-12-12 12:49   ` Peter Maydell
2014-12-12 13:39     ` Laszlo Ersek
2014-12-12 13:41       ` Peter Maydell
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 3/7] fw_cfg: expose the "data_memwidth" prop with fw_cfg_init_data_memwidth() Laszlo Ersek
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 4/7] arm: add fw_cfg to "virt" board Laszlo Ersek
2014-12-12 12:55   ` Peter Maydell
2014-12-12 13:41     ` Laszlo Ersek [this message]
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 5/7] hw/loader: split out load_image_gzipped_buffer() Laszlo Ersek
2014-12-12 13:11   ` Peter Maydell
2014-12-12 13:43     ` Laszlo Ersek
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 6/7] hw/arm: pass pristine kernel image to guest firmware over fw_cfg Laszlo Ersek
2014-12-12 13:20   ` Peter Maydell
2014-12-12 13:52     ` Laszlo Ersek
2014-12-12 13:57       ` Peter Maydell
2014-12-12 14:10         ` Laszlo Ersek
2014-12-12 14:14           ` Richard W.M. Jones
2014-12-12 14:24             ` Laszlo Ersek
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 7/7] hw/arm/virt: enable passing of EFI-stubbed kernel to guest UEFI firmware Laszlo Ersek
2014-12-12 13:20   ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=548AF093.5040708@redhat.com \
    --to=lersek@redhat.com \
    --cc=drjones@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).