Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 09 1月, 2017 9 次提交
  3. 27 12月, 2016 1 次提交
  5. 16 11月, 2016 1 次提交
  7. 28 10月, 2016 2 次提交
  9. 25 10月, 2016 1 次提交
  11. 24 10月, 2016 1 次提交
  13. 18 10月, 2016 1 次提交
  15. 10 10月, 2016 1 次提交
  17. 04 10月, 2016 2 次提交
  19. 14 7月, 2016 1 次提交
    • A
      hw/arm/virt: tcg: adjust MPIDR like KVM · 95eb49c8
      由 Andrew Jones 提交于 
      KVM adjusts the MPIDR of guest vcpus based on the architecture of
the host, 32-bit vs. 64-bit, and, for 64-bit, also on the type of
GIC the guest is using. To be consistent and improve SGI efficiency
we make the same adjustments for TCG as 64-bit KVM hosts. We neglect
to add consistency with 32-bit KVM hosts, as that would reduce SGI
efficiency and KVM is expected to change.

As MPIDR is a system register, and thus guest visible, we only make
adjustments for current and later versioned machines.
Signed-off-by: NAndrew Jones <drjones@redhat.com>
Message-id: 1467378129-23302-3-git-send-email-drjones@redhat.com
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      95eb49c8
  21. 08 7月, 2016 2 次提交
    • I
      arm: virt: Parse cpu_model only once · 09f71b05
      由 Igor Mammedov 提交于 
      Considering that features are converted to global properties and
global properties are automatically applied to every new instance
of created CPU (at object_new() time), there is no point in
parsing cpu_model string every time a CPU created. So move
parsing outside CPU creation loop and do it only once.

Parsing also should be done before any CPU is created so that
features would affect the first CPU a well.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      09f71b05
    • I
      cpu: Use CPUClass->parse_features() as convertor to global properties · 62a48a2a
      由 Igor Mammedov 提交于 
      Currently CPUClass->parse_features() is used to parse -cpu
features string and set properties on created CPU instances.

But considering that features specified by -cpu apply to every
created CPU instance, it doesn't make sense to parse the same
features string for every CPU created. It also makes every target
that cares about parsing features string explicitly call
CPUClass->parse_features() parser, which gets in a way if we
consider using generic device_add for CPU hotplug as device_add
has not a clue about CPU specific hooks.

Turns out we can use global properties mechanism to set
properties on every created CPU instance for a given type. That
way it's possible to convert CPU features into a set of global
properties for CPU type specified by -cpu cpu_model and common
Device.device_post_init() will apply them to CPU of given type
automatically regardless whether it's manually created CPU or CPU
created with help of device_add.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      62a48a2a
  23. 04 7月, 2016 1 次提交
  25. 14 6月, 2016 5 次提交
  27. 09 6月, 2016 1 次提交
  29. 06 6月, 2016 2 次提交
  31. 21 5月, 2016 1 次提交
  33. 12 5月, 2016 1 次提交
  35. 31 3月, 2016 1 次提交
  37. 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
  39. 17 3月, 2016 3 次提交
  41. 04 3月, 2016 2 次提交
    • 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