[Qemu-commits] [qemu/qemu] c8d8ef: pc: Rearrange pc_system_firmware_init()'s legacy -...

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: c8d8ef00a121ee7326c87a76cc9f49716ed68917
      
https://github.com/qemu/qemu/commit/c8d8ef00a121ee7326c87a76cc9f49716ed68917
  Author: Markus Armbruster <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M hw/i386/pc_sysfw.c

  Log Message:
  -----------
  pc: Rearrange pc_system_firmware_init()'s legacy -drive loop

The loop does two things: map legacy -drive to properties, and collect
all the backends for use after the loop.  The next patch will factor
out the former for reuse in hw/arm/virt.c.  To make that easier,
rearrange the loop so it does the first thing first, and the second
thing second.

Signed-off-by: Markus Armbruster <address@hidden>
Reviewed-by: Laszlo Ersek <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 2d731dbd5e7173961cd76dc12c939e672cbca2bd
      
https://github.com/qemu/qemu/commit/2d731dbd5e7173961cd76dc12c939e672cbca2bd
  Author: Markus Armbruster <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M hw/block/pflash_cfi01.c
    M hw/i386/pc_sysfw.c
    M include/hw/block/flash.h

  Log Message:
  -----------
  pflash_cfi01: New pflash_cfi01_legacy_drive()

Factored out of pc_system_firmware_init() so the next commit can reuse
it in hw/arm/virt.c.

Signed-off-by: Markus Armbruster <address@hidden>
Reviewed-by: Laszlo Ersek <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>


  Commit: e0561e60f170b220c5d73d185fa8eaa66fa8e6ef
      
https://github.com/qemu/qemu/commit/e0561e60f170b220c5d73d185fa8eaa66fa8e6ef
  Author: Markus Armbruster <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M hw/arm/virt.c
    M include/hw/arm/virt.h

  Log Message:
  -----------
  hw/arm/virt: Support firmware configuration with -blockdev

The ARM virt machines put firmware in flash memory.  To configure it,
you use -drive if=pflash,unit=0,... and optionally -drive
if=pflash,unit=1,...

Why two -drive?  This permits setting up one part of the flash memory
read-only, and the other part read/write.  It also makes upgrading
firmware on the host easier.  Below the hood, we get two separate
flash devices, because we were too lazy to improve our flash device
models to support sector protection.

The problem at hand is to do the same with -blockdev somehow, as one
more step towards deprecating -drive.

We recently solved this problem for x86 PC machines, in commit
ebc29e1beab.  See the commit message for design rationale.

This commit solves it for ARM virt basically the same way: new machine
properties pflash0, pflash1 forward to the onboard flash devices'
properties.  Requires creating the onboard devices in the
.instance_init() method virt_instance_init().  The existing code to
pick up drives defined with -drive if=pflash is replaced by code to
desugar into the machine properties.

There are a few behavioral differences, though:

* The flash devices are always present (x86: only present if
  configured)

* Flash base addresses and sizes are fixed (x86: sizes depend on
  images, mapped back to back below a fixed address)

* -bios configures contents of first pflash (x86: -bios configures ROM
   contents)

* -bios is rejected when first pflash is also configured with -machine
   pflash0=... (x86: bios is silently ignored then)

* -machine pflash1=... does not require -machine pflash0=... (x86: it
   does).

The actual code is a bit simpler than for x86 mostly due to the first
two differences.

Before the patch, all the action is in create_flash(), called from the
machine's .init() method machvirt_init():

    main()
        machine_run_board_init()
            machvirt_init()
                create_flash()
                    create_one_flash() for flash[0]
                        create
                        configure
                            includes obeying -drive if=pflash,unit=0
                        realize
                        map
                        fall back to -bios
                    create_one_flash() for flash[1]
                        create
                        configure
                            includes obeying -drive if=pflash,unit=1
                        realize
                        map
                    update FDT

To make the machine properties work, we need to move device creation
to its .instance_init() method virt_instance_init().

Another complication is machvirt_init()'s computation of
@firmware_loaded: it predicts what create_flash() will do.  Instead of
predicting what create_flash()'s replacement virt_firmware_init() will
do, I decided to have virt_firmware_init() return what it did.
Requires calling it a bit earlier.

Resulting call tree:

    main()
        current_machine = object_new()
            ...
                virt_instance_init()
                    virt_flash_create()
                        virt_flash_create1() for flash[0]
                            create
                            configure: set defaults
                            become child of machine [NEW]
                            add machine prop pflash0 as alias for drive [NEW]
                        virt_flash_create1() for flash[1]
                            create
                            configure: set defaults
                            become child of machine [NEW]
                            add machine prop pflash1 as alias for drive [NEW]
        for all machine props from the command line: machine_set_property()
            ...
                property_set_alias() for machine props pflash0, pflash1
                    ...
                        set_drive() for cfi.pflash01 prop drive
                            this is how -machine pflash0=... etc set
        machine_run_board_init(current_machine);
            virt_firmware_init()
                pflash_cfi01_legacy_drive()
                    legacy -drive if=pflash,unit=0 and =1 [NEW]
                virt_flash_map()
                    virt_flash_map1() for flash[0]
                        configure: num-blocks
                        realize
                        map
                    virt_flash_map1() for flash[1]
                        configure: num-blocks
                        realize
                        map
                fall back to -bios
            virt_flash_fdt()
                update FDT

