qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] d0414d: target/i386: generate simpler code fo


From: Richard Henderson
Subject: [Qemu-commits] [qemu/qemu] d0414d: target/i386: generate simpler code for ROL/ROR wit...
Date: Thu, 23 May 2024 09:42:41 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: d0414d71f612651699de019b911a772b07d0ac4a
      
https://github.com/qemu/qemu/commit/d0414d71f612651699de019b911a772b07d0ac4a
  Author: Paolo Bonzini <pbonzini@redhat.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/tcg/emit.c.inc

  Log Message:
  -----------
  target/i386: generate simpler code for ROL/ROR with immediate count

gen_rot_carry and gen_rot_overflow are meant to be called with count == NULL
if the count cannot be zero.  However this is not done in gen_ROL and gen_ROR,
and writing everywhere "can_be_zero ? count : NULL" is burdensome and less
readable.  Just pass can_be_zero as a separate argument.

gen_RCL and gen_RCR use a conditional branch to skip the computation
if count is zero, so they can pass false unconditionally to gen_rot_overflow.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240522123914.608516-1-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: ec56891984e682c0e6a7bbf5a51372648a60a353
      
https://github.com/qemu/qemu/commit/ec56891984e682c0e6a7bbf5a51372648a60a353
  Author: Paolo Bonzini <pbonzini@redhat.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/helper.h
    M target/i386/tcg/decode-new.c.inc
    M target/i386/tcg/emit.c.inc
    M target/i386/tcg/int_helper.c

  Log Message:
  -----------
  target/i386: clean up AAM/AAD

The 32-bit AAM/AAD opcodes are using helpers that read and write flags and
env->regs[R_EAX].  Clean them up so that the table correctly includes AX
as a 16-bit input and output.

No real reason to do it to be honest, but they are nice one-output helpers
and it removes the masking of env->regs[R_EAX] that generic load/writeback
code already does.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240522123912.608497-1-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: a44ea3fa7f2aa1d809fdca1b84a52695b53d8ad0
      
https://github.com/qemu/qemu/commit/a44ea3fa7f2aa1d809fdca1b84a52695b53d8ad0
  Author: Bernhard Beschow <shentey@gmail.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M hw/i386/pc.c
    M hw/i386/pc_piix.c
    M hw/i386/pc_q35.c
    M hw/i386/pc_sysfw.c
    M include/hw/i386/pc.h

  Log Message:
  -----------
  hw/i386/pc_sysfw: Alias rather than copy isa-bios region

In the -bios case the "isa-bios" memory region is an alias to the BIOS mapped
to the top of the 4G memory boundary. Do the same in the -pflash case, but only
for new machine versions for migration compatibility. This establishes common
behavior and makes pflash commands work in the "isa-bios" region which some
real-world legacy bioses rely on.

Note that in the sev_enabled() case, the "isa-bios" memory region in the -pflash
case will now also point to encrypted memory, just like it already does in the
-bios case.

When running `info mtree` before and after this commit with
`qemu-system-x86_64 -S -drive \
if=pflash,format=raw,readonly=on,file=/usr/share/qemu/bios-256k.bin` and running
`diff -u before.mtree after.mtree` results in the following changes in the
memory tree:

   --- before.mtree
   +++ after.mtree
   @@ -71,7 +71,7 @@
        0000000000000000-ffffffffffffffff (prio -1, i/o): pci
        00000000000a0000-00000000000bffff (prio 1, i/o): vga-lowmem
        00000000000c0000-00000000000dffff (prio 1, rom): pc.rom
   -      00000000000e0000-00000000000fffff (prio 1, rom): isa-bios
   +      00000000000e0000-00000000000fffff (prio 1, romd): alias isa-bios 
@system.flash0 0000000000020000-000000000003ffff
        00000000000a0000-00000000000bffff (prio 1, i/o): alias smram-region 
@pci 00000000000a0000-00000000000bffff
        00000000000c0000-00000000000c3fff (prio 1, i/o): alias pam-pci @pci 
00000000000c0000-00000000000c3fff
        00000000000c4000-00000000000c7fff (prio 1, i/o): alias pam-pci @pci 
00000000000c4000-00000000000c7fff
   @@ -108,7 +108,7 @@
        0000000000000000-ffffffffffffffff (prio -1, i/o): pci
        00000000000a0000-00000000000bffff (prio 1, i/o): vga-lowmem
        00000000000c0000-00000000000dffff (prio 1, rom): pc.rom
   -      00000000000e0000-00000000000fffff (prio 1, rom): isa-bios
   +      00000000000e0000-00000000000fffff (prio 1, romd): alias isa-bios 
@system.flash0 0000000000020000-000000000003ffff
        00000000000a0000-00000000000bffff (prio 1, i/o): alias smram-region 
@pci 00000000000a0000-00000000000bffff
        00000000000c0000-00000000000c3fff (prio 1, i/o): alias pam-pci @pci 
00000000000c0000-00000000000c3fff
        00000000000c4000-00000000000c7fff (prio 1, i/o): alias pam-pci @pci 
