Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 12 6月, 2018 4 次提交
  3. 08 6月, 2018 1 次提交
  5. 02 6月, 2018 1 次提交
  7. 01 6月, 2018 2 次提交
  9. 29 5月, 2018 1 次提交
  11. 20 5月, 2018 1 次提交
  13. 11 5月, 2018 2 次提交
  15. 08 5月, 2018 1 次提交
    • G
      ppc: e500: use g_strdup_printf() instead of snprintf() · 2fb513d3
      由 Greg Kurz 提交于 
      qemu-system-ppc fails to build with GCC 8.0.1:

/home/hsp/src/qemu-master/hw/ppc/e500.c: In function ‘ppce500_load_device_tree’:
/home/hsp/src/qemu-master/hw/ppc/e500.c:442:37: error: ‘/pic@’
directive output may be truncated writing 5 bytes into a region of
size between 1 and 128 [-Werror=format-truncation=]
     snprintf(mpic, sizeof(mpic), "%s/pic@%llx", soc, MPC8544_MPIC_REGS_OFFSET);
                                     ^~~~~
In file included from /usr/include/stdio.h:862,
                 from /home/hsp/src/qemu-master/include/qemu/osdep.h:68,
                 from /home/hsp/src/qemu-master/hw/ppc/e500.c:17:
/usr/include/bits/stdio2.h:64:10: note: ‘__builtin___snprintf_chk’
output between 11 and 138 bytes into a destination of size 128
   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        __bos (__s), __fmt, __va_arg_pack ());
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/hsp/src/qemu-master/hw/ppc/e500.c:470:39: error:
‘/global-utilities@’ directive output may be truncated writing 18
bytes into a region of size between 1 and 128
[-Werror=format-truncation=]
     snprintf(gutil, sizeof(gutil), "%s/global-utilities@%llx", soc,
                                       ^~~~~~~~~~~~~~~~~~
In file included from /usr/include/stdio.h:862,
                 from /home/hsp/src/qemu-master/include/qemu/osdep.h:68,
                 from /home/hsp/src/qemu-master/hw/ppc/e500.c:17:
/usr/include/bits/stdio2.h:64:10: note: ‘__builtin___snprintf_chk’
output between 24 and 151 bytes into a destination of size 128
   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        __bos (__s), __fmt, __va_arg_pack ());
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/hsp/src/qemu-master/hw/ppc/e500.c:477:36: error: ‘/msi@’
directive output may be truncated writing 5 bytes into a region of
size between 0 and 127 [-Werror=format-truncation=]
     snprintf(msi, sizeof(msi), "/%s/msi@%llx", soc, MPC8544_MSI_REGS_OFFSET);
                                    ^~~~~
In file included from /usr/include/stdio.h:862,
                 from /home/hsp/src/qemu-master/include/qemu/osdep.h:68,
                 from /home/hsp/src/qemu-master/hw/ppc/e500.c:17:
/usr/include/bits/stdio2.h:64:10: note: ‘__builtin___snprintf_chk’
output between 12 and 139 bytes into a destination of size 128
   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        __bos (__s), __fmt, __va_arg_pack ());
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fix this by converting e500 to use g_strdup_printf()+g_free() instead
of snprintf(). This is done globally, even for call sites that don't
break build, since this is the preferred practice in QEMU.
Reported-by: NHoward Spoelstra <hsp.cat7@gmail.com>
Signed-off-by: NGreg Kurz <groug@kaod.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 152568372989.443627.900708381919207053.stgit@bahia.lan
Cc: qemu-stable@nongnu.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      2fb513d3
  17. 07 5月, 2018 6 次提交
  19. 04 5月, 2018 14 次提交
    • M
      qobject: Replace qobject_incref/QINCREF qobject_decref/QDECREF · cb3e7f08
      由 Marc-André Lureau 提交于 
      Now that we can safely call QOBJECT() on QObject * as well as its
subtypes, we can have macros qobject_ref() / qobject_unref() that work
everywhere instead of having to use QINCREF() / QDECREF() for QObject
and qobject_incref() / qobject_decref() for its subtypes.

The replacement is mechanical, except I broke a long line, and added a
cast in monitor_qmp_cleanup_req_queue_locked().  Unlike
qobject_decref(), qobject_unref() doesn't accept void *.

Note that the new macros evaluate their argument exactly once, thus no
need to shout them.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-Id: <20180419150145.24795-4-marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
[Rebased, semantic conflict resolved, commit message improved]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      cb3e7f08
    • G
      spapr: don't advertise radix GTSE if max-compat-cpu < power9 · 0550b120
      由 Greg Kurz 提交于 
      On a POWER9 host, if a guest runs in pre POWER9 compat mode, it necessarily
uses the hash MMU mode. In this case, we shouldn't advertise radix GTSE in
the ibm,arch-vec-5-platform-support DT property as the current code does.
The first reason is that it doesn't make sense, and the second one is that
causes the CAS-negotiated options subsection to be migrated. This breaks
backward migration to QEMU 2.7 and older versions on POWER8 hosts:

