- 18 1月, 2018 2 次提交
-
-
由 Peter Maydell 提交于
ppc patch queue 2017-01-17 Another pull request for ppc related patches. The most interesting thing here is the new capabilities framework for the pseries machine type. This gives us better handling of several existing incompatibilities between TCG, PR and HV KVM, as well as new ones that arise with POWER9. Further, it will allow reasonable handling of the advertisement of features necessary to mitigate the recent CVEs (Spectre and Meltdown). In addition there's: * Improvide handling of different "vsmt" modes * Significant enhancements to the "pnv" machine type * Assorted other bugfixes # gpg: Signature made Wed 17 Jan 2018 02:21:50 GMT # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.12-20180117: (22 commits) target-ppc: Fix booke206 tlbwe TLB instruction target/ppc: add support for POWER9 HILE ppc/pnv: change initrd address ppc/pnv: fix XSCOM core addressing on POWER9 ppc/pnv: introduce pnv*_is_power9() helpers ppc/pnv: change core mask for POWER9 ppc/pnv: use POWER9 DD2 processor tests/boot-serial-test: fix powernv support ppc/pnv: Update skiboot firmware image spapr: Adjust default VSMT value for better migration compatibility spapr: Allow some cases where we can't set VSMT mode in the kernel target/ppc: Clarify compat mode max_threads value ppc: Change Power9 compat table to support at most 8 threads/core spapr: Remove unnecessary 'options' field from sPAPRCapabilityInfo hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation spapr: Handle Decimal Floating Point (DFP) as an optional capability spapr: Handle VMX/VSX presence as an spapr capability flag target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM spapr: Validate capabilities on migration spapr: Treat Hardware Transactional Memory (HTM) as an optional capability ... Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 John Arbuckle 提交于
When using a mouse's scroll wheel in a guest with the cocoa front-end, the mouse pointer moves up and down instead of scrolling the window. This patch fixes this problem. Signed-off-by: NJohn Arbuckle <programmingkidx@gmail.com> Message-id: 20180108180707.7976-1-programmingkidx@gmail.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 17 1月, 2018 27 次提交
-
-
由 Luc MICHEL 提交于
When overwritting a valid TLB entry with a new one, the previous page were not flushed in QEMU TLB, leading to incoherent mapping. This commit fixes this. Signed-off-by: NLuc MICHEL <luc.michel@git.antfield.fr> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
When skiboot starts, it first clears the CPU structs for all possible CPUs on a system : for (i = 0; i <= cpu_max_pir; i++) memset(&cpu_stacks[i].cpu, 0, sizeof(struct cpu_thread)); On POWER9, cpu_max_pir is quite big, 0x7fff, and the skiboot cpu_stacks array overlaps with the memory region in which QEMU maps the initramfs file. Move it upwards in memory to keep it safe. Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
The XSCOM base address of the core chiplet was wrongly calculated. Use the OPAL macros to fix that and do a couple of renames. Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
These are useful when instantiating device models which are shared between the POWER8 and the POWER9 processor families. Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
When addressed by XSCOM, the first core has the 0x20 chiplet ID but the CPU PIR can start at 0x0. Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
commit 1ed9c8af ("target/ppc: Add POWER9 DD2.0 model information") deprecated the POWER9 model v1.0. Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
Recent commit introduced the firmware image skiboot 5.9 which has a different first line ouput. Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Cédric Le Goater 提交于
This is skiboot 5.9 (commit e0ee24c2). It brings improved POWER9 support among many other things. Built from submodule. Signed-off-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
fa98fbfc "PC: KVM: Support machine option to set VSMT mode" introduced the "vsmt" parameter for the pseries machine type, which controls the spacing of the vcpu ids of thread 0 for each virtual core. This was done to bring some consistency and stability to how that was done, while still allowing backwards compatibility for migration and otherwise. The default value we used for vsmt was set to the max of the host's advertised default number of threads and the number of vthreads per vcore in the guest. This was done to continue running without extra parameters on older KVM versions which don't allow the VSMT value to be changed. Unfortunately, even that smaller than before leakage of host configuration into guest visible configuration still breaks things. Specifically a guest with 4 (or less) vthread/vcore will get a different vsmt value when running on a POWER8 (vsmt==8) and POWER9 (vsmt==4) host. That means the vcpu ids don't line up so you can't migrate between them, though you should be able to. Long term we really want to make vsmt == smp_threads for sufficiently new machine types. However, that means that qemu will then require a sufficiently recent KVM (one which supports changing VSMT) - that's still not widely enough deployed to be really comfortable to do. In the meantime we need some default that will work as often as possible. This patch changes that default to 8 in all circumstances. This does change guest visible behaviour (including for existing machine versions) for many cases - just not the most common/important case. Following is case by case justification for why this is still the least worst option. Note that any of the old behaviours can still be duplicated after this patch, it's just that it requires manual intervention by setting the vsmt property on the command line. KVM HV on POWER8 host: This is the overwhelmingly common case in production setups, and is unchanged by design. POWER8 hosts will advertise a default VSMT mode of 8, and > 8 vthreads/vcore isn't permitted KVM HV on POWER7 host: Will break, but POWER7s allowing KVM were never released to the public. KVM HV on POWER9 host: Not yet released to the public, breaking this now will reduce other breakage later. KVM HV on PowerPC 970: Will theoretically break it, but it was barely supported to begin with and already required various user visible hacks to work. Also so old that I just don't care. TCG: This is the nastiest one; it means migration of TCG guests (without manual vsmt setting) will break. Since TCG is rarely used in production I think this is worth it for the other benefits. It does also remove one more barrier to TCG<->KVM migration which could be interesting for debugging applications. KVM PR: As with TCG, this will break migration of existing configurations, without adding extra manual vsmt options. As with TCG, it is rare in production so I think the benefits outweigh breakages. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NLaurent Vivier <lvivier@redhat.com> Reviewed-by: NJose Ricardo Ziviani <joserz@linux.vnet.ibm.com> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 David Gibson 提交于
At present if we require a vsmt mode that's not equal to the kernel's default, and the kernel doesn't let us change it (e.g. because it's an old kernel without support) then we always fail. But in fact we can cope with the kernel having a different vsmt as long as a) it's >= the actual number of vthreads/vcore (so that guest threads that are supposed to be on the same core act like it) b) it's a submultiple of the requested vsmt mode (so that guest threads spaced by the vsmt value will act like they're on different cores) Allowing this case gives us a bit more freedom to adjust the vsmt behaviour without breaking existing cases. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NLaurent Vivier <lvivier@redhat.com> Tested-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 David Gibson 提交于
We recently had some discussions that were sidetracked for a while, because nearly everyone misapprehended the purpose of the 'max_threads' field in the compatiblity modes table. It's all about guest expectations, not host expectations or support (that's handled elsewhere). In an attempt to avoid a repeat of that confusion, rename the field to 'max_vthreads' and add an explanatory comment. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NLaurent Vivier <lvivier@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NJose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
-
由 Jose Ricardo Ziviani 提交于
Increases the max smt mode to 8 for Power9. That's because KVM supports smt emulation in this platform so QEMU should allow users to use it as well. Today if we try to pass -smp ...,threads=8, QEMU will silently truncate it to smt4 mode and may cause a crash if we try to perform a cpu hotplug. Signed-off-by: NJose Ricardo Ziviani <joserz@linux.vnet.ibm.com> [dwg: Added an explanatory comment] Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
The options field here is intended to list the available values for the capability. It's not used yet, because the existing capabilities are boolean. We're going to add capabilities that aren't, but in that case the info on the possible values can be folded into the .description field. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Suraj Jitindar Singh 提交于
Currently spapr_caps are tied to boolean values (on or off). This patch reworks the caps so that they can have any uint8 value. This allows more capabilities with various values to be represented in the same way internally. Capabilities are numbered in ascending order. The internal representation of capability values is an array of uint8s in the sPAPRMachineState, indexed by capability number. Capabilities can have their own name, description, options, getter and setter functions, type and allow functions. They also each have their own section in the migration stream. Capabilities are only migrated if they were explictly set on the command line, with the assumption that otherwise the default will match. On migration we ensure that the capability value on the destination is greater than or equal to the capability value from the source. So long at this remains the case then the migration is considered compatible and allowed to continue. This patch implements generic getter and setter functions for boolean capabilities. It also converts the existings cap-htm, cap-vsx and cap-dfp capabilities to this new format. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
Decimal Floating Point has been available on POWER7 and later (server) cpus. However, it can be disabled on the hypervisor, meaning that it's not available to guests. We currently handle this by conditionally advertising DFP support in the device tree depending on whether the guest CPU model supports it - which can also depend on what's allowed in the host for -cpu host. That can lead to confusion on migration, since host properties are silently affecting guest visible properties. This patch handles it by treating it as an optional capability for the pseries machine type. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 David Gibson 提交于
We currently have some conditionals in the spapr device tree code to decide whether or not to advertise the availability of the VMX (aka Altivec) and VSX vector extensions to the guest, based on whether the guest cpu has those features. This can lead to confusion and subtle failures on migration, since it makes a guest visible change based only on host capabilities. We now have a better mechanism for this, in spapr capabilities flags, which explicitly depend on user options rather than host capabilities. Rework the advertisement of VSX and VMX based on a new VSX capability. We no longer bother with a conditional for VMX support, because every CPU that's ever been supported by the pseries machine type supports VMX. NOTE: Some userspace distributions (e.g. RHEL7.4) already rely on availability of VSX in libc, so using cap-vsx=off may lead to a fatal SIGILL in init. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 David Gibson 提交于
When constructing the "host" cpu class we modify whether the VMX and VSX vector extensions and DFP (Decimal Floating Point) are available based on whether KVM can support those instructions. This can depend on policy in the host kernel as well as on the actual host cpu capabilities. However, the way we probe for this is not very nice: we explicitly check the host's device tree. That works in practice, but it's not really correct, since the device tree is a property of the host kernel's platform which we don't really know about. We get away with it because the only modern POWER platforms happen to encode VMX, VSX and DFP availability in the device tree in the same way. Arguably we should have an explicit KVM capability for this, but we haven't needed one so far. Barring specific KVM policies which don't yet exist, each of these instruction classes will be available in the guest if and only if they're available in the qemu userspace process. We can determine that from the ELF AUX vector we're supplied with. Once reworked like this, there are no more callers for kvmppc_get_vmx() and kvmppc_get_dfp() so remove them. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 David Gibson 提交于
Now that the "pseries" machine type implements optional capabilities (well, one so far) there's the possibility of having different capabilities available at either end of a migration. Although arguably a user error, it would be nice to catch this situation and fail as gracefully as we can. This adds code to migrate the capabilities flags. These aren't pulled directly into the destination's configuration since what the user has specified on the destination command line should take precedence. However, they are checked against the destination capabilities. If the source was using a capability which is absent on the destination, we fail the migration, since that could easily cause a guest crash or other bad behaviour. If the source lacked a capability which is present on the destination we warn, but allow the migration to proceed. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 David Gibson 提交于
This adds an spapr capability bit for Hardware Transactional Memory. It is enabled by default for pseries-2.11 and earlier machine types. with POWER8 or later CPUs (as it must be, since earlier qemu versions would implicitly allow it). However it is disabled by default for the latest pseries-2.12 machine type. This means that with the latest machine type, HTM will not be available, regardless of CPU, unless it is explicitly enabled on the command line. That change is made on the basis that: * This way running with -M pseries,accel=tcg will start with whatever cpu and will provide the same guest visible model as with accel=kvm. - More specifically, this means existing make check tests don't have to be modified to use cap-htm=off in order to run with TCG * We hope to add a new "HTM without suspend" feature in the not too distant future which could work on both POWER8 and POWER9 cpus, and could be enabled by default. * Best guesses suggest that future POWER cpus may well only support the HTM-without-suspend model, not the (frankly, horribly overcomplicated) POWER8 style HTM with suspend. * Anecdotal evidence suggests problems with HTM being enabled when it wasn't wanted are more common than being missing when it was. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 David Gibson 提交于
Because PAPR is a paravirtual environment access to certain CPU (or other) facilities can be blocked by the hypervisor. PAPR provides ways to advertise in the device tree whether or not those features are available to the guest. In some places we automatically determine whether to make a feature available based on whether our host can support it, in most cases this is based on limitations in the available KVM implementation. Although we correctly advertise this to the guest, it means that host factors might make changes to the guest visible environment which is bad: as well as generaly reducing reproducibility, it means that a migration between different host environments can easily go bad. We've mostly gotten away with it because the environments considered mature enough to be well supported (basically, KVM on POWER8) have had consistent feature availability. But, it's still not right and some limitations on POWER9 is going to make it more of an issue in future. This introduces an infrastructure for defining "sPAPR capabilities". These are set by default based on the machine version, masked by the capabilities of the chosen cpu, but can be overriden with machine properties. The intention is at reset time we verify that the requested capabilities can be supported on the host (considering TCG, KVM and/or host cpu limitations). If not we simply fail, rather than silently modifying the advertised featureset to the guest. This does mean that certain configurations that "worked" may now fail, but such configurations were already more subtly broken. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 Alexey Kardashevskiy 提交于
As stated in the 1ad9f0a4 commit log, the returned entries are not a whole PTEG. It was not a problem before 1ad9f0a4 as it would read a single record assuming it contains a whole PTEG but now the code tries reading the entire PTEG and "if ((n - i) < invalid)" produces negative values which then are converted to size_t for memset() and that throws seg fault. This fixes the math. While here, fix the last @i increment as well. Fixes: 1ad9f0a4 "target/ppc: Fix KVM-HV HPTE accessors" Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Peter Maydell 提交于
Queued TCG patches # gpg: Signature made Tue 16 Jan 2018 16:24:50 GMT # gpg: using RSA key 0x64DF38E8AF7E215F # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" # Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F * remotes/rth/tags/pull-tcg-20180116: tcg/ppc: Allow a 32-bit offset to the constant pool tcg/ppc: Support tlb offsets larger than 64k tcg/arm: Support tlb offsets larger than 64k tcg/arm: Fix double-word comparisons Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Richard Henderson 提交于
We recently relaxed the limit of the number of opcodes that can appear in a TranslationBlock. In certain cases this has resulted in relocation overflow. Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
-
由 Richard Henderson 提交于
AArch64 with SVE has an offset of 80k to the 8th TLB. Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
-
由 Richard Henderson 提交于
AArch64 with SVE has an offset of 80k to the 8th TLB. Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
-
由 Richard Henderson 提交于
The code sequence we were generating was only good for unsigned comparisons. For signed comparisions, use the sequence from gcc. Fixes booting of ppc64 firmware, with a patch changing the code sequence for ppc comparisons. Tested-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
-
- 16 1月, 2018 11 次提交
-
-
由 Peter Maydell 提交于
* QemuMutex tracing improvements (Alex) * ram_addr_t optimization (David) * SCSI fixes (Fam, Stefan, me) * do {} while (0) fixes (Eric) * KVM fix for PMU (Jan) * memory leak fixes from ASAN (Marc-André) * migration fix for HPET, icount, loadvm (Maria, Pavel) * hflags fixes (me, Tao) * block/iscsi uninitialized variable (Peter L.) * full support for GMainContexts in character devices (Peter Xu) * more boot-serial-test (Thomas) * Memory leak fix (Zhecheng) # gpg: Signature made Tue 16 Jan 2018 14:15:45 GMT # gpg: using RSA key 0xBFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (51 commits) scripts/analyse-locks-simpletrace.py: script to analyse lock times util/qemu-thread-*: add qemu_lock, locked and unlock trace events cpu: flush TB cache when loading VMState block/iscsi: fix initialization of iTask in iscsi_co_get_block_status find_ram_offset: Align ram_addr_t allocation on long boundaries find_ram_offset: Add comments and tracing cpu_physical_memory_sync_dirty_bitmap: Another alignment fix checkpatch: Enforce proper do/while (0) style maint: Fix macros with broken 'do/while(0); ' usage tests: Avoid 'do/while(false); ' in vhost-user-bridge chardev: Clean up previous patch indentation chardev: Use goto/label instead of do/break/while(0) mips: Tweak location of ';' in macros net: Drop unusual use of do { } while (0); irq: fix memory leak cpus: unify qemu_*_wait_io_event icount: fixed saving/restoring of icount warp timers scripts/qemu-gdb/timers.py: new helper to dump timer state scripts/qemu-gdb: add simple tcg lock status helper target-i386: update hflags on Hypervisor.framework ... Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
target-arm queue: * SDHCI: cleanups and minor bug fixes * target/arm: minor refactor preparatory to fp16 support * omap_ssd, ssi-sd, pl181, milkymist-memcard: reset the SD card on controller reset (fixes migration failures) * target/arm: Handle page table walk load failures correctly * hw/arm/virt: Add virt-2.12 machine type * get_phys_addr_pmsav7: Support AP=0b111 for v7M * hw/intc/armv7m: Support byte and halfword accesses to CFSR # gpg: Signature made Tue 16 Jan 2018 13:33:31 GMT # gpg: using RSA key 0x3C2525ED14360CDE # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" # gpg: aka "Peter Maydell <pmaydell@gmail.com>" # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20180116: (24 commits) sdhci: add a 'dma' property to the sysbus devices sdhci: fix the PCI device, using the PCI address space for DMA sdhci: Implement write method of ACMD12ERRSTS register sdhci: fix CAPAB/MAXCURR registers, both are 64bit and read-only sdhci: rename the SDHC_CAPAB register sdhci: move MASK_TRNMOD with other SDHC_TRN* defines in "sd-internal.h" sdhci: convert the DPRINT() calls into trace events sdhci: use qemu_log_mask(UNIMP) instead of fprintf() sdhci: refactor common sysbus/pci unrealize() into sdhci_common_unrealize() sdhci: refactor common sysbus/pci realize() into sdhci_common_realize() sdhci: refactor common sysbus/pci class_init() into sdhci_common_class_init() sdhci: use DEFINE_SDHCI_COMMON_PROPERTIES() for common sysbus/pci properties sdhci: remove dead code sdhci: clean up includes target/arm: Add fp16 support to vfp_expand_imm target/arm: Split out vfp_expand_imm hw/sd/omap_mmc: Reset SD card on controller reset hw/sd/ssi-sd: Reset SD card on controller reset hw/sd/milkymist-memcard: Reset SD card on controller reset hw/sd/pl181: Reset SD card on controller reset ... Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Alex Bennée 提交于
This script allows analysis of mutex acquisition and hold times based on a trace file. Given a trace control file of: qemu_mutex_lock qemu_mutex_locked qemu_mutex_unlock And running with: $QEMU $QEMU_ARGS -trace events=./lock-trace You can analyse the results with: ./scripts/analyse-locks-simpletrace.py trace-events-all ./trace-21812 Signed-off-by: NAlex Bennée <alex.bennee@linaro.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Alex Bennée 提交于
Signed-off-by: NAlex Bennée <alex.bennee@linaro.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Pavel Dovgalyuk 提交于
Flushing TB cache is required because TBs key in the cache may match different code which existed in the previous state. Signed-off-by: NPavel Dovgalyuk <pavel.dovgaluk@ispras.ru> Signed-off-by: NMaria Klimushenkova <maria.klimushenkova@ispras.ru> Message-Id: <20180110134846.12940.99993.stgit@pasha-VirtualBox> [Add comment suggested by Peter Maydell. - Paolo] Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NPavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
-
由 Peter Lieven 提交于
in case of unaligned requests or on a target that does not support block provisioning we leave iTask uninitialized and check iTask.task for NULL later. Fixes: e38bc234Signed-off-by: NPeter Lieven <pl@kamp.de> Reviewed-by: NEric Blake <eblake@redhat.com> Message-Id: <1515425247-21730-1-git-send-email-pl@kamp.de> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Dr. David Alan Gilbert 提交于
The dirty bitmaps are built from 'long's and there is fast-path code for synchronising the case where the RAMBlock is aligned to the start of a long boundary. Align the allocation to this boundary to cause the fast path to be used. Offsets before change: 11398@1515169675.018566:find_ram_offset size: 0x1e0000 @ 0x8000000 11398@1515169675.020064:find_ram_offset size: 0x20000 @ 0x81e0000 11398@1515169675.020244:find_ram_offset size: 0x20000 @ 0x8200000 11398@1515169675.024343:find_ram_offset size: 0x1000000 @ 0x8220000 11398@1515169675.025154:find_ram_offset size: 0x10000 @ 0x9220000 11398@1515169675.027682:find_ram_offset size: 0x40000 @ 0x9230000 11398@1515169675.032921:find_ram_offset size: 0x200000 @ 0x9270000 11398@1515169675.033307:find_ram_offset size: 0x1000 @ 0x9470000 11398@1515169675.033601:find_ram_offset size: 0x1000 @ 0x9471000 after change: 10923@1515169108.818245:find_ram_offset size: 0x1e0000 @ 0x8000000 10923@1515169108.819410:find_ram_offset size: 0x20000 @ 0x8200000 10923@1515169108.819587:find_ram_offset size: 0x20000 @ 0x8240000 10923@1515169108.823708:find_ram_offset size: 0x1000000 @ 0x8280000 10923@1515169108.824503:find_ram_offset size: 0x10000 @ 0x9280000 10923@1515169108.827093:find_ram_offset size: 0x40000 @ 0x92c0000 10923@1515169108.833045:find_ram_offset size: 0x200000 @ 0x9300000 10923@1515169108.833504:find_ram_offset size: 0x1000 @ 0x9500000 10923@1515169108.833787:find_ram_offset size: 0x1000 @ 0x9540000 Suggested-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20180105170138.23357-3-dgilbert@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Dr. David Alan Gilbert 提交于
Add some comments so I can understand the various nested loops. Add some tracing so I can see what they're doing. Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20180105170138.23357-2-dgilbert@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Dr. David Alan Gilbert 提交于
This code has an optimised, word aligned version, and a boring unaligned version. My commit f70d3451 fixed one alignment issue, but there's another. The optimised version operates on 'longs' dealing with (typically) 64 pages at a time, replacing the whole long by a 0 and counting the bits. If the Ramblock is less than 64bits in length that long can contain bits representing two different RAMBlocks, but the code will update the bmap belinging to the 1st RAMBlock only while having updated the total dirty page count for both. This probably didn't matter prior to 6b6712ef which split the dirty bitmap by RAMBlock, but now they're separate RAMBlocks we end up with a count that doesn't match the state in the bitmaps. Symptom: Migration showing a few dirty pages left to be sent constantly Seen on aarch64 and x86 with x86+ovmf Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reported-by: NWei Huang <wei@redhat.com> Fixes: 6b6712efSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Eric Blake 提交于
Use of a loop construct for code that is not intended to repeat does not make much idiomatic sense, except in one place: it is a common usage in macros in order to wrap arbitrary code with single-statement semantics. But when used in a macro, it is more typical for the caller to supply the trailing ';' when calling the macro. Although qemu coding style frowns on bare: if (cond) statement1; else statement2; where extra semicolons actually cause syntax errors, we still want our macro styles to be easily copied to other projects. Thus, declare it an error if we encounter any form of 'while (0)' with a semicolon in the same line. Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <20171201232433.25193-8-eblake@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Eric Blake 提交于
The point of writing a macro embedded in a 'do { ... } while (0)' loop (particularly if the macro has multiple statements or would otherwise end with an 'if' statement) is so that the macro can be used as a drop-in statement with the caller supplying the trailing ';'. Although our coding style frowns on brace-less 'if': if (cond) statement; else something else; that is the classic case where failure to use do/while(0) wrapping would cause the 'else' to pair with any embedded 'if' in the macro rather than the intended outer 'if'. But conversely, if the macro includes an embedded ';', then the same brace-less coding style would now have two statements, making the 'else' a syntax error rather than pairing with the outer 'if'. Thus, even though our coding style with required braces is not impacted, ending a macro with ';' makes our code harder to port to projects that use brace-less styles. The change should have no semantic impact. I was not able to fully compile-test all of the changes (as some of them are examples of the ugly bit-rotting debug print statements that are completely elided by default, and I didn't want to recompile with the necessary -D witnesses - cleaning those up is left as a bite-sized task for another day); I did, however, audit that for all files touched, all callers of the changed macros DID supply a trailing ';' at the callsite, and did not appear to be used as part of a brace-less conditional. Found mechanically via: $ git grep -B1 'while (0);' | grep -A1 \\\\ Signed-off-by: NEric Blake <eblake@redhat.com> Acked-by: NCornelia Huck <cohuck@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Acked-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20171201232433.25193-7-eblake@redhat.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-