Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 04 3月, 2016 9 次提交
    • P
      hw/arm/virt: Assume EL3 boot rom will handle PSCI if one is provided · 4824a61a
      由 Peter Maydell 提交于 
      If the user passes us an EL3 boot rom, then it is going to want to
implement the PSCI interface itself. In this case, disable QEMU's
internal PSCI implementation so it does not get in the way, and
instead start all CPUs in an SMP configuration at once (the boot
rom will catch them all and pen up the secondaries until needed).
The boot rom code is also responsible for editing the device tree
to include any necessary information about its own PSCI implementation
before eventually passing it to a NonSecure guest.

(This "start all CPUs at once" approach is what both ARM Trusted
Firmware and UEFI expect, since it is what the ARM Foundation Model
does; the other approach would be to provide some emulated hardware
for "start the secondaries" but this is simplest.)

This is a compatibility break, but I don't believe that anybody
was using a secure boot ROM with an SMP configuration. Such a setup
would be somewhat broken since there was nothing preventing nonsecure
guest code from calling the QEMU PSCI function to start up a secondary
core in a way that completely bypassed the secure world.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Message-id: 1456853976-7592-1-git-send-email-peter.maydell@linaro.org
      4824a61a
    • P
      hw/arm/virt: Make first flash device Secure-only if booting secure · 738a5d9f
      由 Peter Maydell 提交于 
      If the virt board is started with the 'secure' property set to
request a Secure setup, then make the first flash device be
visible only to the Secure world.

This is a breaking change, but I don't expect it to be noticed
by anybody, because running TZ-aware guests isn't common and
those guests are generally going to be booting from the flash
and implicitly expecting their Non-secure guests to not touch it.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1455288361-30117-5-git-send-email-peter.maydell@linaro.org
      738a5d9f
    • P
      hw/arm/virt: Load bios image to MemoryRegion, not physaddr · 16f4a8dc
      由 Peter Maydell 提交于 
      If we're loading a BIOS image into the first flash device,
load it into the flash's memory region specifically, not
into the physical address where the flash resides. This will
make a difference when the flash might be in the Secure
address space rather than the Nonsecure one.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1455288361-30117-4-git-send-email-peter.maydell@linaro.org
      16f4a8dc
    • P
      loader: Add load_image_mr() to load ROM image to a MemoryRegion · 76151cac
      由 Peter Maydell 提交于 
      Add a new function load_image_mr(), which behaves like
load_image_targphys() except that it loads the ROM image to
a specified MemoryRegion rather than to a specified physical
address. This is useful when a ROM blob needs to be loaded
to a particular flash or ROM device but the address of that
device in the machine's address space is not known. (For
instance, ROMs in devices, or ROMs which might exist in
a different address space to the system address space.)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1455288361-30117-3-git-send-email-peter.maydell@linaro.org
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      76151cac
    • P
      hw/arm/virt: Provide a secure-only RAM if booting in Secure mode · 83ec1923
      由 Peter Maydell 提交于 
      If we're booting in Secure mode, provide a secure-only RAM
(just 16MB) so that secure firmware has somewhere to run
from that won't be accessible to the Non-secure guest.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1455288361-30117-2-git-send-email-peter.maydell@linaro.org
      83ec1923
    • P
      sdhci: Implement DeviceClass reset · 8b41c305
      由 Peter Maydell 提交于 
      The sdhci device was missing a DeviceClass reset method;
implement it. Poweron reset looks the same as reset commanded
by the guest via the device registers, apart from modelling of
the rpi 'pending insert interrupt on powerup' quirk.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAndrew Baumann <Andrew.Baumann@microsoft.com>
Message-id: 1456493044-10025-3-git-send-email-peter.maydell@linaro.org
      8b41c305
    • P
      sd.c: Handle NULL block backend in sd_get_inserted() · 0719e71e
      由 Peter Maydell 提交于 
      The sd.c SD card emulation code can be in a state where the
SDState BlockBackend pointer is NULL; this is treated as
"card not present". Add a missing check to sd_get_inserted()
so that we don't segfault in this situation.

(This could be provoked by the guest writing to the SDHCI
register to do a reset on a xilinx-zynq-a9 board; it will
also happen at startup when sdhci implements its DeviceClass
reset method.)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Message-id: 1456493044-10025-2-git-send-email-peter.maydell@linaro.org
      0719e71e
    • P
      virt: Lift the maximum RAM limit from 30GB to 255GB · 71c27684
      由 Peter Maydell 提交于 
      The virt board restricts guests to only 30GB of RAM. This is a
hangover from the vexpress-a15 board, and there's no inherent reason
for it. 30GB is smaller than you might reasonably want to provision
a VM for on a beefy server machine. Raise the limit to 255GB.

We choose 255GB because the available space we currently have
below the 1TB boundary is up to the 512GB mark, but we don't
want to paint ourselves into a corner by assigning it all to
RAM. So we make half of it available for RAM, with the 256GB..512GB
range available for future non-RAM expansion purposes.

If we need to provide more RAM to VMs in the future then we need to:
 * allocate a second bank of RAM starting at 2TB and working up
 * fix the DT and ACPI table generation code in QEMU to correctly
   report two split lumps of RAM to the guest
 * fix KVM in the host kernel to allow guests with >40 bit address spaces

The last of these is obviously the trickiest, but it seems
reasonable to assume that anybody configuring a VM with a quarter
of a terabyte of RAM will be doing it on a host with more than a
terabyte of physical address space.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
Tested-by: NWei Huang <wei@redhat.com>
Message-id: 1456402182-11651-1-git-send-email-peter.maydell@linaro.org
      71c27684
    • P
      target-arm: Correct handling of writes to CPSR mode bits from gdb in usermode · 8c4f0eb9
      由 Peter Maydell 提交于 
      In helper.c the expression
  (env->uncached_cpsr & CPSR_M) != CPSR_USER
is always true; the right hand side was supposed to be ARM_CPU_MODE_USR
(an error in commit cb01d391).

Since the incorrect expression was always true, this just meant that
commit cb01d391 had no effect.

However simply changing the RHS here would reveal a logic error: if
the mode is USR we wish to completely ignore the attempt to set the
mode bits, which means that we must clear the CPSR_M bits from mask
to avoid the uncached_cpsr bits being updated at the end of the
function.

Move the condition into the correct place in the code, fix its RHS
constant, and add a comment about the fact that we must be doing a
gdbstub write if we're in user mode.

Fixes: https://bugs.launchpad.net/qemu/+bug/1550503Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NSergey Fedorov <serge.fdrv@gmail.com>
Message-id: 1456764438-30015-1-git-send-email-peter.maydell@linaro.org
      8c4f0eb9
  3. 03 3月, 2016 7 次提交
  5. 01 3月, 2016 24 次提交