You have László to thank for making me explain this in detail.

Signed-off-by: Markus Armbruster <address@hidden>
Acked-by: Laszlo Ersek <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: ff3dcf28c0b7a3ac261399c3754bf2f410c2e91e
      
https://github.com/qemu/qemu/commit/ff3dcf28c0b7a3ac261399c3754bf2f410c2e91e
  Author: Peter Maydell <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M hw/arm/raspi.c

  Log Message:
  -----------
  hw/arm/raspi: Diagnose requests for too much RAM

The Raspberry Pi boards have a physical memory map which does
not allow for more than 1GB of RAM. Currently if the user tries
to ask for more then we fail in a confusing way:

$ qemu-system-aarch64 --machine raspi3 -m 8G
Unexpected error in visit_type_uintN() at qapi/qapi-visit-core.c:164:
qemu-system-aarch64: Parameter 'vcram-base' expects uint32_t
Aborted (core dumped)

Catch this earlier and diagnose it with a more friendly message:
$ qemu-system-aarch64 --machine raspi3 -m 8G
qemu-system-aarch64: Requested ram size is too large for this machine: maximum 
is 1GB

Fixes: https://bugs.launchpad.net/qemu/+bug/1794187
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Wainer dos Santos Moschetta <address@hidden>


  Commit: b698e4eef5111e2df7598261b09dcef8249b7ae6
      
https://github.com/qemu/qemu/commit/b698e4eef5111e2df7598261b09dcef8249b7ae6
  Author: Peter Maydell <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M target/arm/cpu.h
    M target/arm/helper.c
    M target/arm/kvm.c
    M target/arm/kvm32.c
    M target/arm/kvm64.c
    M target/arm/machine.c

  Log Message:
  -----------
  arm: Allow system registers for KVM guests to be changed by QEMU code

At the moment the Arm implementations of kvm_arch_{get,put}_registers()
don't support having QEMU change the values of system registers
(aka coprocessor registers for AArch32). This is because although
kvm_arch_get_registers() calls write_list_to_cpustate() to
update the CPU state struct fields (so QEMU code can read the
values in the usual way), kvm_arch_put_registers() does not
call write_cpustate_to_list(), meaning that any changes to
the CPU state struct fields will not be passed back to KVM.

The rationale for this design is documented in a comment in the
AArch32 kvm_arch_put_registers() -- writing the values in the
cpregs list into the CPU state struct is "lossy" because the
write of a register might not succeed, and so if we blindly
copy the CPU state values back again we will incorrectly
change register values for the guest. The assumption was that
no QEMU code would need to write to the registers.

However, when we implemented debug support for KVM guests, we
broke that assumption: the code to handle "set the guest up
to take a breakpoint exception" does so by updating various
guest registers including ESR_EL1.

Support this by making kvm_arch_put_registers() synchronize
CPU state back into the list. We sync only those registers
where the initial write succeeds, which should be sufficient.

This commit is the same as commit 823e1b3818f9b10b824ddc which we
had to revert in commit 942f99c825fc94c8b1a4, except that the bug
which was preventing EDK2 guest firmware running has been fixed:
kvm_arm_reset_vcpu() now calls write_list_to_cpustate().

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Eric Auger <address@hidden>


  Commit: a9df9622bc28ff94bb65e4264ddbf7e600d911dc
      
https://github.com/qemu/qemu/commit/a9df9622bc28ff94bb65e4264ddbf7e600d911dc
  Author: Joel Stanley <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M hw/arm/aspeed.c
    M include/hw/arm/aspeed.h

  Log Message:
  -----------
  arm: aspeed: Set SDRAM size

We currently use Qemu's default of 128MB. As we know how much ram each
machine ships with, make it easier on users by setting a default.

It can still be overridden with -m on the command line.

Signed-off-by: Joel Stanley <address@hidden>
Reviewed-by: Andrew Jeffery <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 48bb55bfaa4e8c4799e0ee3dda3b1dde0e25ef72
      
https://github.com/qemu/qemu/commit/48bb55bfaa4e8c4799e0ee3dda3b1dde0e25ef72
  Author: Cao Jiaxi <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M contrib/libvhost-user/libvhost-user.h
    M include/qemu/compiler.h
    M scripts/cocci-macro-file.h

  Log Message:
  -----------
  QEMU_PACKED: Remove gcc_struct attribute in Windows non x86 targets

