aboutsummaryrefslogtreecommitdiff
path: root/target/i386/cpu.c
AgeCommit message (Collapse)Author
2017-03-28i386: Don't override -cpu options on -cpu host/maxEduardo Habkost
The existing code for "host" and "max" CPU models overrides every single feature in the CPU object at realize time, even the ones that were explicitly enabled or disabled by the user using "feat=on" or "feat=off", while features set using +feat/-feat are kept. This means "-cpu host,+invtsc" works as expected, while "-cpu host,invtsc=on" doesn't. This was a known bug, already documented in a comment inside x86_cpu_expand_features(). What makes this bug worse now is that libvirt 3.0.0 and newer now use "feat=on|off" instead of +feat/-feat when it detects a QEMU version that supports it (see libvirt commit d47db7b16dd5422c7e487c8c8ee5b181a2f9cd66). Change the feature property getter/setter to set a env->user_features field, to keep track of features that were explicitly changed using QOM properties. Then make the max_features code not override user features when handling "-cpu host" and "-cpu max". This will also allow us to remove the plus_features/minus_features hack in the future, but I plan to do that after 2.9.0 is released. Reported-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170327144815.8043-3-ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-28i386: Replace uint32_t* with FeatureWord on feature getter/setterEduardo Habkost
Instead of passing a pointer to the feature property getter and setter functions, pass a FeatureWord enum so they can perform other actions related to the feature flag. This will be used to add a new "user_features" field to keep track of features that were explicitly set by the user. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170327144815.8043-2-ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-10i386: Change stepping of Haswell to non-blacklisted valueEduardo Habkost
glibc blacklists TSX on Haswell CPUs with model==60 and stepping < 4. To make the Haswell CPU model more useful, make those guests actually use TSX by changing CPU stepping to 4. References: * glibc commit 2702856bf45c82cf8e69f2064f5aa15c0ceb6359 https://sourceware.org/git/?p=glibc.git;a=commit;h=2702856bf45c82cf8e69f2064f5aa15c0ceb6359 Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170309181212.18864-4-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-10i386: host_vendor_fms() helper functionEduardo Habkost
Helper function for code that needs to check the host CPU vendor/family/model/stepping values. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170309181212.18864-2-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-03x86: Work around SMI migration breakagesDr. David Alan Gilbert
Migration from a 2.3.0 qemu results in a reboot on the receiving QEMU due to a disagreement about SM (System management) interrupts. 2.3.0 didn't have much SMI support, but it did set CPU_INTERRUPT_SMI and this gets into the migration stream, but on 2.3.0 it never got delivered. ~2.4.0 SMI interrupt support was added but was broken - so that when a 2.3.0 stream was received it cleared the CPU_INTERRUPT_SMI but never actually caused an interrupt. The SMI delivery was recently fixed by 68c6efe07a, but the effect now is that an incoming 2.3.0 stream takes the interrupt it had flagged but it's bios can't actually handle it(I think partly due to the original interrupt not being taken during boot?). The consequence is a triple(?) fault and a reboot. Tested from: 2.3.1 -M 2.3.0 2.7.0 -M 2.3.0 2.8.0 -M 2.3.0 2.8.0 -M 2.8.0 This corresponds to RH bugzilla entry 1420679. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20170223133441.16010-1-dgilbert@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-03qapi: flatten GuestPanicInformation unionAnton Nefedov
Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Eric Blake <eblake@redhat.com> Message-Id: <1487614915-18710-3-git-send-email-den@openvz.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-02-27i386: Improve query-cpu-model-expansion full modeEduardo Habkost
This keeps the same results on type=static expansion, but make type=full expansion return every single QOM property on the CPU object that have a different value from the "base' CPU model, plus all the CPU feature flag properties. Cc: Jiri Denemark <jdenemar@redhat.com> Message-Id: <20170222190029.17243-4-ehabkost@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Implement query-cpu-model-expansion QMP commandEduardo Habkost
Implement query-cpu-model-expansion for target-i386. This should meet all the requirements while being simple. In the case of static expansion, it will use the new "base" CPU model, and in the case of full expansion, it will keep the original CPU model name+props, and append extra properties. A future follow-up should improve the implementation of type=full, so that it returns more detailed data, including every writable QOM property in the CPU object. Cc: libvir-list@redhat.com Cc: Jiri Denemark <jdenemar@redhat.com> Message-Id: <20170222190029.17243-3-ehabkost@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Define static "base" CPU modelEduardo Habkost
The query-cpu-model-expand QMP command needs at least one static model, to allow the "static" expansion mode to be implemented. Instead of defining static versions of every CPU model, define a "base" CPU model that has absolutely no feature flag enabled. Despite having no CPUID data set at all, "-cpu base" is even a functional CPU: * It can boot a Slackware Linux 1.01 image with a Linux 0.99.12 kernel[1]. * It is even possible to boot[2] a modern Fedora x86_64 guest by manually enabling the following CPU features: -cpu base,+lm,+msr,+pae,+fpu,+cx8,+cmov,+sse,+sse2,+fxsr [1] http://www.qemu-advent-calendar.org/2014/#day-1 [2] This is what can be seen in the guest: [root@localhost ~]# cat /proc/cpuinfo processor : 0 vendor_id : unknown cpu family : 0 model : 0 model name : 00/00 stepping : 0 physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu msr pae cx8 cmov fxsr sse sse2 lm nopl bugs : bogomips : 5832.70 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [root@localhost ~]# x86info -v -a x86info v1.30. Dave Jones 2001-2011 Feedback to <davej@redhat.com>. No TSC, MHz calculation cannot be performed. Unknown vendor (0) MP Table: Family: 0 Model: 0 Stepping: 0 CPU Model (x86info's best guess): eax in: 0x00000000, eax = 00000001 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x00000001, eax = 00000000 ebx = 00000800 ecx = 00000000 edx = 07008161 eax in: 0x80000000, eax = 80000001 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x80000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 20000000 Feature flags: fpu Onboard FPU msr Model-Specific Registers pae Physical Address Extensions cx8 CMPXCHG8 instruction cmov CMOV instruction fxsr FXSAVE and FXRSTOR instructions sse SSE support sse2 SSE2 support Long NOPs supported: yes Address sizes : 0 bits physical, 0 bits virtual 0MHz processor (estimate). running at an estimated 0MHz [root@localhost ~]# Message-Id: <20170222190029.17243-2-ehabkost@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Don't set CPUClass::cpu_def on "max" modelEduardo Habkost
Host CPUID info is used by the "max" CPU model only in KVM mode. Move the initialization of CPUID data for "max" from class_init to instance_init, and don't set CPUClass::cpu_def for "max". Message-Id: <20170222183919.11928-4-ehabkost@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Make "max" model not use any host CPUID info on TCGEduardo Habkost
Instead of reporting host CPUID data on "max", use the qemu64 CPU model as reference to initialize CPUID vendor/family/model/stepping/model-id. Message-Id: <20170222183919.11928-3-ehabkost@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Create "max" CPU modelEduardo Habkost
Rename the existing "host" CPU model to "max, and set it to kvm_enabled=false. The new "max" CPU model will be able to enable all features supported by TCG out of the box, because its logic is based on x86_cpu_get_supported_feature_word(), which already works with TCG. A new KVM-specific "host" class was added, that simply inherits everything from "max" except the 'ordering' and 'description' fields. Message-Id: <20170222183919.11928-2-ehabkost@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Reorganize and document CPUID initialization stepsEduardo Habkost
CPU runnability checks and CPU model expansion have slightly different requirements. Document the steps involved in loading a CPU model and realizing a CPU, so their requirements and purpose are clearly defined. This patch doesn't change any implementation. It just add comments, rename the x86_cpu_load_features() function for clarity (so it won't be confused with x86_cpu_load_def()), and move x86_cpu_filter_features() closer to it. Message-Id: <20170116211124.29245-2-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Rename X86CPU::host_features to X86CPU::max_featuresEduardo Habkost
Rename the field and add a small comment to make its purpose clearer. Message-Id: <20170119210449.11991-4-ehabkost@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Add ordering field to CPUClassEduardo Habkost
Instead of using kvm_enabled to order the "-cpu help" list, use a new "ordering" field for that. Message-Id: <20170119210449.11991-3-ehabkost@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Unset cannot_destroy_with_object_finalize_yet on "host" modelEduardo Habkost
The class is now safe because the assert(kvm_enabled()) line was removed by commit e435601058e656e6d24e3e87b187e5518f7bf16a. Message-Id: <20170119210449.11991-2-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-23util/cutils: Change qemu_strtosz*() from int64_t to uint64_tMarkus Armbruster
This will permit its use in parse_option_size(). Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> (maintainer:X86) Cc: Kevin Wolf <kwolf@redhat.com> (supporter:Block layer core) Cc: Max Reitz <mreitz@redhat.com> (supporter:Block layer core) Cc: qemu-block@nongnu.org (open list:Block layer core) Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1487708048-2131-24-git-send-email-armbru@redhat.com>
2017-02-23util/cutils: Return qemu_strtosz*() error and value separatelyMarkus Armbruster
This makes qemu_strtosz(), qemu_strtosz_mebi() and qemu_strtosz_metric() similar to qemu_strtoi64(), except negative values are rejected. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> (maintainer:X86) Cc: Kevin Wolf <kwolf@redhat.com> (supporter:Block layer core) Cc: Max Reitz <mreitz@redhat.com> (supporter:Block layer core) Cc: qemu-block@nongnu.org (open list:Block layer core) Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1487708048-2131-23-git-send-email-armbru@redhat.com>
2017-02-23util/cutils: Let qemu_strtosz*() optionally reject trailing crapMarkus Armbruster
Change the qemu_strtosz() & friends to return -EINVAL when @endptr is null and the conversion doesn't consume the string completely. Matches how qemu_strtol() & friends work. Only test_qemu_strtosz_simple() passes a null @endptr. No functional change there, because its conversion consumes the string. Simplify callers that use @endptr only to fail when it doesn't point to '\0' to pass a null @endptr instead. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> (maintainer:X86) Cc: Kevin Wolf <kwolf@redhat.com> (supporter:Block layer core) Cc: Max Reitz <mreitz@redhat.com> (supporter:Block layer core) Cc: qemu-block@nongnu.org (open list:Block layer core) Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1487708048-2131-22-git-send-email-armbru@redhat.com>
2017-02-23util/cutils: New qemu_strtosz_metric()Markus Armbruster
To parse numbers with metric suffixes, we use qemu_strtosz_suffix_unit(nptr, &eptr, QEMU_STRTOSZ_DEFSUFFIX_B, 1000) Capture this in a new function for legibility: qemu_strtosz_metric(nptr, &eptr) Replace test_qemu_strtosz_suffix_unit() by test_qemu_strtosz_metric(). Rename qemu_strtosz_suffix_unit() to do_strtosz() and give it internal linkage. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1487708048-2131-15-git-send-email-armbru@redhat.com>
2017-02-16report guest crash information in GUEST_PANICKED eventAnton Nefedov
it's not very convenient to use the crash-information property interface, so provide a CPU class callback to get the guest crash information, and pass that information in the event Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> Message-Id: <1487053524-18674-3-git-send-email-den@openvz.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-02-16i386/cpu: add crash-information QOM propertyAnton Nefedov
Windows reports BSOD parameters through Hyper-V crash MSRs. This information is very useful for initial crash analysis and thus it would be nice to have a way to fetch it. Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> Message-Id: <1487053524-18674-2-git-send-email-den@openvz.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-27pc: Enable vmware-cpuid-freq CPU option for 2.9+ machine typesPhil Dennis-Jordan
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Message-Id: <1484921496-11257-4-git-send-email-phil@philjordan.eu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-27x86-KVM: Supply TSC and APIC clock rates to guest like VMWarePhil Dennis-Jordan
This fixes timekeeping of x86-64 Darwin/OS X/macOS guests when using KVM. Darwin/OS X/macOS for x86-64 uses the TSC for timekeeping; it normally calibrates this by querying various clock frequency scaling MSRs. Details depend on the exact CPU model detected. The local APIC timer frequency is extracted from (EFI) firmware. This is problematic in the presence of virtualisation, as the MSRs in question are typically not handled by the hypervisor. VMWare (Fusion) advertises TSC and APIC frequency via a custom 0x40000010 CPUID leaf, in the eax and ebx registers respectively. This is documented at https://lwn.net/Articles/301888/ among other places. Darwin/OS X/macOS looks for the generic 0x40000000 hypervisor leaf, and if this indicates via eax that leaf 0x40000010 might be available, that is in turn queried for the two frequencies. This adds a CPU option "vmware-cpuid-freq" to enable the same behaviour when running Qemu with KVM acceleration, if the KVM TSC frequency can be determined, and it is stable. (invtsc or user-specified) The virtualised APIC bus cycle is hardcoded to 1GHz in KVM, so ebx of the CPUID leaf is also hardcoded to this value. Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Message-Id: <1484921496-11257-2-git-send-email-phil@philjordan.eu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-23i386: Return migration-safe field on query-cpu-definitionsEduardo Habkost
Return the migration-safe field on query-cpu-definitions. All CPU models in x86 are migration-safe except "host". Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170116181212.31565-1-ehabkost@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-01-23i386: Remove AMD feature flag aliases from Opteron modelsEduardo Habkost
When CPU vendor is set to AMD, the AMD feature alias bits on CPUID[0x80000001].EDX are already automatically copied from CPUID[1].EDX on x86_cpu_realizefn(). When CPU vendor is Intel, those bits are reserved and should be zero. On either case, those bits shouldn't be set in the CPU model table. Commit 726a8ff68677d8d5fba17eb0ffb85076bfb598dc removed those bits from most CPU models, but the Opteron_* entries still have them. Remove the alias bits from Opteron_* too. Add an assert() to x86_register_cpudef_type() to ensure we don't make the same mistake again. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170113190057.6327-1-ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-01-23x86: add AVX512_VPOPCNTDQ featuresHe Chen
AVX512_VPOPCNTDQ: Vector POPCNT instructions for word and qwords. variable precision. Signed-off-by: He Chen <he.chen@linux.intel.com> Message-Id: <1484272411-28073-1-git-send-email-he.chen@linux.intel.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-01-16Merge remote-tracking branch ↵Peter Maydell
'remotes/stsquad/tags/pull-tcg-common-tlb-reset-20170113-r1' into staging This is the same as the v3 posted except a re-base and a few extra signoffs # gpg: Signature made Fri 13 Jan 2017 14:26:46 GMT # gpg: using RSA key 0xFBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * remotes/stsquad/tags/pull-tcg-common-tlb-reset-20170113-r1: cputlb: drop flush_global flag from tlb_flush cpu_common_reset: wrap TCG specific code in tcg_enabled() qom/cpu: move tlb_flush to cpu_common_reset Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-01-13qom/cpu: move tlb_flush to cpu_common_resetAlex Bennée
It is a common thing amongst the various cpu reset functions want to flush the SoftMMU's TLB entries. This is done either by calling tlb_flush directly or by way of a general memset of the CPU structure (sometimes both). This moves the tlb_flush call to the common reset function and additionally ensures it is only done for the CONFIG_SOFTMMU case and when tcg is enabled. In some target cases we add an empty end_of_reset_fields structure to the target vCPU structure so have a clear end point for any memset which is resetting value in the structure before CPU_COMMON (where the TLB structures are). While this is a nice clean-up in general it is also a precursor for changes coming to cputlb for MTTCG where the clearing of entries can't be done arbitrarily across vCPUs. Currently the cpu_reset function is usually called from the context of another vCPU as the architectural power up sequence is run. By using the cputlb API functions we can ensure the right behaviour in the future. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-12qmp: Report QOM type name on query-cpu-definitionsEduardo Habkost
The new typename attribute on query-cpu-definitions will be used to help management software use device-list-properties to check which properties can be set using -cpu or -global for the CPU model. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <1479320499-29818-1-git-send-email-ehabkost@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-12-22x86: implement la57 paging modeKirill A. Shutemov
The new paging more is extension of IA32e mode with more additional page table level. It brings support of 57-bit vitrual address space (128PB) and 52-bit physical address space (4PB). The structure of new page table level is identical to pml4. The feature is enumerated with CPUID.(EAX=07H, ECX=0):ECX[bit 16]. CR4.LA57[bit 12] need to be set when pageing enables to activate 5-level paging mode. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Message-Id: <20161215001305.146807-1-kirill.shutemov@linux.intel.com> [Drop changes to target-i386/translate.c. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-12-22target-i386: Add Intel SHA_NI instruction support.Yi Sun
Add SHA_NI feature bit. Its spec can be found at: https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> Message-Id: <1481683803-10051-1-git-send-email-yi.y.sun@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-12-20Move target-* CPU file into a target/ folderThomas Huth
We've currently got 18 architectures in QEMU, and thus 18 target-xxx folders in the root folder of the QEMU source tree. More architectures (e.g. RISC-V, AVR) are likely to be included soon, too, so the main folder of the QEMU sources slowly gets quite overcrowded with the target-xxx folders. To disburden the main folder a little bit, let's move the target-xxx folders into a dedicated target/ folder, so that target-xxx/ simply becomes target/xxx/ instead. Acked-by: Laurent Vivier <laurent@vivier.eu> [m68k part] Acked-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> [tricore part] Acked-by: Michael Walle <michael@walle.cc> [lm32 part] Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x part] Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> [s390x part] Acked-by: Eduardo Habkost <ehabkost@redhat.com> [i386 part] Acked-by: Artyom Tarasenko <atar4qemu@gmail.com> [sparc part] Acked-by: Richard Henderson <rth@twiddle.net> [alpha part] Acked-by: Max Filippov <jcmvbkbc@gmail.com> [xtensa part] Reviewed-by: David Gibson <david@gibson.dropbear.id.au> [ppc part] Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> [cris&microblaze part] Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn> [unicore32 part] Signed-off-by: Thomas Huth <thuth@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-16 08:31:34 +0000