qemu-system-ppc64: error while loading state for instance 0x0 of device
 'spapr'
qemu-system-ppc64: load of migration failed: No such file or directory

This patch hence initialize CPUs a bit earlier so that we can check the
requested compat mode, and don't set OV5_MMU_RADIX_GTSE for power8 and
older.
Signed-off-by: NGreg Kurz <groug@kaod.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      0550b120
    • G
      spapr: don't migrate "spapr_option_vector_ov5_cas" to pre 2.8 machines · aef19c04
      由 Greg Kurz 提交于 
      a324d6f1 "spapr: Support ibm,dynamic-memory-v2 property" added
a new feature in the set of CAS-negotiatable options. This causes
the CAS-negotiated options subsection to be migrated, even for old
machine types that don't know about it, and breaks backward migration
to QEMU 2.7 and older versions:

qemu-system-ppc64: error while loading state for instance 0x0 of device
 'spapr'
qemu-system-ppc64: load of migration failed: No such file or directory

Since this feature only affects boot time behaviour, it should be
filtered out when we decide to migrate CAS-negotiated options, like
we already do with OV5_FORM1_AFFINITY and OV5_DRCONF_MEMORY.
Signed-off-by: NGreg Kurz <groug@kaod.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      aef19c04
    • M
      mac_newworld: move wiring of macio IRQs to macio_newworld_realize() · 0fcd2a81
      由 Mark Cave-Ayland 提交于 
      Since the macio device has a link to the PIC device, we can now wire up the
IRQs directly via qdev GPIOs rather than having to use an intermediate array.
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      0fcd2a81
    • M
      mac_newworld: remove pics IRQ array and wire up macio to OpenPIC directly · 040b27c0
      由 Mark Cave-Ayland 提交于 
      Introduce constants for the pre-defined New World IRQs to help keep things
readable.
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      040b27c0
    • M
      uninorth: create new uninorth device · 0662946a
      由 Mark Cave-Ayland 提交于 
      Commit 4e46dcdb "PPC: Newworld: Add uninorth token register" added a TODO
which was to convert the uninorth registers hack to a proper device. Move
these registers to a new uninorth device, removing the old hacks from
mac_newworld.c.
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      0662946a
    • D
      spapr: Clean up handling of LPCR power-saving exit bits · 47a9b551
      由 David Gibson 提交于 
      To prevent spurious wakeups on cpus that are supposed to be disabled, we
need to clear the LPCR bits which control certain wakeup events.
spapr_cpu_reset() has separate cases here for boot and non-boot (initially
inactive) cpus.  rtas_start_cpu() then turns the LPCR bits on when the
non-boot cpus are activated.

But explicit checks against first_cpu are not how we usually do things:
instead spapr_cpu_reset() generally sets things up for non-boot (inactive)
cpus, then spapr_machine_reset() and/or rtas_start_cpu() override as
necessary.

So, do that instead.  Because the LPCR activation is identical for boot
cpus and non-boot cpus just activated with rtas_start_cpu() we can put the
code common in spapr_cpu_set_entry_state().
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Tested-by: NCédric Le Goater <clg@kaod.org>
      47a9b551
    • D
      spapr: Move PAPR mode cpu setup fully to spapr code · da20aed1
      由 David Gibson 提交于 
      cpu_ppc_set_papr() does several things:
    1) it sets up the virtual hypervisor interface
    2) it prevents the cpu from ever entering hypervisor mode
    3) it tells KVM that we're emulating a cpu in PAPR mode
and 4) it configures the LPCR and AMOR (hypervisor privileged registers)
       so that TCG will behave correctly for PAPR guests, without
       attempting to emulate the cpu in hypervisor mode

(1) & (2) make sense for any virtual hypervisor (if another one ever
exists).

(3) belongs more properly in the machine type specific to a PAPR guest, so
move it to spapr_cpu_init().  While we're at it, remove an ugly test on
kvm_enabled() by making kvmppc_set_papr() a safe no-op on non-KVM.

(4) also belongs more properly in the machine type specific code.  (4) is
done by mangling the default values of the SPRs, so that they will be set
correctly at reset time.  Manipulating usually-static parameters of the cpu
model like this is kind of ugly, especially since the values used really
have more to do with the platform than the cpu.

The spapr code already has places for PAPR specific initializations of
register state in spapr_cpu_reset(), so move this handling there.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Tested-by: NCédric Le Goater <clg@kaod.org>
      da20aed1
    • D
      target/ppc: Delay initialization of LPCR_UPRT for secondary cpus · f00bed95
      由 David Gibson 提交于 
      In cpu_ppc_set_papr() the UPRT and GTSE bits of the LPCR default value are