gcc_struct is for x86 only, and it generates an warning on ARM64 Clang/MinGW 
targets.

Signed-off-by: Cao Jiaxi <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Message-id: address@hidden
[PMM: dropped the slirp change as slirp is now a submodule]
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 8ac65578920a98a845aa8c80ea19140a51440185
      
https://github.com/qemu/qemu/commit/8ac65578920a98a845aa8c80ea19140a51440185
  Author: Cao Jiaxi <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M qga/commands-win32.c

  Log Message:
  -----------
  qga: Fix mingw compilation warnings on enum conversion

The win2qemu[] is supposed to be the conversion table to convert between
STORAGE_BUS_TYPE in Windows SDK and GuestDiskBusType in qga.

But it was incorrectly written that it forces to set a GuestDiskBusType
value to STORAGE_BUS_TYPE, which generates an enum conversion warning in clang.

Suggested-by: Eric Blake <address@hidden>
Signed-off-by: Cao Jiaxi <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Message-id: address@hidden
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 8041336ef74e19ca607c1601016333c986de8f9c
      
https://github.com/qemu/qemu/commit/8041336ef74e19ca607c1601016333c986de8f9c
  Author: Cao Jiaxi <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M util/cacheinfo.c

  Log Message:
  -----------
  util/cacheinfo: Use uint64_t on LLP64 model to satisfy Windows ARM64

Windows ARM64 uses LLP64 model, which breaks current assumptions.

Signed-off-by: Cao Jiaxi <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Message-id: address@hidden
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 946376c21be1cd9dcc3c7936b204b113781603f7
      
https://github.com/qemu/qemu/commit/946376c21be1cd9dcc3c7936b204b113781603f7
  Author: Cao Jiaxi <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M include/qemu/osdep.h

  Log Message:
  -----------
  osdep: Fix mingw compilation regarding stdio formats

I encountered the following compilation error on mingw:

/mnt/d/qemu/include/qemu/osdep.h:97:9: error: '__USE_MINGW_ANSI_STDIO' macro 
redefined [-Werror,-Wmacro-redefined]
 #define __USE_MINGW_ANSI_STDIO 1
        ^
/mnt/d/llvm-mingw/aarch64-w64-mingw32/include/_mingw.h:433:9: note: previous 
definition is here
 #define __USE_MINGW_ANSI_STDIO 0      /* was not defined so it should be 0 */

It turns out that __USE_MINGW_ANSI_STDIO must be set before any
system headers are included, not just before stdio.h.

Signed-off-by: Cao Jiaxi <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Reviewed-by: Stefan Weil <address@hidden>
Message-id: address@hidden
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: b01e2f0284a2df11aef990219104e3f52c317061
      
https://github.com/qemu/qemu/commit/b01e2f0284a2df11aef990219104e3f52c317061
  Author: Peter Maydell <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M hw/intc/armv7m_nvic.c

  Log Message:
  -----------
  hw/arm/armv7m_nvic: Check subpriority in nvic_recompute_state_secure()

Rule R_CQRV says that if two pending interrupts have the same
group priority then ties are broken by looking at the subpriority.
We had a comment describing this but had forgotten to actually
implement the subpriority comparison. Correct the omission.

(The further tie break rules of "lowest exception number" and
"secure before non-secure" are handled implicitly by the order
in which we iterate through the exceptions in the loops.)

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden


  Commit: 339327b6d4a2830cba230c6be7a17a4a2fc3d546
      
https://github.com/qemu/qemu/commit/339327b6d4a2830cba230c6be7a17a4a2fc3d546
  Author: Peter Maydell <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M hw/intc/armv7m_nvic.c

  Log Message:
  -----------
  hw/intc/armv7m_nvic: NS BFAR and BFSR are RAZ/WI if BFHFNMINS == 0

The non-secure versions of the BFAR and BFSR registers are
supposed to be RAZ/WI if AICR.BFHFNMINS == 0; we were
incorrectly allowing NS code to access the real values.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden


  Commit: a03ffaefce5dbb455ee1bc7c7709faf377dfbd45
      
https://github.com/qemu/qemu/commit/a03ffaefce5dbb455ee1bc7c7709faf377dfbd45
  Author: Peter Maydell <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M hw/intc/armv7m_nvic.c

  Log Message:
  -----------
  hw/intc/armv7m_nvic: Don't enable ARMV7M_EXCP_DEBUG from reset

The M-profile architecture specifies that the DebugMonitor exception
should be initially disabled, not enabled. It should be controlled
by the DEMCR register's MON_EN bit, but we don't implement that
register yet (like most of the debug architecture for M-profile).

Note that BKPT instructions will still work, because they
will be escalated to HardFault.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden


  Commit: f1e2598c46d480c9e21213a244bc514200762828
      
