Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 12 5月, 2016 1 次提交
  3. 31 3月, 2016 1 次提交
  5. 23 3月, 2016 1 次提交
    • M
      include/qemu/osdep.h: Don't include qapi/error.h · da34e65c
      由 Markus Armbruster 提交于 
      Commit 57cb38b3 included qapi/error.h into qemu/osdep.h to get the
Error typedef.  Since then, we've moved to include qemu/osdep.h
everywhere.  Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h.  That's in excess of
100KiB of crap most .c files don't actually need.

Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h.  Include qapi/error.h in .c files that need it and don't
get it now.  Include qapi-types.h in qom/object.h for uint16List.

Update scripts/clean-includes accordingly.  Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h.  Update the list of includes in the qemu/osdep.h
comment quoted above similarly.

This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third.  Unfortunately, the number depending on
qapi-types.h shrinks only a little.  More work is needed for that one.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      da34e65c
  7. 17 3月, 2016 3 次提交
  9. 04 3月, 2016 5 次提交
    • 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
      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
      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
  11. 11 2月, 2016 1 次提交
  13. 21 1月, 2016 3 次提交
  15. 19 1月, 2016 1 次提交
  17. 13 1月, 2016 1 次提交
  19. 12 1月, 2016 1 次提交
  21. 17 12月, 2015 3 次提交
  23. 10 11月, 2015 1 次提交
  25. 27 10月, 2015 1 次提交
    • A
      hw/arm/virt: don't use a15memmap directly · 4b280b72
      由 Andrew Jones 提交于 
      We should always go through VirtBoardInfo when we need the memmap.
To avoid using a15memmap directly, in this case, we need to defer
the max-cpus check from class init time to instance init time. In
class init we now use MAX_CPUMASK_BITS for max_cpus initialization,
which is the maximum QEMU supports, and also, incidentally, the
maximum KVM/gicv3 currently supports. Also, a nice side-effect of
delaying the max-cpus check is that we now get more appropriate
error messages for gicv2 machines that try to configure more than
123 cpus. Before this patch it would complain that the requested
number of cpus was greater than 123, but for gicv2 configs, it
should complain that the number is greater than 8.
Signed-off-by: NAndrew Jones <drjones@redhat.com>
Message-id: 1445189728-860-3-git-send-email-drjones@redhat.com
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      4b280b72
  27. 19 10月, 2015 2 次提交
  29. 16 10月, 2015 2 次提交
  31. 24 9月, 2015 1 次提交
  33. 19 9月, 2015 2 次提交
  35. 09 9月, 2015 2 次提交
  37. 07 9月, 2015 3 次提交
  39. 13 8月, 2015 4 次提交
  41. 26 6月, 2015 1 次提交
    • P
      hw/arm/virt: Make block devices default to virtio · 4e2c0b2a
      由 Peter Maydell 提交于 
      Now we have virtio-pci, we can make the virt board's default block
device type be IF_VIRTIO. This allows users to use simplified
command lines that don't have to explicitly create virtio-pci-blk
devices; the -hda &c very short options now also work.

This means we also need to set no_cdrom to avoid getting a
default cdrom device -- this is needed because the virtio-blk
device will fail if it is connected to a block backend with
no media, which is what the default cdrom device typically is.
Providing a cdrom with media via -cdrom will succeed, but silently
create a device with non-removable medium. this is probably
not really what the user wants, but is the best we can do now.

Note that this change means that some command lines which used
to work (by accident) will stop working. Where a drive was connected
manually to a device but without 'if=none' being specified, we
used to treat this as an IDE drive, which we would then not autoplug
because the board doesn't support IDE. Now we will treat it as a
virtio disk and autoplug it, which means the attempt to use the
drive manually will fail:
  qemu-system-arm: -drive file=img.qcow2,id=foo: Drive 'foo' is already
  in use because it has been automatically connected to another device
  (did you need 'if=none' in the drive options?)
The command line will have to be changed to include 'if=none', as the
error message suggests.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Message-id: 1435068107-12594-4-git-send-email-peter.maydell@linaro.org
      4e2c0b2a