aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-09-08meson: build qapi tests libraryMarc-André Lureau3-78/+62
- builds QAPI builtins types/visitor to fix a linking issue with unresolved symbols in the static library. - work around a meson limitation on generated file output directories. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200828110734.1638685-2-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-08meson: fix libqos linkingPaolo Bonzini1-3/+6
Add genh to the sources to avoid race conditions between QAPI file generation and libqos compilation. Make the name_suffix .fa for consistency with other link_whole static libraries and to work around a Meson issue where lots of linker flags are placed between -Wl,--start-group and -Wl,--end-group and this breaks the fork-fuzz.ld linker script. Reported-by: Claudio Fontana <cfontana@suse.de> Reported-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-08ninjatool: use constant names for stamp filesPaolo Bonzini1-3/+5
Numbering files according to rules causes confusion, because CUSTOM_COMMAND3.stamp from a previous build might represent completely different targets after Makefile.ninja is regenerated. As a result, the new targets are not rebuilt and compilation fails. Use the targets to build a SHA1 hash; the chances for collision are one in 2^24 even with a 12-character prefix of the hash. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-08configure: include cross sdl2-config in meson cross filePaolo Bonzini1-0/+3
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-08configure: do not include absolute paths in -I and -L pathsPaolo Bonzini1-5/+5
On msys2, paths such as -L/e/path/to/qemu are not recognized by the linker. Fortunately we do not need absolute paths at all in a non-recursive build system. Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-08meson: remove b_lundef optionPaolo Bonzini1-1/+1
Meson automatically adds "-undefined dynamic_lookup" to shared_module build targets; b_lundef is only needed for executables. Therefore, we can remove this option. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-08mtest2make: unify tests that appear in multiple suitesPaolo Bonzini1-36/+38
Whenever a test appears in multiple suites, the rules generated by mtest2make are currently running it twice. Instead, after this patch we generate a phony target for each test and we have a generic "run-tests" target depend on all the tests that were chosen on the command line. Tests that appear in multiple suites will be added to the prerequisites just once. This has other advantages: it removes the handling of -k and it increases parallelism. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-08mtest2make: hide output of successful testsPaolo Bonzini2-1/+36
The softfloat tests are quite noisy; before the Meson conversion they buffered the output in a file and emitted the output only if the test failed. Tweak mtest2make.py so that the courtesy is extended to all non-TAP tests. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-08mtest2make: split working directory from test commandPaolo Bonzini1-8/+8
Pass the working directory and test command in separate macro arguments, so that we will be able to insert a test driver in the next patch. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-08mtest2make: split environment from test commandPaolo Bonzini1-8/+9
Pass the environment and test command in separate macro arguments, so that we will be able to insert a test driver in the next patch. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-08qemu-iotests: move check-block back to MakefilesPaolo Bonzini3-8/+12
check-block has its own test harness, unlike every other test. If we capture its output, as is in general nicer to do without V=1, there will be no sign of progress. So for lack of a better option just move the invocation of the test back to Makefile rules. As a side effect, this will also fix "make check" in --disable-tools builds, as they were trying to run qemu-iotests without having made qemu-img before. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-08spapr_numa: use spapr_numa_get_vcpu_assoc() in home_node hcallDaniel Henrique Barboza1-8/+33
The current implementation of h_home_node_associativity hard codes the values of associativity domains of the vcpus. Let's make it consider the values already initialized in spapr->numa_assoc_array, via the spapr_numa_get_vcpu_assoc() helper. We want to set it and forget it, and for that we also need to assert that we don't overflow the registers of the hypercall. >From R4 to R9 we can squeeze in 12 associativity domains for vcpus, so let's assert that VCPU_ASSOC_SIZE -1 isn't greater than that. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200904172422.617460-4-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr_numa: create a vcpu associativity helperDaniel Henrique Barboza2-14/+24
The work to be done in h_home_node_associativity() intersects with what is already done in spapr_numa_fixup_cpu_dt(). This patch creates a new helper, spapr_numa_get_vcpu_assoc(), to be used for both spapr_numa_fixup_cpu_dt() and h_home_node_associativity(). While we're at it, use memcpy() instead of loop assignment to created the returned array. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200904172422.617460-3-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr: move h_home_node_associativity to spapr_numa.cDaniel Henrique Barboza2-40/+45
The implementation of this hypercall will be modified to use spapr->numa_assoc_arrays input. Moving it to spapr_numa.c makes make more sense. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200904172422.617460-2-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr_numa: move NVLink2 associativity handling to spapr_numa.cDaniel Henrique Barboza2-18/+30
The NVLink2 GPUs works like a regular NUMA node with its own associativity values, regardless of user input. This can be handled inside spapr_numa_associativity_init(), initializing NVGPU_MAX_NUM associativity arrays that can be used by the GPUs. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200903220639.563090-5-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr, spapr_numa: move lookup-arrays handling to spapr_numa.cDaniel Henrique Barboza3-23/+38
In a similar fashion as the previous patch, let's move the handling of ibm,associativity-lookup-arrays from spapr.c to spapr_numa.c. A spapr_numa_write_assoc_lookup_arrays() helper was created, and spapr_dt_dynamic_reconfiguration_memory() can now use it to advertise the lookup-arrays. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200903220639.563090-4-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr, spapr_numa: handle vcpu ibm,associativityDaniel Henrique Barboza3-16/+30
Vcpus have an additional paramenter to be appended, vcpu_id. This also changes the size of the of property itself, which is being represented in index 0 of numa_assoc_array[cpu->node_id], and defaults to MAX_DISTANCE_REF_POINTS for all cases but vcpus. All this logic makes more sense in spapr_numa.c, where we handle everything NUMA and associativity. A new helper spapr_numa_fixup_cpu_dt() was added, and spapr.c uses it the same way as it was using the former spapr_fixup_cpu_numa_dt(). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200903220639.563090-3-danielhb413@gmail.com> [dwg: Correct uint to int type, which can break windows builds] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr: introduce SpaprMachineState::numa_assoc_arrayDaniel Henrique Barboza7-33/+73
The next step to centralize all NUMA/associativity handling in the spapr machine is to create a 'one stop place' for all things ibm,associativity. This patch introduces numa_assoc_array, a 2 dimensional array that will store all ibm,associativity arrays of all NUMA nodes. This array is initialized in a new spapr_numa_associativity_init() function, called in spapr_machine_init(). It is being initialized with the same values used in other ibm,associativity properties around spapr files (i.e. all zeros, last value is node_id). The idea is to remove all hardcoded definitions and FDT writes of ibm,associativity arrays, doing instead a call to the new helper spapr_numa_write_associativity_dt() helper, that will be able to write the DT with the correct values. We'll start small, handling the trivial cases first. The remaining instances of ibm,associativity will be handled next. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200903220639.563090-2-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08ppc/spapr_nvdimm: turn spapr_dt_nvdimm() staticDaniel Henrique Barboza2-12/+11
This function is only used inside spapr_nvdimm.c. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200901125645.118026-3-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08ppc: introducing spapr_numa.c NUMA code helperDaniel Henrique Barboza4-25/+74
We're going to make changes in how spapr handles all ibm,associativity* related properties to enhance our current NUMA support. At this moment we have associativity code scattered all around spapr_* files, with hardcoded values and array sizes. This makes it harder to change any NUMA specific parameters in the future. Having everything in the same place allows not only for easier tuning, but also easier understanding since all NUMA related code is on the same file. This patch introduces a new file to gather all NUMA/associativity handling code in spapr, spapr_numa.c. To get things started, let's remove associativity-reference-points and max-associativity-domains code from spapr_dt_rtas() to a new helper called spapr_numa_write_rtas_dt(). This will decouple spapr_dt_rtas() from the NUMA changes that are going to happen in those two properties. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200901125645.118026-2-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08hw/ppc/ppc4xx_pci: Replace pointless warning by assert()Philippe Mathieu-Daudé1-4/+1
We call pci_register_root_bus() to register 4 IRQs with the ppc4xx_pci_set_irq() handler. As it can only be called with values in the [0-4[ range, replace the pointless warning by an assert(). Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200901104043.91383-5-f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08hw/ppc/ppc4xx_pci: Use ARRAY_SIZE() instead of magic valuePhilippe Mathieu-Daudé1-1/+2
Replace the magic '4' by ARRAY_SIZE(s->irq) which is more explicit. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200901104043.91383-4-f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08target/s390x: Use start-powered-off CPUState propertyThiago Jung Bauermann1-1/+1
Instead of setting CPUState::halted to 1 in s390_cpu_initfn(), use the start-powered-off property which makes cpu_common_reset() initialize it to 1 in common code. Note that this changes behavior by setting cs->halted to 1 on reset, which didn't happen before. Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Message-Id: <20200826055535.951207-9-bauerman@linux.ibm.com> [dwg: Fix from Laurent Vivier for user only case] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08sparc/sun4m: Use start-powered-off CPUState propertyThiago Jung Bauermann1-19/+6
Instead of setting CPUState::halted to 1 in secondary_cpu_reset(), use the start-powered-off property which makes cpu_common_reset() initialize it to 1 in common code. Now secondary_cpu_reset() becomes equivalent to main_cpu_reset() so rename the function to sun4m_cpu_reset(). Also remove setting of cs->halted from cpu_devinit(), which seems out of place when compared to similar code in other architectures (e.g., ppce500_init() in hw/ppc/e500.c). Finally, change creation of CPU object from cpu_create() to object_new() and qdev_realize_and_unref() because cpu_create() realizes the CPU and it's not possible to set a property after the object is realized. Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Message-Id: <20200826055535.951207-8-bauerman@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08sparc/sun4m: Don't set cs->halted = 0 in main_cpu_reset()Thiago Jung Bauermann1-1/+0
We rely on cpu_common_reset() to set cs->halted to 0, it's redundant to do it in main_cpu_reset(). Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Message-Id: <20200826055535.951207-7-bauerman@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08mips/cps: Use start-powered-off CPUState propertyThiago Jung Bauermann1-4/+11
Instead of setting CPUState::halted to 1 in main_cpu_reset(), use the start-powered-off property which makes cpu_common_reset() initialize it to 1 in common code. Also change creation of CPU object from cpu_create() to object_new() and qdev_realize_and_unref() because cpu_create() realizes the CPU and it's not possible to set a property after the object is realized. Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Message-Id: <20200826055535.951207-6-bauerman@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08ppc/e500: Use start-powered-off CPUState propertyThiago Jung Bauermann1-4/+9
Instead of setting CPUState::halted to 1 in ppce500_cpu_reset_sec(), use the start-powered-off property which makes cpu_common_reset() initialize it to 1 in common code. Also change creation of CPU object from cpu_create() to object_new() and qdev_realize_and_unref() because cpu_create() realizes the CPU and it's not possible to set a property after the object is realized. Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Message-Id: <20200826055535.951207-5-bauerman@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08ppc/spapr: Use start-powered-off CPUState propertyThiago Jung Bauermann1-5/+5
PowerPC sPAPR CPUs start in the halted state, and spapr_reset_vcpu() attempts to implement this by setting CPUState::halted to 1. But that's too late for the case of hotplugged CPUs in a machine configure with 2 or more threads per core. By then, other parts of QEMU have already caused the vCPU to run in an unitialized state a couple of times. For example, ppc_cpu_reset() calls ppc_tlb_invalidate_all(), which ends up calling async_run_on_cpu(). This kicks the new vCPU while it has CPUState::halted = 0, causing QEMU to issue a KVM_RUN ioctl on the new vCPU before the guest is able to make the start-cpu RTAS call to initialize its register state. This problem doesn't seem to cause visible issues for regular guests, but on a secure guest running under the Ultravisor it does. The Ultravisor relies on being able to snoop on the start-cpu RTAS call to map vCPUs to guests, and this issue causes it to see a stray vCPU that doesn't belong to any guest. Fix by setting the start-powered-off CPUState property in spapr_create_vcpu(), which makes cpu_common_reset() initialize CPUState::halted to 1 at an earlier moment. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Message-Id: <20200826055535.951207-4-bauerman@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08target/arm: Move setting of CPU halted state to generic codeThiago Jung Bauermann2-2/+1
This change is in a separate patch because it's not so obvious that it won't cause a regression. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Message-Id: <20200826055535.951207-3-bauerman@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08target/arm: Move start-powered-off property to generic CPUStateThiago Jung Bauermann6-8/+9
There are other platforms which also have CPUs that start powered off, so generalize the start-powered-off property so that it can be used by them. Note that ARMv7MState also has a property of the same name but this patch doesn't change it because that class isn't a subclass of CPUState so it wouldn't be a trivial change. This change should not cause any change in behavior. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Message-Id: <20200826055535.951207-2-bauerman@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08ppc/spapr_nvdimm: do not enable support with 'nvdimm=off'Daniel Henrique Barboza1-0/+18
The NVDIMM support for pSeries was introduced in 5.1, but it didn't contemplate the 'nvdimm' machine option that other archs uses. For every other arch, if no '-machine nvdimm(=on)' is present, it is assumed that the NVDIMM support is disabled. The user must explictly inform that the machine supports NVDIMM. For pseries-5.1 the 'nvdimm' option is completely ignored, and support is always assumed to exist. This leads to situations where the user is able to set 'nvdimm=off' but the guest boots up with the NVDIMMs anyway. Fixing this now, after 5.1 launch, can put the overall NVDIMM support for pseries in a strange place regarding this 'nvdimm' machine option. If we force everything to be like other archs, existing pseries-5.1 guests that didn't use 'nvdimm' to use NVDIMM devices will break. If we attempt to make the newer pseries machines (5.2+) behave like everyone else, but keep pseries-5.1 untouched, we'll have consistency problems on machine upgrade (5.1 will have different default values for NVDIMM support than 5.2). The common ground here is, if the user sets 'nvdimm=off', we must comply regardless of being 5.1 or 5.2+. This patch changes spapr_nvdimm_validate() to verify if the user set NVDIMM support off in the machine options and, in that case, error out if we have a NVDIMM device. The default value for 5.2+ pseries machines will still be 'nvdimm=on' when there is no 'nvdimm' option declared, just like it is today with pseries-5.1. In the end we'll have different default semantics from everyone else in the absence of the 'nvdimm' machine option, but this boat has sailed. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1848887 Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200825215749.213536-4-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr, spapr_nvdimm: fold NVDIMM validation in the same placeDaniel Henrique Barboza3-16/+16
NVDIMM has different contraints and conditions than the regular DIMM and we'll need to add at least one more. Instead of relying on 'if (nvdimm)' conditionals in the body of spapr_memory_pre_plug(), use the existing spapr_nvdimm_validate_opts() and put all NVDIMM handling code there. Rename it to spapr_nvdimm_validate() to reflect that the function is now checking more than the nvdimm device options. This makes spapr_memory_pre_plug() a bit easier to follow, and we can tune in NVDIMM parameters and validation in the same place. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200825215749.213536-3-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08ppc/spapr_nvdimm: use g_autofree in spapr_nvdimm_validate_opts()Daniel Henrique Barboza1-2/+1
Since we're using the string just once, just use g_autofree and avoid leaking it without calling g_free(). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200825215749.213536-2-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr/xive: Allocate vCPU IPIs from the vCPU contextsCédric Le Goater1-3/+33
When QEMU switches to the XIVE interrupt mode, it creates all the guest interrupts at the level of the KVM device. These interrupts are backed by real HW interrupts from the IPI interrupt pool of the XIVE controller. Currently, this is done from the QEMU main thread, which results in allocating all interrupts from the chip on which QEMU is running. IPIs are not distributed across the system and the load is not well balanced across the interrupt controllers. Change the vCPU IPI allocation to run from the vCPU context. The associated XIVE IPI interrupt will be allocated on the chip on which the vCPU is running and improve distribution of the IPIs in the system. When the vCPUs are pinned, this will make the IPI local to the chip of the vCPU. It will reduce rerouting between interrupt controllers and gives better performance. Device interrupts are still treated the same. To improve placement, we would need some information on the chip owning the virtual source or the HW source in case of a passthrough device but this reuires changes in PAPR. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200820134547.2355743-5-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr/xive: Allocate IPIs independently from the other sourcesCédric Le Goater1-5/+42
The vCPU IPIs are now allocated in kvmppc_xive_cpu_connect() when the vCPU connects to the KVM device and not when all the sources are reset in kvmppc_xive_source_reset() This requires extra care for hotplug vCPUs and VM restore. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200820134547.2355743-4-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr/xive: Use kvmppc_xive_source_reset() in post_loadCédric Le Goater1-10/+10
This is doing an extra loop but should be equivalent. It also differentiate the reset of the sources from the restore of the sources configuration. This will help in allocating the vCPU IPIs independently. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200820134547.2355743-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr/xive: Modify kvm_cpu_is_enabled() interfaceCédric Le Goater1-3/+2
We will use to check if a vCPU IPI has been created. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200820134547.2355743-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr/xive: Use the xics flag to check for XIVE-only IRQ backendsCédric Le Goater1-1/+1
The sPAPR machine has four different IRQ backends, each implementing the XICS or XIVE interrupt mode or both in the case of the 'dual' backend. If a machine is started in P8 compat mode, QEMU should necessarily support the XICS interrupt mode and in that case, the XIVE-only IRQ backend is invalid. Currently, spapr_irq_check() tests the pointer value to the IRQ backend to check for this condition, instead use the 'xics' flag. It's equivalent and it will ease the introduction of new XIVE-only IRQ backends if needed. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200820140106.2357228-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr_vscsi: do not allow device hotplugDaniel Henrique Barboza1-0/+3
We do not implement hotplug in the vscsi bus, but we forgot to tell qdev about it. The result is that users are able to hotplug devices in the vscsi bus, the devices appear in qdev, but they aren't usable by the guest OS unless the user reboots it first. Setting qbus hotplug_handler to NULL will tell qdev-monitor, via qbus_is_hotpluggable(), that we do not support hotplug operations in spapr_vscsi. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1862059 Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200820190635.379657-1-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08ppc/pnv: Add a HIOMAP erase commandCédric Le Goater2-1/+29
The OPAL test suite runs a read-erase-write test on the PNOR : https://github.com/open-power/op-test/blob/master/testcases/OpTestPNOR.py which revealed that the IPMI HIOMAP handlers didn't support HIOMAP_C_ERASE. Implement the sector erase command by writing 0xFF in the PNOR memory region. Cc: Corey Minyard <cminyard@mvista.com> Reported-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200820164638.2515681-1-clg@kaod.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr/xive: Add a 'hv-prio' property to represent the KVM escalation priorityCédric Le Goater2-19/+16
On POWER9, the KVM XIVE device uses priority 7 for the escalation interrupts. On POWER10, the host can use a reduced set of priorities and KVM will configure the escalation priority to a lower number. In any case, the guest is allowed to use priorities in a single range : [ 0 .. (maxprio - 1) ]. Introduce a 'hv-prio' property to represent the escalation priority number and use it to compute the "ibm,plat-res-int-priorities" property defining the priority ranges reserved by the hypervisor. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200819130843.2230799-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08spapr: Remove unnecessary DRC type-checker macrosDavid Gibson1-42/+1
spapr_drc.h includes typechecker macro boilerplate for the many different DRC subclasses. However, most of these types don't actually have different data in their class and/or instance, making these unneeded, unused, and in fact a bad idea. Remove them. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
2020-09-08ppc/pnv: Fix TypeInfo of PnvLpcController abstract classCédric Le Goater1-2/+1
It was missing the instance_size field. Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200822083920.2668930-1-clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-08adb: Correct class size on TYPE_ADB_DEVICEDavid Gibson1-0/+1
The TypeInfo incorrectly just lets the class size be inherited. It won't actually break things, since the class is abstract, but we should get it right. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2020-09-07Merge remote-tracking branch 'remotes/hdeller/tags/target-hppa-pull-request' ↵Peter Maydell7-23/+94
into staging hppa power button support, graphics updates and firmware fixes # gpg: Signature made Mon 07 Sep 2020 20:09:49 BST # gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F # gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown] # gpg: aka "Helge Deller <deller@kernel.org>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603 # Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F * remotes/hdeller/tags/target-hppa-pull-request: hw/display/artist: Allow screen size up to 2048 lines hw/display/artist: Refactor x/y coordination extraction hw/display/artist: Verify artist screen resolution target/hppa: Fix boot with old Linux installation CDs hw/hppa: Add power button emulation hw/hppa: Tell SeaBIOS port address of fw_cfg hw/hppa: Change fw_cfg port address hw/hppa: Store boot device in fw_cfg section hw/hppa: Make number of TLB and BTLB entries configurable seabios-hppa: Update SeaBIOS to hppa-qemu-5.2-2 tag Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-09-07configure: Do not set TARGET_ABI32 for microblazeRichard Henderson1-1/+0
In 19f27b6c2493 TARGET_ABI_LONG was reduced to 32 bits for CONFIG_USER_ONLY. There is no need to set this by hand; it will now be set automatically by include/exec/user/abitypes.h. Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-09-07target/microblaze: Put MicroBlazeCPUConfig into DisasContextRichard Henderson1-12/+12
The bulk of the translator should not have access to the complete cpu state, to avoid the temptation to examine bits that are in run time, but not translation time context. We do need access to the constant cpu configuration, and that is sufficient, so put that into DisasContext. Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-09-07target/microblaze: Fill in VMStateDescription for cpuRichard Henderson4-8/+115
Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-09-07target/microblaze: Move mmu parameters to MicroBlazeCPUConfigRichard Henderson5-25/+30
The final 4 fields in MicroBlazeMMU are configuration constants. Move them into MicroBlazeCPUConfig where they belong. Remove the leading "c_" from the member names, as that presumably implied "config", and that should not be explicit in the location. Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-09-07target/microblaze: Treat pvr_regs as constantRichard Henderson2-9/+0
Do not allow gdb to set the values, and don't bother dumping unchanging values with -d cpu. Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
generated by cgit v1.1 at 2025-01-08 14:00:40 +0000