https://github.com/qemu/qemu/commit/f1e2598c46d480c9e21213a244bc514200762828
  Author: Peter Maydell <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M target/arm/cpu.h
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Implement XPSR GE bits

In the M-profile architecture, if the CPU implements the DSP extension
then the XPSR has GE bits, in the same way as the A-profile CPSR. When
we added DSP extension support we forgot to add support for reading
and writing the GE bits, which are stored in env->GE. We did put in
the code to add XPSR_GE to the mask of bits to update in the v7m_msr
helper, but forgot it in v7m_mrs. We also must not allow the XPSR we
pull off the stack on exception return to set the nonexistent GE bits.
Correct these errors:
 * read and write env->GE in xpsr_read() and xpsr_write()
 * only set GE bits on exception return if DSP present
 * read GE bits for MRS if DSP present

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden


  Commit: 63159601fb3e396b28da14cbb71e50ed3f5a0331
      
https://github.com/qemu/qemu/commit/63159601fb3e396b28da14cbb71e50ed3f5a0331
  Author: Peter Maydell <address@hidden>
  Date:   2019-05-07 (Tue, 07 May 2019)

  Changed paths:
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Stop using variable length array in dc_zva

Currently the dc_zva helper function uses a variable length
array. In fact we know (as the comment above remarks) that
the length of this array is bounded because the architecture
limits the block size and QEMU limits the target page size.
Use a fixed array size and assert that we don't run off it.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden


  Commit: 629d166994725773dea9cef843fcb0ae5f3585fe
      
https://github.com/qemu/qemu/commit/629d166994725773dea9cef843fcb0ae5f3585fe
  Author: Peter Maydell <address@hidden>
  Date:   2019-05-08 (Wed, 08 May 2019)

  Changed paths:
    M contrib/libvhost-user/libvhost-user.h
    M hw/arm/aspeed.c
    M hw/arm/raspi.c
    M hw/arm/virt.c
    M hw/block/pflash_cfi01.c
    M hw/i386/pc_sysfw.c
    M hw/intc/armv7m_nvic.c
    M include/hw/arm/aspeed.h
    M include/hw/arm/virt.h
    M include/hw/block/flash.h
    M include/qemu/compiler.h
    M include/qemu/osdep.h
    M qga/commands-win32.c
    M scripts/cocci-macro-file.h
    M target/arm/cpu.h
    M target/arm/helper.c
    M target/arm/kvm.c
    M target/arm/kvm32.c
    M target/arm/kvm64.c
    M target/arm/machine.c
    M util/cacheinfo.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190507' 
into staging

target-arm queue:
 * Stop using variable length array in dc_zva
 * Implement M-profile XPSR GE bits
 * Don't enable ARMV7M_EXCP_DEBUG from reset
 * armv7m_nvic: NS BFAR and BFSR are RAZ/WI if BFHFNMINS == 0
 * armv7m_nvic: Check subpriority in nvic_recompute_state_secure()
 * fix various minor issues to allow building for Windows-on-ARM64
 * aspeed: Set SDRAM size
 * Allow system registers for KVM guests to be changed by QEMU code
 * raspi: Diagnose requests for too much RAM
 * virt: Support firmware configuration with -blockdev

# gpg: Signature made Tue 07 May 2019 12:59:30 BST
# gpg:                using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg:                issuer "address@hidden"
# gpg: Good signature from "Peter Maydell <address@hidden>" [ultimate]
# gpg:                 aka "Peter Maydell <address@hidden>" [ultimate]
# gpg:                 aka "Peter Maydell <address@hidden>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* remotes/pmaydell/tags/pull-target-arm-20190507:
  target/arm: Stop using variable length array in dc_zva
  target/arm: Implement XPSR GE bits
  hw/intc/armv7m_nvic: Don't enable ARMV7M_EXCP_DEBUG from reset
  hw/intc/armv7m_nvic: NS BFAR and BFSR are RAZ/WI if BFHFNMINS == 0
  hw/arm/armv7m_nvic: Check subpriority in nvic_recompute_state_secure()
  osdep: Fix mingw compilation regarding stdio formats
  util/cacheinfo: Use uint64_t on LLP64 model to satisfy Windows ARM64
  qga: Fix mingw compilation warnings on enum conversion
  QEMU_PACKED: Remove gcc_struct attribute in Windows non x86 targets
  arm: aspeed: Set SDRAM size
  arm: Allow system registers for KVM guests to be changed by QEMU code
  hw/arm/raspi: Diagnose requests for too much RAM
  hw/arm/virt: Support firmware configuration with -blockdev
  pflash_cfi01: New pflash_cfi01_legacy_drive()
  pc: Rearrange pc_system_firmware_init()'s legacy -drive loop

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/a6f6d24757a7...629d16699472