initialized based on on ppc64_radix_guest().  Which seems reasonable,
except that ppc64_radix_guest() is based on spapr->patb_entry which is
only set up in spapr_machine_reset, called _after_ cpu_ppc_set_papr() for
boot cpus.  Well, and the fact that modifying the SPR default value for an
instance rather than a class is kind of yucky.

The initialization here is really only necessary or valid for
hotplugged cpus; the base cpu initialization already sets a value
that's good enough for the boot cpus until the guest uses an hcall to
configure it's preferred MMU mode.

So, move this initialization to the rtas_start_cpu() path, at which point
ppc64_radix_guest() will have a sensible value, to make sure secondary cpus
come up in an MMU mode matching the existing cpus.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Tested-by: NCédric Le Goater <clg@kaod.org>
      f00bed95
    • D
      spapr: Clean up LPCR updates from hypercalls · 295b6c26
      由 David Gibson 提交于 
      There are several places in spapr_hcall.c where we need to update the LPCR
value on all CPUs.  We do this with the set_spr() helper.  That's not
really correct because this directly sets the SPR value, without going
through the ppc_store_lpcr() helper which may need to update state based
on the LPCR change.

In fact, set_spr() is only ever used for the LPCR, so replace it with an
explicit LPCR updated which uses the right low-level helper.  While we're
there, move the CPU_FOREACH() which was in every one of the callers into
the new helper: set_all_lpcrs().
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Tested-by: NCédric Le Goater <clg@kaod.org>
      295b6c26
    • D
      spapr: Make a helper to set up cpu entry point state · 84369f63
      由 David Gibson 提交于 
      Under PAPR, only the boot CPU is active when the system starts.  Other cpus
must be explicitly activated using an RTAS call.  The entry state for the
boot and secondary cpus isn't identical, but it has some things in common.
We're going to add a bit more common setup later, too, so to simplify
make a helper which sets up the common entry state for both boot and
secondary cpu threads.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NCédric Le Goater <clg@kaod.org>
Tested-by: NCédric Le Goater <clg@kaod.org>
Reviewed-by: NGreg Kurz <groug@kaod.org>
      84369f63
    • D
      spapr: Remove unhelpful helpers from rtas_start_cpu() · 98248918
      由 David Gibson 提交于 
      rtas_start_cpu() calls spapr_cpu_update_tb_offset() and
spapr_cpu_set_endianness() to initialize certain things in the new cpu's
state.  This is the only caller of those helpers, and they're each only
a few lines long, so we might as well just fold them into the caller.

In addition, those helpers initialize state on the new cpu to match that of
the first cpu.  That will generally work, but might be at least logically
incorrect if the first cpu has been set offline by the guest.  So, instead
base the state on that of the cpu invoking the RTAS call, which is
obviously active already.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Tested-by: NCédric Le Goater <clg@kaod.org>
Reviewed-by: NGreg Kurz <groug@kaod.org>
      98248918
    • D
      spapr: Clean up rtas_start_cpu() & rtas_stop_self() · cf116ad4
      由 David Gibson 提交于 
      This makes several minor cleanups to these functions:
  * Follow usual convention of an early exit on error, rather than having
    most of the body in an if
  * Clearer naming of cpu and cpu_.  Now callcpu is the cpu from which the
    RTAS call is invoked, newcpu is the cpu which we're starting
  * Use cpu_synchronize_state() instead of kvm_cpu_synchronize_state()
    directly
  * Remove pointless comment describing what cpu_synchronize_state() does
  * Use ppc_store_lpcr() instead of directly writing the register field
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Tested-by: NCédric Le Goater <clg@kaod.org>
Reviewed-by: NGreg Kurz <groug@kaod.org>
      cf116ad4
    • D
      spapr: Remove support for explicitly allocated RMAs · 090052aa
      由 David Gibson 提交于 
      Current POWER cpus allow for a VRMA, a special mapping which describes a
guest's view of memory when in real mode (MMU off, from the guest's point
of view).  Older cpus didn't have that which meant that to support a guest
a special host-contiguous region of memory was needed to give the guest its
Real Mode Area (RMA).

KVM used to provide special calls to allocate a contiguous RMA for those
cases.  This was useful in the early days of KVM on Power to allow it to be
tested on PowerPC 970 chips as used in Macintosh G5 machines.  Now, those
machines are so old as to be almost irrelevant.

The normal qemu deprecation process would require this to be marked
deprecated then removed in 2 releases.  However, this can only be used
with corresponding support in the host kernel - which was dropped
years ago (in c17b98cf "KVM: PPC: Book3S HV: Remove code for PPC970
processors" of 2014-12-03 to be precise).  Therefore it should be ok
to drop this immediately.

Just to be clear this only affects *KVM HV* guests with PowerPC 970,
and those already require an ancient host kernel.  TCG and KVM PR
guests with PowerPC 970 should still work.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Acked-by: NThomas Huth <thuth@redhat.com>
      090052aa
  21. 27 4月, 2018 7 次提交