00000000000c4000-00000000000c7fff
   @@ -131,11 +131,14 @@
   memory-region: pc.ram
   0000000000000000-0000000007ffffff (prio 0, ram): pc.ram

   +memory-region: system.flash0
   +  00000000fffc0000-00000000ffffffff (prio 0, romd): system.flash0
   +
   memory-region: pci
   0000000000000000-ffffffffffffffff (prio -1, i/o): pci
        00000000000a0000-00000000000bffff (prio 1, i/o): vga-lowmem
        00000000000c0000-00000000000dffff (prio 1, rom): pc.rom
   -    00000000000e0000-00000000000fffff (prio 1, rom): isa-bios
   +    00000000000e0000-00000000000fffff (prio 1, romd): alias isa-bios 
@system.flash0 0000000000020000-000000000003ffff

   memory-region: smram
        00000000000a0000-00000000000bffff (prio 0, ram): alias smram-low 
@pc.ram 00000000000a0000-00000000000bffff

Note that in both cases the "system" memory region contains the entry

  00000000fffc0000-00000000ffffffff (prio 0, romd): system.flash0

but the "system.flash0" memory region only appears standalone when "isa-bios" is
an alias.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-ID: <20240508175507.22270-7-shentey@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: ba6780905943696d790cc880c8e5684b51f027fe
      
https://github.com/qemu/qemu/commit/ba6780905943696d790cc880c8e5684b51f027fe
  Author: Robert Hoo <robert.hu@linux.intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/cpu.c
    M target/i386/cpu.h

  Log Message:
  -----------
  target/i386: add support for LAM in CPUID enumeration

Linear Address Masking (LAM) is a new Intel CPU feature, which allows
software to use of the untranslated address bits for metadata.

The bit definition:
CPUID.(EAX=7,ECX=1):EAX[26]

Add CPUID definition for LAM.

Note LAM feature is not supported for TCG of target-i386, LAM CPIUD bit
will not be added to TCG_7_1_EAX_FEATURES.

More info can be found in Intel ISE Chapter "LINEAR ADDRESS MASKING(LAM)"
https://cdrdv2.intel.com/v1/dl/getContent/671368

Signed-off-by: Robert Hoo <robert.hu@linux.intel.com>
Co-developed-by: Binbin Wu <binbin.wu@linux.intel.com>
Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
Tested-by: Xuelian Guo <xuelian.guo@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Message-ID: <20240112060042.19925-2-binbin.wu@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 0117067131f99acaab4f4d2cca0290c5510e37cf
      
https://github.com/qemu/qemu/commit/0117067131f99acaab4f4d2cca0290c5510e37cf
  Author: Binbin Wu <binbin.wu@linux.intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/cpu.h
    M target/i386/helper.c

  Log Message:
  -----------
  target/i386: add control bits support for LAM

LAM uses CR3[61] and CR3[62] to configure/enable LAM on user pointers.
LAM uses CR4[28] to configure/enable LAM on supervisor pointers.

For CR3 LAM bits, no additional handling needed:
- TCG
  LAM is not supported for TCG of target-i386.  helper_write_crN() and
  helper_vmrun() check max physical address bits before calling
  cpu_x86_update_cr3(), no change needed, i.e. CR3 LAM bits are not allowed
  to be set in TCG.
- gdbstub
  x86_cpu_gdb_write_register() will call cpu_x86_update_cr3() to update cr3.
  Allow gdb to set the LAM bit(s) to CR3, if vcpu doesn't support LAM,
  KVM_SET_SREGS will fail as other reserved bits.

For CR4 LAM bit, its reservation depends on vcpu supporting LAM feature or
not.
- TCG
  LAM is not supported for TCG of target-i386.  helper_write_crN() and
  helper_vmrun() check CR4 reserved bit before calling cpu_x86_update_cr4(),
  i.e. CR4 LAM bit is not allowed to be set in TCG.
- gdbstub
  x86_cpu_gdb_write_register() will call cpu_x86_update_cr4() to update cr4.
  Mask out LAM bit on CR4 if vcpu doesn't support LAM.
- x86_cpu_reset_hold() doesn't need special handling.

Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
Tested-by: Xuelian Guo <xuelian.guo@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Message-ID: <20240112060042.19925-3-binbin.wu@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 12f6b8280fa3a89db853bef8373ddc949dbfde6b
      
https://github.com/qemu/qemu/commit/12f6b8280fa3a89db853bef8373ddc949dbfde6b
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M hw/i386/pc.c
    M target/i386/cpu.c

  Log Message:
  -----------
  i386/cpu: Fix i/d-cache topology to core level for Intel CPU

For i-cache and d-cache, current QEMU hardcodes the maximum IDs for CPUs
sharing cache (CPUID.04H.00H:EAX[bits 25:14] and CPUID.04H.01H:EAX[bits
25:14]) to 0, and this means i-cache and d-cache are shared in the SMT
level.

This is correct if there's single thread per core, but is wrong for the
hyper threading case (one core contains multiple threads) since the
i-cache and d-cache are shared in the core level other than SMT level.

