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
next prev parent 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).