Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 04 3月, 2016 4 次提交
    • 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
  3. 03 3月, 2016 1 次提交
  5. 01 3月, 2016 11 次提交
  7. 29 2月, 2016 1 次提交
  9. 28 2月, 2016 8 次提交
  11. 26 2月, 2016 5 次提交
  13. 25 2月, 2016 10 次提交