For AMD CPU, commit 8f4202fb1080 ("i386: Populate AMD Processor Cache
Information for cpuid 0x8000001D") has already introduced i/d cache
topology as core level by default.

Therefore, in order to be compatible with both multi-threaded and
single-threaded situations, we should set i-cache and d-cache be shared
at the core level by default.

This fix changes the default i/d cache topology from per-thread to
per-core. Potentially, this change in L1 cache topology may affect the
performance of the VM if the user does not specifically specify the
topology or bind the vCPU. However, the way to achieve optimal
performance should be to create a reasonable topology and set the
appropriate vCPU affinity without relying on QEMU's default topology
structure.

Fixes: 7e3482f82480 ("i386: Helpers to encode cache information consistently")
Suggested-by: Robert Hoo <robert.hu@linux.intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20240424154929.1487382-6-zhao1.liu@intel.com>
[Add compat property. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 88dd4ca06c8392155289e5462cd26af3762a1b04
      
https://github.com/qemu/qemu/commit/88dd4ca06c8392155289e5462cd26af3762a1b04
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  i386/cpu: Use APIC ID info to encode cache topo in CPUID[4]

Refer to the fixes of cache_info_passthrough ([1], [2]) and SDM, the
CPUID.04H:EAX[bits 25:14] and CPUID.04H:EAX[bits 31:26] should use the
nearest power-of-2 integer.

The nearest power-of-2 integer can be calculated by pow2ceil() or by
using APIC ID offset/width (like L3 topology using 1 << die_offset [3]).

But in fact, CPUID.04H:EAX[bits 25:14] and CPUID.04H:EAX[bits 31:26]
are associated with APIC ID. For example, in linux kernel, the field
"num_threads_sharing" (Bits 25 - 14) is parsed with APIC ID. And for
another example, on Alder Lake P, the CPUID.04H:EAX[bits 31:26] is not
matched with actual core numbers and it's calculated by:
"(1 << (pkg_offset - core_offset)) - 1".

Therefore the topology information of APIC ID should be preferred to
calculate nearest power-of-2 integer for CPUID.04H:EAX[bits 25:14] and
CPUID.04H:EAX[bits 31:26]:
1. d/i cache is shared in a core, 1 << core_offset should be used
   instead of "cs->nr_threads" in encode_cache_cpuid4() for
   CPUID.04H.00H:EAX[bits 25:14] and CPUID.04H.01H:EAX[bits 25:14].
2. L2 cache is supposed to be shared in a core as for now, thereby
   1 << core_offset should also be used instead of "cs->nr_threads" in
   encode_cache_cpuid4() for CPUID.04H.02H:EAX[bits 25:14].
3. Similarly, the value for CPUID.04H:EAX[bits 31:26] should also be
   calculated with the bit width between the package and SMT levels in
   the APIC ID (1 << (pkg_offset - core_offset) - 1).

In addition, use APIC ID bits calculations to replace "pow2ceil()" for
cache_info_passthrough case.

[1]: efb3934adf9e ("x86: cpu: make sure number of addressable IDs for processor 
cores meets the spec")
[2]: d7caf13b5fcf ("x86: cpu: fixup number of addressable IDs for logical 
processors sharing cache")
[3]: d65af288a84d ("i386: Update new x86_apicid parsing rules with die_offset 
support")

Fixes: 7e3482f82480 ("i386: Helpers to encode cache information consistently")
Suggested-by: Robert Hoo <robert.hu@linux.intel.com>
Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Message-ID: <20240424154929.1487382-7-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 9a085c4b4adeec648d6506316b8a42fbd0cf7c3c
      
https://github.com/qemu/qemu/commit/9a085c4b4adeec648d6506316b8a42fbd0cf7c3c
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  i386/cpu: Use APIC ID info get NumSharingCache for CPUID[0x8000001D].EAX[bits 
25:14]

The commit 8f4202fb1080 ("i386: Populate AMD Processor Cache Information
for cpuid 0x8000001D") adds the cache topology for AMD CPU by encoding
the number of sharing threads directly.

>From AMD's APM, NumSharingCache (CPUID[0x8000001D].EAX[bits 25:14])
means [1]:

The number of logical processors sharing this cache is the value of
this field incremented by 1. To determine which logical processors are
sharing a cache, determine a Share Id for each processor as follows:

ShareId = LocalApicId >> log2(NumSharingCache+1)

Logical processors with the same ShareId then share a cache. If
NumSharingCache+1 is not a power of two, round it up to the next power
of two.

>From the description above, the calculation of this field should be same
as CPUID[4].EAX[bits 25:14] for Intel CPUs. So also use the offsets of
APIC ID to calculate this field.

[1]: APM, vol.3, appendix.E.4.15 Function 8000_001Dh--Cache Topology
     Information

Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Babu Moger <babu.moger@amd.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Message-ID: <20240424154929.1487382-8-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 2613747a794c4de8cd04e4a24001765220e91f1b
      
https://github.com/qemu/qemu/commit/2613747a794c4de8cd04e4a24001765220e91f1b
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  i386/cpu: Consolidate the use of topo_info in cpu_x86_cpuid()

In cpu_x86_cpuid(), there are many variables in representing the cpu
topology, e.g., topo_info, cs->nr_cores and cs->nr_threads.

Since the names of cs->nr_cores and cs->nr_threads do not accurately
represent its meaning, the use of cs->nr_cores or cs->nr_threads is
prone to confusion and mistakes.

And the structure X86CPUTopoInfo names its members clearly, thus the
variable "topo_info" should be preferred.

In addition, in cpu_x86_cpuid(), to uniformly use the topology variable,
replace env->dies with topo_info.dies_per_pkg as well.

Suggested-by: Robert Hoo <robert.hu@linux.intel.com>
Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Babu Moger <babu.moger@amd.com>
Message-ID: <20240424154929.1487382-9-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 6ddeb0ec8c29d51be49d5336c6d6508972b6d49c
      
https://github.com/qemu/qemu/commit/6ddeb0ec8c29d51be49d5336c6d6508972b6d49c
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M hw/i386/x86-common.c
    M include/hw/i386/topology.h
    M target/i386/cpu.c
    M target/i386/cpu.h
    M target/i386/kvm/kvm.c

  Log Message:
  -----------
  i386/cpu: Introduce bitmap to cache available CPU topology levels

Currently, QEMU checks the specify number of topology domains to detect
if there's extended topology levels (e.g., checking nr_dies).

With this bitmap, the extended CPU topology (the levels other than SMT,
core and package) could be easier to detect without touching the
topology details.

This is also in preparation for the follow-up to decouple CPUID[0x1F]
subleaf with specific topology level.

Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Message-ID: <20240424154929.1487382-10-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 0f6ed7ba135a45a4a28bddda74d1bf0061174b98
      
https://github.com/qemu/qemu/commit/0f6ed7ba135a45a4a28bddda74d1bf0061174b98
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/cpu.c
    M target/i386/cpu.h

  Log Message:
  -----------
  i386: Split topology types of CPUID[0x1F] from the definitions of CPUID[0xB]

CPUID[0xB] defines SMT, Core and Invalid types, and this leaf is shared
by Intel and AMD CPUs.

But for extended topology levels, Intel CPU (in CPUID[0x1F]) and AMD CPU
(in CPUID[0x80000026]) have the different definitions with different
enumeration values.

Though CPUID[0x80000026] hasn't been implemented in QEMU, to avoid
possible misunderstanding, split topology types of CPUID[0x1F] from the
definitions of CPUID[0xB] and introduce CPUID[0x1F]-specific topology
types.

Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Babu Moger <babu.moger@amd.com>
Message-ID: <20240424154929.1487382-11-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 822bce9f58df7ab46f70abc9c350341d5280c91a
      
https://github.com/qemu/qemu/commit/822bce9f58df7ab46f70abc9c350341d5280c91a
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  i386/cpu: Decouple CPUID[0x1F] subleaf with specific topology level

At present, the subleaf 0x02 of CPUID[0x1F] is bound to the "die" level.

In fact, the specific topology level exposed in 0x1F depends on the
platform's support for extension levels (module, tile and die).

To help expose "module" level in 0x1F, decouple CPUID[0x1F] subleaf
with specific topology level.

Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Message-ID: <20240424154929.1487382-12-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 81c392ab5c7489955d7e2b515b7186a4cd174c71
      
https://github.com/qemu/qemu/commit/81c392ab5c7489955d7e2b515b7186a4cd174c71
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M hw/i386/x86-common.c
    M target/i386/cpu.c
    M target/i386/cpu.h

  Log Message:
  -----------
  i386: Introduce module level cpu topology to CPUX86State

Intel CPUs implement module level on hybrid client products (e.g.,
ADL-N, MTL, etc) and E-core server products.

A module contains a set of cores that share certain resources (in
current products, the resource usually includes L2 cache, as well as
module scoped features and MSRs).

Module level support is the prerequisite for L2 cache topology on
module level. With module level, we can implement the Guest's CPU
topology and future cache topology to be consistent with the Host's on
Intel hybrid client/E-core server platforms.

Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Co-developed-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
Signed-off-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Message-ID: <20240424154929.1487382-13-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 3568adc995b3906b5cc134753a829363f08bf6e1
      
https://github.com/qemu/qemu/commit/3568adc995b3906b5cc134753a829363f08bf6e1
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M hw/i386/x86.c
    M include/hw/i386/topology.h
    M target/i386/cpu.c
    M tests/unit/test-x86-topo.c

  Log Message:
  -----------
  i386: Support modules_per_die in X86CPUTopoInfo

Support module level in i386 cpu topology structure "X86CPUTopoInfo".

Since x86 does not yet support the "modules" parameter in "-smp",
X86CPUTopoInfo.modules_per_die is currently always 1.

Therefore, the module level width in APIC ID, which can be calculated by
"apicid_bitwidth_for_count(topo_info->modules_per_die)", is always 0 for
now, so we can directly add APIC ID related helpers to support module
level parsing.

In addition, update topology structure in test-x86-topo.c.

Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Co-developed-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
Signed-off-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Message-ID: <20240424154929.1487382-14-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 5304873acd12f7a4ddb07d3560ac5ac02a0e1060
      
https://github.com/qemu/qemu/commit/5304873acd12f7a4ddb07d3560ac5ac02a0e1060
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M hw/i386/x86-common.c
    M include/hw/i386/topology.h
    M target/i386/cpu.c
    M target/i386/cpu.h

  Log Message:
  -----------
  i386: Expose module level in CPUID[0x1F]

Linux kernel (from v6.4, with commit edc0a2b595765 ("x86/topology: Fix
erroneous smp_num_siblings on Intel Hybrid platforms") is able to
handle platforms with Module level enumerated via CPUID.1F.

Expose the module level in CPUID[0x1F] if the machine has more than 1
modules.

Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Message-ID: <20240424154929.1487382-15-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: b17a26bc4b0289ca7415f821bb0a89a8a333cea5
      
https://github.com/qemu/qemu/commit/b17a26bc4b0289ca7415f821bb0a89a8a333cea5
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M hw/i386/x86-common.c
    M hw/i386/x86.c
    M include/hw/i386/topology.h

  Log Message:
  -----------
  i386: Support module_id in X86CPUTopoIDs

Add module_id member in X86CPUTopoIDs.

module_id can be parsed from APIC ID, so also update APIC ID parsing
rule to support module level. With this support, the conversions with
module level between X86CPUTopoIDs, X86CPUTopoInfo and APIC ID are
completed.

module_id can be also generated from cpu topology, and before i386
supports "modules" in smp, the default "modules per die" (modules *
clusters) is only 1, thus the module_id generated in this way is 0,
so that it will not conflict with the module_id generated by APIC ID.

Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Signed-off-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
Co-developed-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Message-ID: <20240424154929.1487382-16-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 588208346f92e6030ae1d4bee94096ca0e070b60
      
https://github.com/qemu/qemu/commit/588208346f92e6030ae1d4bee94096ca0e070b60
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M hw/i386/x86-common.c
    M target/i386/cpu.c
    M target/i386/cpu.h

  Log Message:
  -----------
  i386/cpu: Introduce module-id to X86CPU

Introduce module-id to be consistent with the module-id field in
CpuInstanceProperties.

Following the legacy smp check rules, also add the module_id validity
into x86_cpu_pre_plug().

Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Co-developed-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
Signed-off-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Message-ID: <20240424154929.1487382-17-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 321d2599ebf9d27fbc41c672858048087f6a052d
      
https://github.com/qemu/qemu/commit/321d2599ebf9d27fbc41c672858048087f6a052d
  Author: Zhuocheng Ding <zhuocheng.ding@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M tests/unit/test-x86-topo.c

  Log Message:
  -----------
  tests: Add test case of APIC ID for module level parsing

After i386 supports module level, it's time to add the test for module
level's parsing.

Signed-off-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
Co-developed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Yanan Wang <wangyanan55@huawei.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20240424154929.1487382-18-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 6807487474165ddffd1016af1bf167e5c15e71bf
      
https://github.com/qemu/qemu/commit/6807487474165ddffd1016af1bf167e5c15e71bf
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M hw/i386/pc.c
    M qemu-options.hx

  Log Message:
  -----------
  hw/i386/pc: Support smp.modules for x86 PC machine

As module-level topology support is added to X86CPU, now we can enable
the support for the modules parameter on PC machines. With this support,
we can define a 5-level x86 CPU topology with "-smp":

-smp cpus=*,maxcpus=*,sockets=*,dies=*,modules=*,cores=*,threads=*.

So, add the 5-level topology example in description of "-smp".

Additionally, add the missed drawers and books options in previous
example.

Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Co-developed-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
Signed-off-by: Zhuocheng Ding <zhuocheng.ding@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Reviewed-by: Babu Moger <babu.moger@amd.com>
Message-ID: <20240424154929.1487382-19-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 9fcba76ab9c264d06394696c304f2462d9296918
      
https://github.com/qemu/qemu/commit/9fcba76ab9c264d06394696c304f2462d9296918
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/cpu.c
    M target/i386/cpu.h

  Log Message:
  -----------
  i386: Add cache topology info in CPUCacheInfo

Currently, by default, the cache topology is encoded as:
1. i/d cache is shared in one core.
2. L2 cache is shared in one core.
3. L3 cache is shared in one die.

This default general setting has caused a misunderstanding, that is, the
cache topology is completely equated with a specific cpu topology, such
as the connection between L2 cache and core level, and the connection
between L3 cache and die level.

In fact, the settings of these topologies depend on the specific
platform and are not static. For example, on Alder Lake-P, every
four Atom cores share the same L2 cache.

Thus, we should explicitly define the corresponding cache topology for
different cache models to increase scalability.

Except legacy_l2_cache_cpuid2 (its default topo level is
CPU_TOPO_LEVEL_UNKNOW), explicitly set the corresponding topology level
for all other cache models. In order to be compatible with the existing
cache topology, set the CPU_TOPO_LEVEL_CORE level for the i/d cache, set
the CPU_TOPO_LEVEL_CORE level for L2 cache, and set the
CPU_TOPO_LEVEL_DIE level for L3 cache.

The field for CPUID[4].EAX[bits 25:14] or CPUID[0x8000001D].EAX[bits
25:14] will be set based on CPUCacheInfo.share_level.

Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20240424154929.1487382-20-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: f602eb925ac5d51d09de6c4b32ba8a5142055492
      
https://github.com/qemu/qemu/commit/f602eb925ac5d51d09de6c4b32ba8a5142055492
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/cpu.c
    M target/i386/cpu.h

  Log Message:
  -----------
  i386/cpu: Use CPUCacheInfo.share_level to encode CPUID[4]

CPUID[4].EAX[bits 25:14] is used to represent the cache topology for
Intel CPUs.

After cache models have topology information, we can use
CPUCacheInfo.share_level to decide which topology level to be encoded
into CPUID[4].EAX[bits 25:14].

And since with the helper max_processor_ids_for_cache(), the filed
CPUID[4].EAX[bits 25:14] (original virable "num_apic_ids") is parsed
based on cpu topology levels, which are verified when parsing -smp, it's
no need to check this value by "assert(num_apic_ids > 0)" again, so
remove this assert().

Additionally, wrap the encoding of CPUID[4].EAX[bits 31:26] into a
helper to make the code cleaner.

Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Message-ID: <20240424154929.1487382-21-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 5eb608a13b2dfb772c831d02000a3514d1f137aa
      
https://github.com/qemu/qemu/commit/5eb608a13b2dfb772c831d02000a3514d1f137aa
  Author: Zhao Liu <zhao1.liu@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  i386/cpu: Use CPUCacheInfo.share_level to encode CPUID[0x8000001D].EAX[bits 
25:14]

CPUID[0x8000001D].EAX[bits 25:14] NumSharingCache: number of logical
processors sharing cache.

The number of logical processors sharing this cache is
NumSharingCache + 1.

After cache models have topology information, we can use
CPUCacheInfo.share_level to decide which topology level to be encoded
into CPUID[0x8000001D].EAX[bits 25:14].

Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Reviewed-by: Babu Moger <babu.moger@amd.com>
Message-ID: <20240424154929.1487382-22-zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 84d4b72854869821eb89813c195927fdd3078c12
      
https://github.com/qemu/qemu/commit/84d4b72854869821eb89813c195927fdd3078c12
  Author: donsheng <dongsheng.x.zhang@intel.com>
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
    M target/i386/kvm/hyperv.c

  Log Message:
  -----------
  target-i386: hyper-v: Correct kvm_hv_handle_exit return value

This bug fix addresses the incorrect return value of kvm_hv_handle_exit for
KVM_EXIT_HYPERV_SYNIC, which should be EXCP_INTERRUPT.

Handling of KVM_EXIT_HYPERV_SYNIC in QEMU needs to be synchronous.
This means that async_synic_update should run in the current QEMU vCPU
thread before returning to KVM, returning EXCP_INTERRUPT to guarantee this.
Returning 0 can cause async_synic_update to run asynchronously.

One problem (kvm-unit-tests's hyperv_synic test fails with timeout error)
caused by this bug:

When a guest VM writes to the HV_X64_MSR_SCONTROL MSR to enable Hyper-V SynIC,
a VM exit is triggered and processed by the kvm_hv_handle_exit function of the
QEMU vCPU. This function then calls the async_synic_update function to set
synic->sctl_enabled to true. A true value of synic->sctl_enabled is required
before creating SINT routes using the hyperv_sint_route_new() function.

If kvm_hv_handle_exit returns 0 for KVM_EXIT_HYPERV_SYNIC, the current QEMU
vCPU thread may return to KVM and enter the guest VM before running
async_synic_update. In such case, the hyperv_synic test’s subsequent call to
synic_ctl(HV_TEST_DEV_SINT_ROUTE_CREATE, ...) immediately after writing to
HV_X64_MSR_SCONTROL can cause QEMU’s hyperv_sint_route_new() function to return
prematurely (because synic->sctl_enabled is false).

If the SINT route is not created successfully, the SINT interrupt will not be
fired, resulting in a timeout error in the hyperv_synic test.

Fixes: 267e071bd6d6 (“hyperv: make overlay pages for SynIC”)
Suggested-by: Chao Gao <chao.gao@intel.com>
Signed-off-by: Dongsheng Zhang <dongsheng.x.zhang@intel.com>
Message-ID: <20240521200114.11588-1-dongsheng.x.zhang@intel.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


  Commit: 0eb285c3627b5406dd91bfa3b47402e5de92123f
      
https://github.com/qemu/qemu/commit/0eb285c3627b5406dd91bfa3b47402e5de92123f
  Author: Song Gao <gaosong@loongson.cn>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M target/loongarch/machine.c

  Log Message:
  -----------
  target/loongarch/kvm: Fix VM recovery from disk failures

vmstate does not save kvm_state_conter,
which can cause VM recovery from disk to fail.

Cc: qemu-stable@nongnu.org
Signed-off-by: Song Gao <gaosong@loongson.cn>
Acked-by: Peter Xu <peterx@redhat.com>
Message-Id: <20240508024732.3127792-1-gaosong@loongson.cn>


  Commit: 07c0866103d4aa2dd83c7c3e7898843e28e3893a
      
https://github.com/qemu/qemu/commit/07c0866103d4aa2dd83c7c3e7898843e28e3893a
  Author: Song Gao <gaosong@loongson.cn>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M target/loongarch/kvm/kvm.c

  Log Message:
  -----------
  target/loongarch/kvm: fpu save the vreg registers high 192bit

On kvm side, get_fpu/set_fpu save the vreg registers high 192bits,
but QEMU missing.

Cc: qemu-stable@nongnu.org
Signed-off-by: Song Gao <gaosong@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Message-Id: <20240514110752.989572-1-gaosong@loongson.cn>


  Commit: a7701b61f62ecef787ec4c64569bf5a1e892197c
      
https://github.com/qemu/qemu/commit/a7701b61f62ecef787ec4c64569bf5a1e892197c
  Author: Bibo Mao <maobibo@loongson.cn>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M hw/loongarch/virt.c

  Log Message:
  -----------
  hw/loongarch: Add VM mode in IOCSR feature register in kvm mode

If VM runs in kvm mode, VM mode is added in IOCSR feature register.
So guest can detect kvm hypervisor type and enable possible pv functions.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240514025109.3238398-1-maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>


  Commit: fc100011f38d2f58e2212a056173def3a7cf3512
      
https://github.com/qemu/qemu/commit/fc100011f38d2f58e2212a056173def3a7cf3512
  Author: Bibo Mao <maobibo@loongson.cn>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M hw/loongarch/acpi-build.c

  Log Message:
  -----------
  hw/loongarch: Refine acpi srat table for numa memory

One LoongArch virt machine platform, there is limitation for memory
map information. The minimum memory size is 256M and minimum memory
size for numa node0 is 256M also. With qemu numa qtest, it is possible
that memory size of numa node0 is 128M.

Limitations for minimum memory size for both total memory and numa
node0 is removed for acpi srat table creation.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240515093927.3453674-2-maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>


  Commit: 09ec65794f8e1a344ccb231b53e7c39b664f4fa8
      
https://github.com/qemu/qemu/commit/09ec65794f8e1a344ccb231b53e7c39b664f4fa8
  Author: Bibo Mao <maobibo@loongson.cn>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M hw/loongarch/virt.c

  Log Message:
  -----------
  hw/loongarch: Refine fadt memory table for numa memory

One LoongArch virt machine platform, there is limitation for memory
map information. The minimum memory size is 256M and minimum memory
size for numa node0 is 256M also. With qemu numa qtest, it is possible
that memory size of numa node0 is 128M.

Limitations for minimum memory size for both total memory and numa
node0 is removed for fadt numa memory table creation.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240515093927.3453674-3-maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>


  Commit: 3cc451cbcec746f2736bdc6b14acaf4936c83371
      
https://github.com/qemu/qemu/commit/3cc451cbcec746f2736bdc6b14acaf4936c83371
  Author: Bibo Mao <maobibo@loongson.cn>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M hw/loongarch/virt.c

  Log Message:
  -----------
  hw/loongarch: Refine fwcfg memory map

Memory map table for fwcfg is used for UEFI BIOS, UEFI BIOS uses the first
entry from fwcfg memory map as the first memory HOB, the second memory HOB
will be used if the first memory HOB is used up.

Memory map table for fwcfg does not care about numa node, however in
generic the first memory HOB is part of numa node0, so that runtime
memory of UEFI which is allocated from the first memory HOB is located
at numa node0.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240515093927.3453674-4-maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>


  Commit: 8d96788cb1fbaa361b29e98954e5254acf6d0435
      
https://github.com/qemu/qemu/commit/8d96788cb1fbaa361b29e98954e5254acf6d0435
  Author: Bibo Mao <maobibo@loongson.cn>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M hw/loongarch/virt.c

  Log Message:
  -----------
  hw/loongarch: Refine system dram memory region

For system dram memory region, it is not necessary to use numa node
information. There is only low memory region and high memory region.

Remove numa node information for ddr memory region here, it can reduce
memory region number on LoongArch virt machine.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240515093927.3453674-5-maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>


  Commit: ac551dbd586cd13a78d26933e2a9ee3b0867ccb0
      
https://github.com/qemu/qemu/commit/ac551dbd586cd13a78d26933e2a9ee3b0867ccb0
  Author: Bibo Mao <maobibo@loongson.cn>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M hw/loongarch/virt.c

  Log Message:
  -----------
  hw/loongarch: Remove minimum and default memory size

Some qtest test cases such as numa use default memory size of generic
machine class, which is 128M by fault.

Here generic default memory size is used, and also remove minimum memory
size which is 1G originally.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240515093927.3453674-6-maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>


  Commit: f83434f3dc6df21c890ff1537c47905eedf1d69c
      
https://github.com/qemu/qemu/commit/f83434f3dc6df21c890ff1537c47905eedf1d69c
  Author: Bibo Mao <maobibo@loongson.cn>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M target/loongarch/cpu.c

  Log Message:
  -----------
  target/loongarch: Add loongarch vector property unconditionally

Currently LSX/LASX vector property is decided by the default value.
Instead vector property should be added unconditionally, and it is
irrelative with its default value. If vector is disabled by default,
vector also can be enabled from command line.

Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240521080549.434197-2-maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>


  Commit: 6204af704a071ea68d3af55c0502b112a7af9546
      
https://github.com/qemu/qemu/commit/6204af704a071ea68d3af55c0502b112a7af9546
  Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M hw/loongarch/virt.c

  Log Message:
  -----------
  hw/loongarch/virt: Fix FDT memory node address width

Higher bits for memory nodes were omitted at qemu_fdt_setprop_cells.

Cc: qemu-stable@nongnu.org
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240520-loongarch-fdt-memnode-v1-1-5ea9be93911e@flygoat.com>
Signed-off-by: Song Gao <gaosong@loongson.cn>


  Commit: 50c3fc72b5428939a42b89e99986d7bfa18290de
      
https://github.com/qemu/qemu/commit/50c3fc72b5428939a42b89e99986d7bfa18290de
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M hw/loongarch/acpi-build.c
    M hw/loongarch/virt.c
    M target/loongarch/cpu.c
    M target/loongarch/kvm/kvm.c
    M target/loongarch/machine.c

  Log Message:
  -----------
  Merge tag 'pull-loongarch-20240523' of https://gitlab.com/gaosong/qemu into 
staging

pull-loongarch-20240523

# -----BEGIN PGP SIGNATURE-----
#
# iLMEAAEKAB0WIQS4/x2g0v3LLaCcbCxAov/yOSY+3wUCZk6fPgAKCRBAov/yOSY+
# 35rwA/98G/tODhR2PAl7qZr6+6z8vazkiT4iNNHgxnw/T2TKsh2YONe+2gtKhTa1
# HKYANMykWTxOtBZeCYY9Z5QNj8DuC3xKc1zY1pC1AwRcflsMlGz0WoAC78Gbl9TC
# PBCwyu01hsFoYpIstH/dOGbNsR2OFRLnnGUVFUKtPuS3O+59hg==
# =OzUv
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 22 May 2024 06:43:26 PM PDT
# gpg:                using RSA key B8FF1DA0D2FDCB2DA09C6C2C40A2FFF239263EDF
# gpg: Good signature from "Song Gao <m17746591750@163.com>" [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: B8FF 1DA0 D2FD CB2D A09C  6C2C 40A2 FFF2 3926 3EDF

* tag 'pull-loongarch-20240523' of https://gitlab.com/gaosong/qemu:
  hw/loongarch/virt: Fix FDT memory node address width
  target/loongarch: Add loongarch vector property unconditionally
  hw/loongarch: Remove minimum and default memory size
  hw/loongarch: Refine system dram memory region
  hw/loongarch: Refine fwcfg memory map
  hw/loongarch: Refine fadt memory table for numa memory
  hw/loongarch: Refine acpi srat table for numa memory
  hw/loongarch: Add VM mode in IOCSR feature register in kvm mode
  target/loongarch/kvm: fpu save the vreg registers high 192bit
  target/loongarch/kvm: Fix VM recovery from disk failures

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>


  Commit: 7b68a5fe2fc5e9e03616ff8da9b385ae698cbf0a
      
https://github.com/qemu/qemu/commit/7b68a5fe2fc5e9e03616ff8da9b385ae698cbf0a
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
    M hw/i386/pc.c
    M hw/i386/pc_piix.c
    M hw/i386/pc_q35.c
    M hw/i386/pc_sysfw.c
    M hw/i386/x86-common.c
    M hw/i386/x86.c
    M include/hw/i386/pc.h
    M include/hw/i386/topology.h
    M qemu-options.hx
    M target/i386/cpu.c
    M target/i386/cpu.h
    M target/i386/helper.c
    M target/i386/helper.h
    M target/i386/kvm/hyperv.c
    M target/i386/kvm/kvm.c
    M target/i386/tcg/decode-new.c.inc
    M target/i386/tcg/emit.c.inc
    M target/i386/tcg/int_helper.c
    M tests/unit/test-x86-topo.c

  Log Message:
  -----------
  Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging

* hw/i386/pc_sysfw: Alias rather than copy isa-bios region
* target/i386: add control bits support for LAM
* target/i386: tweaks to new translator
* target/i386: add support for LAM in CPUID enumeration
* hw/i386/pc: Support smp.modules for x86 PC machine
* target-i386: hyper-v: Correct kvm_hv_handle_exit return value

# -----BEGIN PGP SIGNATURE-----
#
# iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmZOMlAUHHBib256aW5p
# QHJlZGhhdC5jb20ACgkQv/vSX3jHroNTSwf8DOPgipepNcsxUQoV9nOBfNXqEWa6
# DilQGwuu/3eMSPITUCGKVrtLR5azwCwvNfYYErVBPVIhjImnk3XHwfKpH1csadgq
# 7Np8WGjAyKEIP/yC/K1VwsanFHv3hmC6jfcO3ZnsnlmbHsRINbvU9uMlFuiQkKJG
# lP/dSUcTVhwLT6eFr9DVDUnq4Nh7j3saY85pZUoDclobpeRLaEAYrawha1/0uQpc
# g7MZYsxT3sg9PIHlM+flpRvJNPz/ZDBdj4raN1xo4q0ET0KRLni6oEOVs5GpTY1R
# t4O8a/IYkxeI15K9U7i0HwYI2wVwKZbHgp9XPMYVZFJdKBGT8bnF56pV9A==
# =lp7q
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 22 May 2024 10:58:40 AM PDT
# gpg:                using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg:                issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full]
# gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>" [full]

* tag 'for-upstream' of https://gitlab.com/bonzini/qemu: (23 commits)
  target-i386: hyper-v: Correct kvm_hv_handle_exit return value
  i386/cpu: Use CPUCacheInfo.share_level to encode CPUID[0x8000001D].EAX[bits 
25:14]
  i386/cpu: Use CPUCacheInfo.share_level to encode CPUID[4]
  i386: Add cache topology info in CPUCacheInfo
  hw/i386/pc: Support smp.modules for x86 PC machine
  tests: Add test case of APIC ID for module level parsing
  i386/cpu: Introduce module-id to X86CPU
  i386: Support module_id in X86CPUTopoIDs
  i386: Expose module level in CPUID[0x1F]
  i386: Support modules_per_die in X86CPUTopoInfo
  i386: Introduce module level cpu topology to CPUX86State
  i386/cpu: Decouple CPUID[0x1F] subleaf with specific topology level
  i386: Split topology types of CPUID[0x1F] from the definitions of CPUID[0xB]
  i386/cpu: Introduce bitmap to cache available CPU topology levels
  i386/cpu: Consolidate the use of topo_info in cpu_x86_cpuid()
  i386/cpu: Use APIC ID info get NumSharingCache for CPUID[0x8000001D].EAX[bits 
25:14]
  i386/cpu: Use APIC ID info to encode cache topo in CPUID[4]
  i386/cpu: Fix i/d-cache topology to core level for Intel CPU
  target/i386: add control bits support for LAM
  target/i386: add support for LAM in CPUID enumeration
  ...

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>


Compare: https://github.com/qemu/qemu/compare/7e1c0047015f...7b68a5fe2fc5

To unsubscribe from these emails, change your notification settings at 
https://github.com/qemu/qemu/settings/notifications



reply via email to

[Prev in Thread] Current Thread [Next in Thread]