It is not a part of standard time.h. Glibc put it under
time.h however musl treat it as a sys timex extension.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20210118063808.12471-2-jiaxun.yang@flygoat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Prior to 2a4b472c3c, sys/signal.h was only included on OpenBSD
(apart from two .c files). The POSIX standard location for this
header is just <signal.h> and in fact, OpenBSD's signal.h includes
sys/signal.h itself.
Unconditionally including <sys/signal.h> on musl causes warnings
for just about every source file:
/usr/include/sys/signal.h:1:2: warning: #warning redirecting incorrect #include <sys/signal.h> to <signal.h> [-Wcpp]
1 | #warning redirecting incorrect #include <sys/signal.h> to <signal.h>
| ^~~~~~~
Since there don't seem to be any platforms which require including
<sys/signal.h> in addition to <signal.h>, and some platforms like
Haiku lack it completely, just remove it.
Tested building on OpenBSD after removing this include.
Signed-off-by: Michael Forney <mforney@mforney.org>
Tested-by: John Snow <jsnow@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20210113215600.16100-1-mforney@mforney.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
When we first converted our documentation to Sphinx, we split it into
multiple manuals (system, interop, tools, etc), which are all built
separately. The primary driver for this was wanting to be able to
avoid shipping the 'devel' manual to end-users. However, this is
working against the grain of the way Sphinx wants to be used and
causes some annoyances:
* Cross-references between documents become much harder or
possibly impossible
* There is no single index to the whole documentation
* Within one manual there's no links or table-of-contents info
that lets you easily navigate to the others
* The devel manual doesn't get published on the QEMU website
(it would be nice to able to refer to it there)
Merely hiding our developer documentation from end users seems like
it's not enough benefit for these costs. Combine all the
documentation into a single manual (the same way that the readthedocs
site builds it) and install the whole thing. The previous manual
divisions remain as the new top level sections in the manual.
* The per-manual conf.py files are no longer needed
* The man_pages[] specifications previously in each per-manual
conf.py move to the top level conf.py
* docs/meson.build logic is simplified as we now only need to run
Sphinx once for the HTML and then once for the manpages5B
* The old index.html.in that produced the top-level page with
links to each manual is no longer needed
Unfortunately this means that we now have to build the HTML
documentation into docs/manual in the build tree rather than directly
into docs/; otherwise it is too awkward to ensure we install only the
built manual and not also the dependency info, stamp file, etc. The
manual still ends up in the same place in the final installed
directory, but anybody who was consulting documentation from within
the build tree will have to adjust where they're looking.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20210115154449.4801-1-peter.maydell@linaro.org
When building with GCC 10.2 configured with --extra-cflags=-Os, we get:
target/arm/m_helper.c: In function ‘arm_v7m_cpu_do_interrupt’:
target/arm/m_helper.c:1811:16: error: ‘restore_s16_s31’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
1811 | if (restore_s16_s31) {
| ^
target/arm/m_helper.c:1350:10: note: ‘restore_s16_s31’ was declared here
1350 | bool restore_s16_s31;
| ^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Initialize the 'restore_s16_s31' variable to silence the warning.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20210119062739.589049-1-f4bug@amsat.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The adc_qom_set function didn't free "response", which caused an indirect
memory leak. So use qobject_unref() to fix it.
ASAN shows memory leak stack:
Indirect leak of 593280 byte(s) in 144 object(s) allocated from:
#0 0x7f9a5e7e8d4e in __interceptor_calloc (/lib64/libasan.so.5+0x112d4e)
#1 0x7f9a5e607a50 in g_malloc0 (/lib64/libglib-2.0.so.0+0x55a50)
#2 0x55b1bebf636b in qdict_new ../qobject/qdict.c:30
#3 0x55b1bec09699 in parse_object ../qobject/json-parser.c:318
#4 0x55b1bec0b2df in parse_value ../qobject/json-parser.c:546
#5 0x55b1bec0b6a9 in json_parser_parse ../qobject/json-parser.c:580
#6 0x55b1bec060d1 in json_message_process_token ../qobject/json-streamer.c:92
#7 0x55b1bec16a12 in json_lexer_feed_char ../qobject/json-lexer.c:313
#8 0x55b1bec16fbd in json_lexer_feed ../qobject/json-lexer.c:350
#9 0x55b1bec06453 in json_message_parser_feed ../qobject/json-streamer.c:121
#10 0x55b1bebc2d51 in qmp_fd_receive ../tests/qtest/libqtest.c:614
#11 0x55b1bebc2f5e in qtest_qmp_receive_dict ../tests/qtest/libqtest.c:636
#12 0x55b1bebc2e6c in qtest_qmp_receive ../tests/qtest/libqtest.c:624
#13 0x55b1bebc3340 in qtest_vqmp ../tests/qtest/libqtest.c:715
#14 0x55b1bebc3942 in qtest_qmp ../tests/qtest/libqtest.c:756
#15 0x55b1bebbd64a in adc_qom_set ../tests/qtest/npcm7xx_adc-test.c:127
#16 0x55b1bebbd793 in adc_write_input ../tests/qtest/npcm7xx_adc-test.c:140
#17 0x55b1bebbdf92 in test_convert_external ../tests/qtest/npcm7xx_adc-test.c:246
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Gan Qixin <ganqixin@huawei.com>
Reviewed-by: Hao Wu <wuhaotsh@google.com>
Message-id: 20210118065627.79903-1-ganqixin@huawei.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Update all users of do_perm_pred3 for the new
predicate descriptor field definitions.
Cc: qemu-stable@nongnu.org
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210113062650.593824-4-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
These two were odd, in that do_pfirst_pnext passed the
count of 64-bit words rather than bytes. Change to pass
the standard pred_full_reg_size to avoid confusion.
Cc: qemu-stable@nongnu.org
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210113062650.593824-3-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
SVE predicate operations cannot use the "usual" simd_desc
encoding, because the lengths are not a multiple of 8.
But we were abusing the SIMD_* fields to store values anyway.
This abuse broke when SIMD_OPRSZ_BITS was modified in e2e7168a21.
Introduce a new set of field definitions for exclusive use
of predicates, so that it is obvious what kind of predicate
we are manipulating. To be used in future patches.
Cc: qemu-stable@nongnu.org
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210113062650.593824-2-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This adds handling for the SCR_EL3.EEL2 bit.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Message-id: 20210112104511.36576-17-remi.denis.courmont@huawei.com
[PMM: Applied fixes for review issues noted by RTH:
- check for FEATURE_AARCH64 before checking sel2 isar feature
- correct the commit message subject line]
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
On ARMv8-A, accesses by 32-bit secure EL1 to monitor registers trap to
the upper (64-bit) EL. With Secure EL2 support, we can no longer assume
that that is always EL3, so make room for the value to be computed at
run-time.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-16-remi.denis.courmont@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The stage_1_mmu_idx() already effectively keeps track of which
translation regimes have two stages. Don't hard-code another test.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-13-remi.denis.courmont@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In the secure stage 2 translation regime, the VSTCR.SW and VTCR.NSW
bits can invert the secure flag for pagetable walks. This patchset
allows S1_ptw_translate() to change the non-secure bit.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-11-remi.denis.courmont@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The VTTBR write callback so far assumes that the underlying VM lies in
non-secure state. This handles the secure state scenario.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-10-remi.denis.courmont@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This adds the MMU indices for EL2 stage 1 in secure state.
To keep code contained, which is largelly identical between secure and
non-secure modes, the MMU indices are reassigned. The new assignments
provide a systematic pattern with a non-secure bit.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-8-remi.denis.courmont@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
With the ARMv8.4-SEL2 extension, EL2 is a legal exception level in
secure mode, though it can only be AArch64.
This patch adds the target EL for exceptions from 64-bit S-EL2.
It also fixes the target EL to EL2 when HCR.{A,F,I}MO are set in secure
mode. Those values were never used in practice as the effective value of
HCR was always 0 in secure mode.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-7-remi.denis.courmont@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-6-remi.denis.courmont@huawei.com
[PMM: tweaked commit message to match reduced scope of patch
following rebase]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This adds a common helper to compute the effective value of MDCR_EL2.
That is the actual value if EL2 is enabled in the current security
context, or 0 elsewise.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-5-remi.denis.courmont@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This will simplify accessing HCR conditionally in secure state.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-4-remi.denis.courmont@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Do not assume that EL2 is available in and only in non-secure context.
That equivalence is broken by ARMv8.4-SEL2.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-3-remi.denis.courmont@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This checks if EL2 is enabled (meaning EL2 registers take effects) in
the current security context.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-2-remi.denis.courmont@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In this context, the HCR value is the effective value, and thus is
zero in secure mode. The tests for HCR.{F,I}MO are sufficient.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210112104511.36576-1-remi.denis.courmont@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The interface for object_property_add_bool is simpler,
making the code easier to understand.
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210111235740.462469-4-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The crypto overhead of emulating pauth can be significant for
some workloads. Add two boolean properties that allows the
feature to be turned off, on with the architected algorithm,
or on with an implementation defined algorithm.
We need two intermediate booleans to control the state while
parsing properties lest we clobber ID_AA64ISAR1 into an invalid
intermediate state.
Tested-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210111235740.462469-3-richard.henderson@linaro.org
[PMM: fixed docs typo, tweaked text to clarify that the impdef
algorithm is specific to QEMU]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Without hardware acceleration, a cryptographically strong
algorithm is too expensive for pauth_computepac.
Even with hardware accel, we are not currently expecting
to link the linux-user binaries to any crypto libraries,
and doing so would generally make the --static build fail.
So choose XXH64 as a reasonably quick and decent hash.
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210111235740.462469-2-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Next pull request for qemu-6.0. Not a huge amount here, but it does
have some important fixes from Greg Kurz. Includes:
* A number of minor cleanups from Daniel Barboza (preliminaries for
some hotplug changes that are still under review)
* Improved handling of memory hotplug from Greg Kurz
* A number of fixes for sam460ex and other 440 based platforms from
Zolan Balaton
* Some fixes for the QOMification of the PPC 4xx UIC interrupt
controller from Peter Maydell
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAmAGerUACgkQbDjKyiDZ
s5LjYQ/+M3OYOrvy8thPINm+s5oeJbeCVlavLK9KY4STGzow9HgI0Kl0BkfviK5y
X5kLdIWTXTW6SmNUa1Y45kEc2L5wxbXERHGk5WkfoMte0DycOFsWmwdmtAfGKQEI
R31+Aj5U/tI+JgtvzlFpHyAqXPzzpLUmnHi9PesD70yU/30FdtI1ZNOA3fRYhN9b
iyBubp340Hy4dWSofGYe4L8ieznmNsIDFVsrcj4jzyp0bSNMPPWgqkHAKHmRST6Q
wcCQCA8hh5T93JPov/W1q0WB+zB0/LGoNLnqh87sH54CL2QwarYJSKMXjl4nsSfY
IRkUO/PW+a+52JHhaACO2aq/qzsNOD/j+8/RE4KBds7wG2XYCY9j3hH0NtcAkHdz
M2odtjHYAW3wFBaaoqff76N/MxDd9WJxc222uBunoJLYumRk3XF1e83cwGRsDpTH
Vu3O6o4/JhBoon0U52+xTFzdRq5rxwaFdwD+YRTTxycgs6v3tENDnTh+USOQezEq
F2W+ESez/7L+HDxUfXs3Lp+RGRyE9aNgeJMfhIyoBY+8n0APZCNz+CwPuqQMxCqi
IVb2FMj9duuXfFNt4ubpmtb0nW9wSikWhxQCvhQKxiYfCesv6mvNEXwcqPtt/Ph5
MR1pT45GykYoDrVrZ4sUfxxOGSrFHoxmslZDRSaSXVBWIzF6JIw=
=pkwx
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.0-20210119' into staging
ppc patch queue 2021-01-19
Next pull request for qemu-6.0. Not a huge amount here, but it does
have some important fixes from Greg Kurz. Includes:
* A number of minor cleanups from Daniel Barboza (preliminaries for
some hotplug changes that are still under review)
* Improved handling of memory hotplug from Greg Kurz
* A number of fixes for sam460ex and other 440 based platforms from
Zolan Balaton
* Some fixes for the QOMification of the PPC 4xx UIC interrupt
controller from Peter Maydell
# gpg: Signature made Tue 19 Jan 2021 06:22:45 GMT
# gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full]
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full]
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full]
# gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dg-gitlab/tags/ppc-for-6.0-20210119:
spapr_cpu_core.c: use g_auto* in spapr_create_vcpu()
spapr_rtas.c: fix identation of rtas_ibm_suspend_me() args
spapr_hcall.c: make do_client_architecture_support static
spapr.h: fix trailing whitespace in phb_placement
spapr: Improve handling of memory unplug with old guests
sam460ex: Use type cast macro instead of simple cast
Revert "ppc4xx: Move common dependency on serial to common option"
Revert "sam460ex: Remove FDT_PPC dependency from KConfig"
hw/ppc: Remove unused ppcuic_init()
hw/ppc/ppc405_uc: Drop use of ppcuic_init()
hw/intc/ppc-uic: Make default dcr-base 0xc0, not 0x30
hw/ppc: Delete unused ppc405cr_init() code
hw/ppc/sam460ex: Drop use of ppcuic_init()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The next-cube.h file is missing the usual copyright-and-license
header; add it (same as the next-cube.c one).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-12-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Add the vmstate for the new NeXTPC devic; this is in theory
a migration compatibility break, but this machine doesn't have
working migration currently anyway.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-11-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
The fields scsi_irq, scsi_dma, scsi_reset and fd_irq in
NeXTState are all unused, except in commented out
"this should do something like this" code. Remove the
unused fields. As and when the functionality that might
use them is added, we can put in the correct kind of
wiring (which might or might not need to be a qemu_irq,
but which in any case will need to be in the NeXTPC
device, not in NeXTState).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-10-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Move the rtc into the NeXTPC struct. Since this is the last
use of the 'backdoor' NextState pointer we can now remove that.
Probably the RTC should be its own device at some point: in hardware
there is a separate MCS1850 RTC chip connected to the Peripheral
Controller via a 1-bit serial interface. That goes beyond the remit
of the current refactoring, though.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-9-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Make the next_irq function be GPIO inputs to the NEXT_PC
device, rather than a freestanding set of qemu_irq lines.
This fixes a minor Coverity issue where it correctly points
out the trivial memory leak of the memory allocated in the
call to qemu_allocate_irqs().
Fixes: CID 1421962
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-8-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
All the code which accesses int_status and int_mask is now doing
so via the NeXTPC->NeXTState indirection, so we can move these
fields into the NeXTPC struct where they belong.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-7-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Make the next_irq function take a NeXTPC* as its opaque rather than
the M68kCPU*. This will make it simpler to turn the next_irq
function into a gpio input line of the NeXTPC device in the next
commit.
For this to work we have to pass the CPU to the NeXTPC device via a
link property, in the same way we do in q800.c (and for the same
reason).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-6-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Move the registers handled by the scr_ops struct into the NeXTPC
device.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-5-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Move the registers handled by the mmio_ops struct into the NeXTPC
device. This allows us to also move the scr1 and scr2 data fields.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-4-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Currently the next-cube board code open-codes a lot of handling of
interrupts and some miscellaneous registers. Move this into a proper
QOM device.
In the real hardware this functionality seems to be the
responsibility of the Peripheral Controller (PC) chip, so name the
device that.
There are several different things that will need to be moved into
this device:
* the mmio_iops register set
* the scr_ops register set
* the next_irq IRQ handling
To ease review, we structure the change as a sequence of commits: in
this first commit we create the skeleton of the NeXTPC device with no
content, but with a backdoor pointer to the NeXTState machine's state
struct so we can move parts of the code and still have refactored and
non-refactored code using the same struct data fields. Further
commits will move functionality into the new device piece by piece.
At the end we will be able to remove the backdoor pointer because all
the data fields will be in the NeXTPC struct and not the NeXTState
struct.
We'll add the VMState for the new device at the end of all that; this
is in theory a migration compatibility break but this machine does
not currently support migration at all anyway.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-3-peter.maydell@linaro.org>
[huth: Add a comment in front of struct NeXTPC]
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
The next_irq() function is global, but isn't actually used anywhere
outside next-cube.c. Make it static.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210115201206.17347-2-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Use g_autoptr() with Object and g_autofree with the string to
avoid the need of a cleanup path.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210114180628.1675603-6-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The function is called only inside spapr_hcall.c.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210114180628.1675603-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This whitespace was messing with lots of diffs if you happen
to use an editor that eliminates trailing whitespaces on file
save.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210114180628.1675603-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Since commit 1e8b5b1aa1 ("spapr: Allow memory unplug to always succeed")
trying to unplug memory from a guest that doesn't support it (eg. rhel6)
no longer generates an error like it used to. Instead, it leaves the
memory around : only a subsequent reboot or manual use of drmgr within
the guest can complete the hot-unplug sequence. A flag was added to
SpaprMachineClass so that this new behavior only applies to the default
machine type.
We can do better. CAS processes all pending hot-unplug requests. This
means that we don't really care about what the guest supports if
the hot-unplug request happens before CAS.
All guests that we care for, even old ones, set enough bits in OV5
that lead to a non-empty bitmap in spapr->ov5_cas. Use that as a
heuristic to decide if CAS has already occured or not.
Always accept unplug requests that happen before CAS since CAS will
process them. Restore the previous behavior of rejecting them after
CAS when we know that the guest doesn't support memory hot-unplug.
This behavior is suitable for all machine types : this allows to
drop the pre_6_0_memory_unplug flag.
Fixes: 1e8b5b1aa1 ("spapr: Allow memory unplug to always succeed")
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <161012708715.801107.11418801796987916516.stgit@bahia.lan>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
