qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 4/7] arm: add fw_cfg to "virt" board


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH v3 4/7] arm: add fw_cfg to "virt" board
Date: Fri, 12 Dec 2014 14:41:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

On 12/12/14 13:55, Peter Maydell wrote:
> On 9 December 2014 at 01:13, Laszlo Ersek <address@hidden> 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 <address@hidden>
>> ---
>>
>> 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 <address@hidden>
> 
> -- PMM
> 

Thanks!
Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]