Re: [PATCH RFC v3 00/49] Add AMD Secure Nested Paging (SEV-SNP) support

[Ani Sinha]

> On 20 Mar 2024, at 14:08, Michael Roth  wrote:
> 
> These patches implement SEV-SNP base support along with CPUID enforcement
> support for QEMU, and are also available at:
> 
>  https://github.com/amdese/qemu/commits/snp-v3-rfc
> 
> they are based on top of the following patchset from Paolo:
> 
>  "[PATCH 0/7] target/i386: VM type infrastructure and KVM_SEV_INIT2 support"
>  https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg04663.html

Can you please also CC me on future revisions of this patchset? 

Thanks!


> 
> 
> Patch Layout
> 
> 
> 01-05: Various changes needed to handle new header files in kvm-next tree
>   and some hacks to get a functional header sync in place for building
>   this series.
> 06-18: These are patches directly plucked from Xiaoyao's TDX v5 patchset[1]
>   that implement common dependencies between SNP/TDX like base
>   guest_memfd, KVM_EXIT_MEMORY_FAULT handling (with a small FIXUP), and
>   mechanisms to disable SMM. We would've also needed some of the basic
>   infrastructure for handling specifying VM types for KVM_CREATE, but
>   much of that is now part of the sevinit2 series this patchset is based
>   on. Ideally all these patches, once stable, could be maintained in a
>   common tree so that future SNP/TDX patchsets can be more easily
>   iterated on/reviewed.
> 19-20: Patches introduced by this series that are  possible candidate for a
>   common tree.
>   shared/private pages when things like VFIO are in use.
> 21-32: Introduction of sev-snp-guest object and various configuration
>   requirements for SNP.
> 33-36: Handling for various KVM_EXIT_VMGEXIT events that are handled in
>   userspace.
> 37-49: Support for creating a cryptographic "launch" context and populating
>   various OVMF metadata pages, BIOS regions, and vCPU/VMSA pages with
>   the initial encrypted/measured/validated launch data prior to
>   launching the SNP guest.
> 
> 
> Testing
> ---
> 
> This series has been tested against the following host kernel tree, which
> is a snapshot of the latest WIP SNP hypervisor tree at the time of this
> posting. It will likely not be kept up to date afterward, so please keep an
> eye upstream or official AMDESE github if you are looking for the latest
> some time after this posting:
> 
>  https://github.com/mdroth/linux/commits/snp-host-v12-wip40/
> 
> A patched OVMF is also needed due to upstream KVM no longer supporting MMIO
> ranges that are mapped as private. It is recommended you build the AmdSevX64
> variant as it provides the kernel-hashing support present in this series:
> 
>  https://github.com/mdroth/edk2/commits/apic-mmio-fix1c/
> 
> A basic command-line invocation for SNP would be:
> 
> qemu-system-x86_64 -smp 32,maxcpus=255 -cpu EPYC-Milan-v2
>  -machine q35,confidential-guest-support=sev0,memory-backend=ram1
>  -object memory-backend-memfd,id=ram1,size=4G,share=true,reserve=false
>  -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,id-auth=
>  -bios /home/mroth/ovmf/OVMF_CODE-upstream-20240228-apicfix-1c-AmdSevX64.fd
> 
> With kernel-hashing and certificate data supplied:
> 
> qemu-system-x86_64 -smp 32,maxcpus=255 -cpu EPYC-Milan-v2
>  -machine q35,confidential-guest-support=sev0,memory-backend=ram1
>  -object memory-backend-memfd,id=ram1,size=4G,share=true,reserve=false
>  -object 
> sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,id-auth=,certs-path=/home/mroth/cert.blob,kernel-hashes=on
>  -bios /home/mroth/ovmf/OVMF_CODE-upstream-20240228-apicfix-1c-AmdSevX64.fd
>  -kernel /boot/vmlinuz-6.8.0-snp-host-v12-wip40+
>  -initrd /boot/initrd.img-6.8.0-snp-host-v12-wip40+
>  -append "root=UUID=d72a6d1c-06cf-4b79-af43-f1bac4f620f9 ro 
> console=ttyS0,115200n8"
> 
> Any comments/feedback would be very much appreciated.
> 
> [1] https://github.com/amdese/linux
>https://github.com/amdese/amdsev/tree/snp-latest
> 
> Changes since rfc2:
> 
> - reworked on top of guest_memfd support
> - added handling for various KVM_EXIT_VMGEXIT events
> - various changes/considerations for PCI passthrough support
> - general bugfixes/hardening/cleanups
> - qapi cmdline doc fixes/rework (Dov, Markus)
> - switch to qbase64_decode, more error-checking for cmdline opts (Dov)
> - unset id_block_en for 0 input (Dov)
> - use error_setg in snp init (Dov)
> - report more info in trace_kvm_sev_init (Dov)
> - rework bounds-checking for kvm_cpuid_info, rework existing checks for 
> readability, add additional checks (Dov)
> - fixups for validated_ranges handling (Dov)
> - rename 'policy' field to 'snp-policy' in query-sev when sev-type is SNP
> 
> Changes since rfc1:
> 
> - rebased onto latest master
> - drop SNP config file in favor of a new 'sev-snp-guest' object where all
>   SNP-related params are passed as strings/integers via command-line
> - report specific error if BIOS reports invalid address/len for
>   reserved/pre-validated regions (Connor)
> - use Range helpers 

Re: [PATCH v2 06/10] i386/pc_sysfw: Ensure sysfw flash configuration does not conflict with IGVM

[Ani Sinha]

> On 3 Apr 2024, at 16:41, Roy Hopkins  wrote:
> 
> When using an IGVM file the configuration of the system firmware is
> defined by IGVM directives contained in the file. In this case the user
> should not configure any pflash devices.
> 
> This commit skips initialization of the ROM mode when pflash0 is not set
> then checks to ensure no pflash devices have been configured when using
> IGVM, exiting with an error message if this is not the case.
> 
> Signed-off-by: Roy Hopkins 
> ---
> hw/i386/pc_sysfw.c | 23 +--
> 1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
> index 3efabbbab2..2412f26225 100644
> --- a/hw/i386/pc_sysfw.c
> +++ b/hw/i386/pc_sysfw.c
> @@ -226,8 +226,13 @@ void pc_system_firmware_init(PCMachineState *pcms,
> }
> 
> if (!pflash_blk[0]) {
> -/* Machine property pflash0 not set, use ROM mode */
> -x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, false);
> +/*
> + * Machine property pflash0 not set, use ROM mode unless using IGVM,
> + * in which case the firmware must be provided by the IGVM file.

What if the igvm file does not contain a firmware? Can we have a check for that 
case somewhere and assert if firmware is absent?

> + */
> +if (!cgs_is_igvm(MACHINE(pcms)->cgs)) {
> +x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, false);
> +}
> } else {
> if (kvm_enabled() && !kvm_readonly_mem_enabled()) {
> /*
> @@ -243,6 +248,20 @@ void pc_system_firmware_init(PCMachineState *pcms,
> }
> 
> pc_system_flash_cleanup_unused(pcms);
> +
> +/*
> + * The user should not have specified any pflash devices when using IGVM
> + * to configure the guest.
> + */
> +if (cgs_is_igvm(MACHINE(pcms)->cgs)) {
> +for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
> +if (pcms->flash[i]) {
> +error_report("pflash devices cannot be configured when "
> + "using IGVM");
> +exit(1);
> +}
> +}
> +}

I have not tested this change but looking at pc_system_flash_create() creates 
flash[0] and flash[1] for all cases (well except for isapc machines). So for 
igvm case, would this not cause an exit all the time?

> }
> 
> void x86_firmware_configure(void *ptr, int size)
> -- 
> 2.43.0
> 

Re: [PATCH 6/9] i386/pc: Skip initialization of system FW when using IGVM

[Ani Sinha]

> On 28 Mar 2024, at 16:04, Ani Sinha  wrote:
> 
> 
> 
>> On 27 Mar 2024, at 19:43, Roy Hopkins  wrote:
>> 
>> On Wed, 2024-03-27 at 18:58 +0530, Ani Sinha wrote:
>>> 
>>> 
>>>> On 27 Feb 2024, at 20:20, Roy Hopkins  wrote:
>>>> 
>>>> When using an IGVM file the configuration of the system firmware is
>>>> defined by IGVM directives contained in the file. Therefore the default
>>>> system firmware should not be initialized when an IGVM file has been
>>>> provided.
>>>> 
>>>> This commit checks to see if an IGVM file has been provided and, if it
>>>> has then the standard system firmware initialization is skipped and any
>>>> prepared flash devices are cleaned up.
>>>> 
>>>> Signed-off-by: Roy Hopkins 
>>>> ---
>>>> hw/i386/pc.c | 12 ++--
>>>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>>> index f8eb684a49..17bb211708 100644
>>>> --- a/hw/i386/pc.c
>>>> +++ b/hw/i386/pc.c
>>>> @@ -63,6 +63,7 @@
>>>> #include "e820_memory_layout.h"
>>>> #include "trace.h"
>>>> #include CONFIG_DEVICES
>>>> +#include "exec/confidential-guest-support.h"
>>>> 
>>>> #ifdef CONFIG_XEN_EMU
>>>> #include "hw/xen/xen-legacy-backend.h"
>>>> @@ -1023,8 +1024,15 @@ void pc_memory_init(PCMachineState *pcms,
>>>>}
>>>>}
>>>> 
>>>> -/* Initialize PC system firmware */
>>>> -pc_system_firmware_init(pcms, rom_memory);
>>>> +/*
>>>> + * If this is a confidential guest configured using IGVM then the IGVM
>>>> + * configuration will include the system firmware. In this case do not
>>>> + * initialise PC system firmware.
>>>> + */
>>>> +if (!cgs_is_igvm(machine->cgs)) {
>>>> +/* Initialize PC system firmware */
>>>> +pc_system_firmware_init(pcms, rom_memory);
>>>> +}
>>> 
>>> Ok so this makes QEMU mot load the default fw as provided in the QEMU 
>>> command
>>> line. It does not specify how the packaged fw specified within IGVM would be
>>> processed and loaded. Am I understanding this right?
>>> 
>> Yes. Although as suggested by Daniel, I've now changed this so if firmware is
>> specified on the command line in conflict with the IGVM file then an error is
>> displayed.
> 
> Does IGVM _must_ mandatorily contain a firmware? If not, then before error is 
> displayed, we should check if the file does have a firmware.
> 
>> The IGVM file itself describes how the firmware binary is populated
>> into guest memory and launched.
> 
> Ok so I looked at the doc here: https://docs.rs/igvm_defs/0.1.7/igvm_defs/
> I do not see anything related to firmware in the spec.
> Secondly, how the firmware is to be loaded is hypervisor specific. So there 
> must be QEMU specific implementation to load the firmware from IGVM. 
> Secondly, should a new directive (and associated definitions) be introduced 
> that instructs hypervisors to load the firmware present in IGVM?
> Something is missing here it seems and I am willing to dive into filling the 
> missing parts.

I guess what I was missing was 
https://github.com/roy-hopkins/buildigvm/blob/main/src/ovmf_firmware.rs . 
Seems something like this is supposed to load ovmf image into memory.

Re: [PATCH 6/9] i386/pc: Skip initialization of system FW when using IGVM

[Ani Sinha]

> On 27 Mar 2024, at 19:43, Roy Hopkins  wrote:
> 
> On Wed, 2024-03-27 at 18:58 +0530, Ani Sinha wrote:
>> 
>> 
>>> On 27 Feb 2024, at 20:20, Roy Hopkins  wrote:
>>> 
>>> When using an IGVM file the configuration of the system firmware is
>>> defined by IGVM directives contained in the file. Therefore the default
>>> system firmware should not be initialized when an IGVM file has been
>>> provided.
>>> 
>>> This commit checks to see if an IGVM file has been provided and, if it
>>> has then the standard system firmware initialization is skipped and any
>>> prepared flash devices are cleaned up.
>>> 
>>> Signed-off-by: Roy Hopkins 
>>> ---
>>> hw/i386/pc.c | 12 ++--
>>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>> index f8eb684a49..17bb211708 100644
>>> --- a/hw/i386/pc.c
>>> +++ b/hw/i386/pc.c
>>> @@ -63,6 +63,7 @@
>>> #include "e820_memory_layout.h"
>>> #include "trace.h"
>>> #include CONFIG_DEVICES
>>> +#include "exec/confidential-guest-support.h"
>>> 
>>> #ifdef CONFIG_XEN_EMU
>>> #include "hw/xen/xen-legacy-backend.h"
>>> @@ -1023,8 +1024,15 @@ void pc_memory_init(PCMachineState *pcms,
>>> }
>>> }
>>> 
>>> -/* Initialize PC system firmware */
>>> -pc_system_firmware_init(pcms, rom_memory);
>>> +/*
>>> + * If this is a confidential guest configured using IGVM then the IGVM
>>> + * configuration will include the system firmware. In this case do not
>>> + * initialise PC system firmware.
>>> + */
>>> +if (!cgs_is_igvm(machine->cgs)) {
>>> +/* Initialize PC system firmware */
>>> +pc_system_firmware_init(pcms, rom_memory);
>>> +}
>> 
>> Ok so this makes QEMU mot load the default fw as provided in the QEMU command
>> line. It does not specify how the packaged fw specified within IGVM would be
>> processed and loaded. Am I understanding this right?
>>  
> Yes. Although as suggested by Daniel, I've now changed this so if firmware is
> specified on the command line in conflict with the IGVM file then an error is
> displayed.

Does IGVM _must_ mandatorily contain a firmware? If not, then before error is 
displayed, we should check if the file does have a firmware.

> The IGVM file itself describes how the firmware binary is populated
> into guest memory and launched.

Ok so I looked at the doc here: https://docs.rs/igvm_defs/0.1.7/igvm_defs/
I do not see anything related to firmware in the spec.
Secondly, how the firmware is to be loaded is hypervisor specific. So there 
must be QEMU specific implementation to load the firmware from IGVM. Secondly, 
should a new directive (and associated definitions) be introduced that 
instructs hypervisors to load the firmware present in IGVM?
Something is missing here it seems and I am willing to dive into filling the 
missing parts.
 

> 

Re: [PATCH 6/9] i386/pc: Skip initialization of system FW when using IGVM

[Ani Sinha]

> On 27 Feb 2024, at 20:20, Roy Hopkins  wrote:
> 
> When using an IGVM file the configuration of the system firmware is
> defined by IGVM directives contained in the file. Therefore the default
> system firmware should not be initialized when an IGVM file has been
> provided.
> 
> This commit checks to see if an IGVM file has been provided and, if it
> has then the standard system firmware initialization is skipped and any
> prepared flash devices are cleaned up.
> 
> Signed-off-by: Roy Hopkins 
> ---
> hw/i386/pc.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index f8eb684a49..17bb211708 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -63,6 +63,7 @@
> #include "e820_memory_layout.h"
> #include "trace.h"
> #include CONFIG_DEVICES
> +#include "exec/confidential-guest-support.h"
> 
> #ifdef CONFIG_XEN_EMU
> #include "hw/xen/xen-legacy-backend.h"
> @@ -1023,8 +1024,15 @@ void pc_memory_init(PCMachineState *pcms,
> }
> }
> 
> -/* Initialize PC system firmware */
> -pc_system_firmware_init(pcms, rom_memory);
> +/*
> + * If this is a confidential guest configured using IGVM then the IGVM
> + * configuration will include the system firmware. In this case do not
> + * initialise PC system firmware.
> + */
> +if (!cgs_is_igvm(machine->cgs)) {
> +/* Initialize PC system firmware */
> +pc_system_firmware_init(pcms, rom_memory);
> +}

Ok so this makes QEMU mot load the default fw as provided in the QEMU command 
line. It does not specify how the packaged fw specified within IGVM would be 
processed and loaded. Am I understanding this right?
 

Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

[Ani Sinha]

> On 26 Mar 2024, at 18:21, Igor Mammedov  wrote:
> 
> ISAPC machine was introduced 25 years ago and it's a lot of time since
> such machine was around with real ISA only PC hardware practically defunct.
> Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host
> in only TCG mode, while in KVM mode it hung in the middle of boot)
> 
> Rather than spending time on fixing 'the oldest' no longer tested machine 
> type,
> deprecate it so we can clean up QEMU code from legacy fixups and hopefully
> make it easier to follow.
> 
> Folks who have to use ancient guest that requires ISAPC can still
> use older QEMU to play with it.
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
> docs/about/deprecated.rst | 7 +++
> hw/i386/pc_piix.c | 1 +
> 2 files changed, 8 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 7b548519b5..5708296991 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -226,6 +226,13 @@ These old machine types are quite neglected nowadays and 
> thus might have
> various pitfalls with regards to live migration. Use a newer machine type
> instead.
> 
> +``isapc`` (since 9.0)
> +'
> +
> +These old machine type are quite neglected nowadays and thus might have
> +various pitfalls with regards to live migration. Use a newer machine type
> +instead.
> +
> Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2)
> '''
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 18ba076609..96f72384dd 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -921,6 +921,7 @@ static void isapc_machine_options(MachineClass *m)
> m->default_nic = "ne2k_isa";
> m->default_cpu_type = X86_CPU_TYPE_NAME("486");
> m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
> +m->deprecation_reason = "old and unattended - use a newer version 
> instead";
> }
> 
> DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
> -- 
> 2.43.0
> ___
> Devel mailing list -- de...@lists.libvirt.org
> To unsubscribe send an email to devel-le...@lists.libvirt.org

Re: [PATCH 0/9] Introduce support for IGVM files

[Ani Sinha]

> On 27 Feb 2024, at 20:20, Roy Hopkins  wrote:
> 
> Hi everyone,
> 
> This initial patch series submission adds the capability to configure
> confidential guests using files that conform to the Independent Guest Virtual
> Machine (IGVM) file format. The series is based on the master branch commit
> 1b330da. Alternatively, the series is available here:
> https://github.com/roy-hopkins/qemu/tree/igvm_master_v1
> 
> I look forward to welcoming your comments!
> 
> Why do we need Independent Guest Virtual Machine (IGVM) files?
> ==
> 
> IGVM files describe, using a set of directives, the memory layout and initial
> configuration of a guest that supports isolation technologies such as AMD
> SEV-SNP and Intel TDX. By encapsulating all of this information in a single
> configuration file and applying the directives in the order they are specified
> when the guest is initialized, it becomes straightforward to pre-calculate the
> cryptographic measurement of the guest initial state, thus aiding in remote
> attestation processes.
> 
> IGVM files can also be used to configure non-standard guest memory layouts,
> payloads or startup configurations. A good example of this is to use IGVM to
> deploy and configure an SVSM module in the guest which supports running at
> multiple VMPLs. The SVSM can be configured to start directly into 32-bit or
> 64-bit code. This patch series was developed with this purpose in mind to
> support the COCONUT-SVSM project:
> https://github.com/coconut-svsm/svsm
> 
> More information and background on the IGVM file format can be found on the
> project page at:
> https://github.com/microsoft/igvm
> 
> What this patch series introduces
> =
> 
> This series adds a build-time configuration option (--enable-igvm) to add
> support for launching a guest using an IGVM file. It extends the current
> ConfidentialGuestSupport object to allow an IGVM filename to be specified.
> 
> The directives in the IGVM file are parsed and the confidential guest is
> configured through new virtual methods added to the ConfidentialGuestSupport
> object. These virtual functions have been implemented for AMD SEV and AMD
> SEV-ES.
> 
> Many of the IGVM directives require capabilities that are not supported in SEV
> and SEV-ES, so support for IGVM directives will need to be considered when
> support for SEV-SNP, TDX or other technologies is introduced to QEMU. Any
> directive that is not currently supported results in an error report.
> 
> Dependencies
> 
> 
> In order to enable IGVM support, you will need the IGVM library installed.
> Instructions on building and installing it can be found here:
> https://github.com/microsoft/igvm/tree/main/igvm_c
> 
> As mentioned above, this series was developed as part of the effort for
> COCONUT-SVSM. COCONUT-SVSM requires support for AMD SEV-SNP which is not
> available in current QEMU. Therefore this series has also been applied on top 
> of
> the AMD SEV-SNP branch (https://github.com/AMDESE/qemu/tree/snp-v3-wip). You 
> can
> find that version of the series here:
> https://github.com/roy-hopkins/qemu/commits/snp-v3-wip-igvm_v2/
> 
> Generating IGVM files
> =
> 
> To try this out you will need to generate an IGVM file that is compatible with
> the SEV platform you are testing on. I've created a tool that can create a
> simple IGVM file that packages an OVMF binary for AMD SEV or AMD SEV-ES. The
> tool is available here:
> https://github.com/roy-hopkins/buildigvm
> 
> I have tested this on an AMD EPYC Genoa system configured to support SEV. Both
> SEV and SEV-ES have been tested using IGVM files generated using the buildigvm
> tool. The SEV-SNP alternative patch set has also been tested using 
> COCONUT-SVSM.

Could you please also CC me in this patchset please? Thanks.

> 
> Roy Hopkins (9):
>  meson: Add optional dependency on IGVM library
>  backends/confidential-guest-support: Add IGVM file parameter
>  backends/confidential-guest-support: Add functions to support IGVM
>  backends/igvm: Implement parsing and processing of IGVM files
>  i386/pc: Process IGVM file during PC initialization if present
>  i386/pc: Skip initialization of system FW when using IGVM
>  i386/sev: Refactor setting of reset vector and initial CPU state
>  i386/sev: Implement ConfidentialGuestSupport functions for SEV
>  docs/system: Add documentation on support for IGVM
> 
> backends/confidential-guest-support.c |  69 +++
> backends/igvm.c   | 718 ++
> backends/meson.build  |   4 +
> docs/system/igvm.rst  |  58 ++
> docs/system/index.rst |   1 +
> hw/i386/pc.c  |  12 +-
> hw/i386/pc_piix.c |   4 +
> hw/i386/pc_q35.c  |   4 +
> include/exec/confidential-guest-support.h | 107 
> 

Re: [PATCH] SMBIOS: fix long lines

[Ani Sinha]

> On 13-Mar-2024, at 03:59, Michael S. Tsirkin  wrote:
> 
> Break up long lines to fit under 80/90 char limit.
> 
> Signed-off-by: Michael S. Tsirkin 

Reviewed-by: Ani Sinha 

> ---
> hw/smbios/smbios.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index e3d5d8f2e2..949c2d74a1 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -1592,12 +1592,15 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
> t = g_new0(struct type9_instance, 1);
> save_opt(>slot_designation, opts, "slot_designation");
> t->slot_type = qemu_opt_get_number(opts, "slot_type", 0);
> -t->slot_data_bus_width = qemu_opt_get_number(opts, 
> "slot_data_bus_width", 0);
> +t->slot_data_bus_width =
> +qemu_opt_get_number(opts, "slot_data_bus_width", 0);
> t->current_usage = qemu_opt_get_number(opts, "current_usage", 0);
> t->slot_length = qemu_opt_get_number(opts, "slot_length", 0);
> t->slot_id = qemu_opt_get_number(opts, "slot_id", 0);
> -t->slot_characteristics1 = qemu_opt_get_number(opts, 
> "slot_characteristics1", 0);
> -t->slot_characteristics2 = qemu_opt_get_number(opts, 
> "slot_characteristics2", 0);
> +t->slot_characteristics1 =
> +qemu_opt_get_number(opts, "slot_characteristics1", 0);
> +t->slot_characteristics2 =
> +qemu_opt_get_number(opts, "slot_characteristics2", 0);
> save_opt(>pcidev, opts, "pcidev");
> QTAILQ_INSERT_TAIL(, t, next);
> return;
> -- 
> MST
> 

Re: [PATCH v5] pc: q35: Bump max_cpus to 4096 vcpus

[Ani Sinha]

> On 28-Feb-2024, at 20:03, Ani Sinha  wrote:
> 
> Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow 
> up to 4096 vCPUs")
> Linux kernel can support upto a maximum number of 4096 vcpus when MAXSMP is
> enabled in the kernel. At present, QEMU has been tested to correctly boot a
> linux guest with 4096 vcpus using the current edk2 upstream master branch that
> has the fixes corresponding to the following two PRs:
> 
> https://github.com/tianocore/edk2/pull/5410
> https://github.com/tianocore/edk2/pull/5418
> 
> The changes merged into edk2 with the above PRs will be in the upcoming 
> 2024-05
> release. With current seabios firmware, it boots fine with 4096 vcpus already.
> So bump up the value max_cpus to 4096 for q35 machines versions 9 and newer.
> Q35 machines versions 8.2 and older continue to support 1024 maximum vcpus
> as before for compatibility reasons.
> 
> If KVM is not able to support the specified number of vcpus, QEMU would
> return the following error messages:
> 
> $ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 1728
> qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (1728) 
> exceeds the recommended cpus supported by KVM (12)
> qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus 
> requested (1728) exceeds the recommended cpus supported by KVM (12)
> Number of SMP cpus requested (1728) exceeds the maximum cpus supported by KVM 
> (1024)
> 
> Cc: Daniel P. Berrangé 
> Cc: Igor Mammedov 
> Cc: Michael S. Tsirkin 
> Cc: Julia Suvorova 
> Cc: kra...@redhat.com
> Reviewed-by: Daniel P. Berrangé 
> Reviewed-by: Igor Mammedov 
> Reviewed-by: Gerd Hoffmann 
> Signed-off-by: Ani Sinha 

Ping .. who is picking this up? The soft code freeze starts today?

> ---
> hw/i386/pc_q35.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Changelog:
> v5: mention the PRs in the commit message. Add tags.
> v4: tweaked commit message as per suggestion from danpb explicitly
> stating that 4096 vcpus work with edk2 fixes that are going to be
> available in the coming edk2 release.
> v3: bump up to 4096 vcpus. It has now been tested to work with edk2.
> See RH Jira: https://issues.redhat.com/browse/RHEL-22202
> v2: bump up the vcpu number to 1856. Add failure messages from ekd2 in
> the commit description.
> 
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 45a4102e75..df63a92b78 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -350,7 +350,7 @@ static void pc_q35_machine_options(MachineClass *m)
> m->default_nic = "e1000e";
> m->default_kernel_irqchip_split = false;
> m->no_floppy = 1;
> -m->max_cpus = 1024;
> +m->max_cpus = 4096;
> m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
> machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
> machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
> @@ -371,6 +371,7 @@ static void pc_q35_8_2_machine_options(MachineClass *m)
> {
> pc_q35_9_0_machine_options(m);
> m->alias = NULL;
> +m->max_cpus = 1024;
> compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
> compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
> }
> -- 
> 2.42.0
> 

[PATCH] docs: update copyright date to the year 2024

[Ani Sinha]

We are already in the third month of 2024 but the copyright notices still refer
to 2023. Update the date to 2024 in documentation and help texts.

Cc: peter.mayd...@linaro.org
Cc: qemu-triv...@nongnu.org
Signed-off-by: Ani Sinha 
---
 docs/conf.py  | 2 +-
 include/qemu/help-texts.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/conf.py b/docs/conf.py
index 1b2afa241c..aae0304ac6 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -88,7 +88,7 @@
 
 # General information about the project.
 project = u'QEMU'
-copyright = u'2023, The QEMU Project Developers'
+copyright = u'2024, The QEMU Project Developers'
 author = u'The QEMU Project Developers'
 
 # The version info for the project you're documenting, acts as replacement for
diff --git a/include/qemu/help-texts.h b/include/qemu/help-texts.h
index d0359f82e0..353ab2ad8b 100644
--- a/include/qemu/help-texts.h
+++ b/include/qemu/help-texts.h
@@ -2,7 +2,7 @@
 #define QEMU_HELP_TEXTS_H
 
 /* Copyright string for -version arguments, About dialogs, etc */
-#define QEMU_COPYRIGHT "Copyright (c) 2003-2023 " \
+#define QEMU_COPYRIGHT "Copyright (c) 2003-2024 " \
 "Fabrice Bellard and the QEMU Project developers"
 
 /* Bug reporting information for --help arguments, About dialogs, etc */
-- 
2.39.2

Re: [PATCH v2 07/20] smbios: avoid mangling user provided tables

[Ani Sinha]

> On 08-Mar-2024, at 22:49, Igor Mammedov  wrote:
> 
> On Thu, 7 Mar 2024 09:33:17 +0530
> Ani Sinha  wrote:
> 
>>> On 06-Mar-2024, at 12:11, Ani Sinha  wrote:
>>> 
>>> 
>>> 
>>> On Tue, 5 Mar 2024, Igor Mammedov wrote:
>>> 
>>>> currently smbios_entry_add() preserves internally '-smbios type='
>>>> options but tables provided with '-smbios file=' are stored directly
>>>> into blob that eventually will be exposed to VM. And then later
>>>> QEMU adds default/'-smbios type' entries on top into the same blob.
>>>> 
>>>> It makes impossible to generate tables more than once, hence
>>>> 'immutable' guard was used.
>>>> Make it possible to regenerate final blob by storing user provided
>>>> blobs into a dedicated area (usr_blobs) and then copy it when
>>>> composing final blob. Which also makes handling of -smbios
>>>> options consistent.
>>>> 
>>>> As side effect of this and previous commits there is no need to
>>>> generate legacy smbios_entries at the time options are parsed.
>>>> Instead compose smbios_entries on demand from  usr_blobs like
>>>> it is done for non-legacy SMBIOS tables.
>>>> 
>>>> Signed-off-by: Igor Mammedov 
>>>> Tested-by: Fiona Ebner   
>>> 
>>> Reviewed-by: Ani Sinha 
>>> 
>>>> ---
>>>> hw/smbios/smbios.c | 179 +++--
>>>> 1 file changed, 92 insertions(+), 87 deletions(-)
>>>> 
>>>> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
>>>> index c46fc93357..aa2cc5bdbd 100644
>>>> --- a/hw/smbios/smbios.c
>>>> +++ b/hw/smbios/smbios.c
>>>> @@ -57,6 +57,14 @@ static size_t smbios_entries_len;
>>>> static bool smbios_uuid_encoded = true;
>>>> /* end: legacy structures & constants for <= 2.0 machines */
>>>> 
>>>> +/*
>>>> + * SMBIOS tables provided by user with '-smbios file=' option
>>>> + */
>>>> +uint8_t *usr_blobs;
>>>> +size_t usr_blobs_len;
>>>> +static GArray *usr_blobs_sizes;
>>>> +static unsigned usr_table_max;
>>>> +static unsigned usr_table_cnt;
>>>> 
>>>> uint8_t *smbios_tables;
>>>> size_t smbios_tables_len;
>>>> @@ -67,7 +75,6 @@ static SmbiosEntryPointType smbios_ep_type = 
>>>> SMBIOS_ENTRY_POINT_TYPE_32;
>>>> static SmbiosEntryPoint ep;
>>>> 
>>>> static int smbios_type4_count = 0;
>>>> -static bool smbios_immutable;
>>>> static bool smbios_have_defaults;
>>>> static uint32_t smbios_cpuid_version, smbios_cpuid_features;
>>>> 
>>>> @@ -569,9 +576,8 @@ static void smbios_build_type_1_fields(void)
>>>> 
>>>> uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t 
>>>> *length)
>>>> {
>>>> -/* drop unwanted version of command-line file blob(s) */
>>>> -g_free(smbios_tables);
>>>> -smbios_tables = NULL;
>>>> +int i;
>>>> +size_t usr_offset;
>>>> 
>>>>/* also complain if fields were given for types > 1 */
>>>>if (find_next_bit(have_fields_bitmap,
>>>> @@ -581,12 +587,33 @@ uint8_t *smbios_get_table_legacy(uint32_t 
>>>> expected_t4_count, size_t *length)
>>>>exit(1);
>>>>}
>>>> 
>>>> -if (!smbios_immutable) {
>>>> -smbios_build_type_0_fields();
>>>> -smbios_build_type_1_fields();
>>>> -smbios_validate_table(expected_t4_count);
>>>> -smbios_immutable = true;
>>>> +g_free(smbios_entries);
>>>> +smbios_entries_len = sizeof(uint16_t);
>>>> +smbios_entries = g_malloc0(smbios_entries_len);
>>>> +
>>>> +for (i = 0, usr_offset = 0; usr_blobs_sizes && i < 
>>>> usr_blobs_sizes->len;
>>>> + i++)
>>>> +{
>>>> +struct smbios_table *table;
>>>> +struct smbios_structure_header *header;
>>>> +size_t size = g_array_index(usr_blobs_sizes, size_t, i);
>>>> +
>>>> +header = (struct smbios_structure_header *)(usr_blobs + 
>>>> usr_offset);
>>>> +smbios_entries = g_realloc(smbios_entries, smbios_entries_len +
>>>> +

[PATCH v2] docs/acpi/bits: add some clarity and details while also improving formating

[Ani Sinha]

Update bios-bits docs to add more details on why a pre-OS environment for
testing bioses is useful. Add author's FOSDEM talk link. Also improve the
formating of the document while at it.

CC: qemu-triv...@nongnu.org
Signed-off-by: Ani Sinha 
---
 docs/devel/acpi-bits.rst | 55 
 1 file changed, 39 insertions(+), 16 deletions(-)

changelog:
v2: commit message improvement.

diff --git a/docs/devel/acpi-bits.rst b/docs/devel/acpi-bits.rst
index 9677b0098f..1ec394f5fb 100644
--- a/docs/devel/acpi-bits.rst
+++ b/docs/devel/acpi-bits.rst
@@ -1,26 +1,48 @@
 =
 ACPI/SMBIOS avocado tests using biosbits
 =
-
+
+Introduction
+
 Biosbits is a software written by Josh Triplett that can be downloaded
 from https://biosbits.org/. The github codebase can be found
-`here <https://github.com/biosbits/bits/tree/master>`__. It is a software that 
executes
-the bios components such as acpi and smbios tables directly through acpica
-bios interpreter (a freely available C based library written by Intel,
+`here <https://github.com/biosbits/bits/tree/master>`__. It is a software that
+executes the bios components such as acpi and smbios tables directly through
+acpica bios interpreter (a freely available C based library written by Intel,
 downloadable from https://acpica.org/ and is included with biosbits) without an
-operating system getting involved in between.
+operating system getting involved in between. Bios-bits has python integration
+with grub so actual routines that executes bios components can be written in
+python instead of bash-ish (grub's native scripting language).
 There are several advantages to directly testing the bios in a real physical
-machine or VM as opposed to indirectly discovering bios issues through the
-operating system. For one thing, the OSes tend to hide bios problems from the
-end user. The other is that we have more control of what we wanted to test
-and how by directly using acpica interpreter on top of the bios on a running
-system. More details on the inspiration for developing biosbits and its real
-life uses can be found in [#a]_ and [#b]_.
+machine or in a VM as opposed to indirectly discovering bios issues through the
+operating system (the OS). Operating systems tend to bypass bios problems and
+hide them from the end user. We have more control of what we wanted to test and
+how by being as close to the bios on a running system as possible without a
+complicated software component such as an operating system coming in between.
+Another issue is that we cannot exercise bios components such as ACPI and
+SMBIOS without being in the highest hardware privilege level, ring 0 for
+example in case of x86. Since the OS executes from ring 0 whereas normal user
+land software resides in unprivileged ring 3, operating system must be modified
+in order to write our test routines that exercise and test the bios. This is
+not possible in all cases. Lastly, test frameworks and routines are preferably
+written using a high level scripting language such as python. OSes and
+OS modules are generally written using low level languages such as C and
+low level assembly machine language. Writing test routines in a low level
+language makes things more cumbersome. These and other reasons makes using
+bios-bits very attractive for testing bioses. More details on the inspiration
+for developing biosbits and its real life uses can be found in [#a]_ and [#b]_.
+
 For QEMU, we maintain a fork of bios bits in gitlab along with all the
-dependent submodules here: https://gitlab.com/qemu-project/biosbits-bits
+dependent submodules `here <https://gitlab.com/qemu-project/biosbits-bits>`__.
 This fork contains numerous fixes, a newer acpica and changes specific to
 running this avocado QEMU tests using bits. The author of this document
-is the sole maintainer of the QEMU fork of bios bits repo.
+is the sole maintainer of the QEMU fork of bios bits repository. For more
+information, please see author's `FOSDEM talk on this bios-bits based test
+framework 
<https://fosdem.org/2024/schedule/event/fosdem-2024-2262-exercising-qemu-generated-acpi-smbios-tables-using-biosbits-from-within-a-guest-vm-/>`__.
+
+*
+Description of the test framework
+*
 
 Under the directory ``tests/avocado/``, ``acpi-bits.py`` is a QEMU avocado
 test that drives all this.
@@ -120,8 +142,9 @@ Under ``tests/avocado/`` as the root we have:
(b) Add a SPDX license header.
(c) Perform modifications to the test.
 
-   Commits (a), (b) and (c) should go under separate commits so that the 
original
-   test script and the changes we have made are separated and clear.
+   Commits (a), (b) and (c) preferably should go under separate commits so th

[PATCH] docs/acpi/bits: add some clarity and details and improve formating

[Ani Sinha]

Update bios-bits docs to add more details on why a pre-OS environment for
testing bioses is useful. Add author's FOSDEM talk link.

CC: qemu-triv...@nongnu.org
Signed-off-by: Ani Sinha 
---
 docs/devel/acpi-bits.rst | 55 
 1 file changed, 39 insertions(+), 16 deletions(-)

diff --git a/docs/devel/acpi-bits.rst b/docs/devel/acpi-bits.rst
index 9677b0098f..1ec394f5fb 100644
--- a/docs/devel/acpi-bits.rst
+++ b/docs/devel/acpi-bits.rst
@@ -1,26 +1,48 @@
 =
 ACPI/SMBIOS avocado tests using biosbits
 =
-
+
+Introduction
+
 Biosbits is a software written by Josh Triplett that can be downloaded
 from https://biosbits.org/. The github codebase can be found
-`here <https://github.com/biosbits/bits/tree/master>`__. It is a software that 
executes
-the bios components such as acpi and smbios tables directly through acpica
-bios interpreter (a freely available C based library written by Intel,
+`here <https://github.com/biosbits/bits/tree/master>`__. It is a software that
+executes the bios components such as acpi and smbios tables directly through
+acpica bios interpreter (a freely available C based library written by Intel,
 downloadable from https://acpica.org/ and is included with biosbits) without an
-operating system getting involved in between.
+operating system getting involved in between. Bios-bits has python integration
+with grub so actual routines that executes bios components can be written in
+python instead of bash-ish (grub's native scripting language).
 There are several advantages to directly testing the bios in a real physical
-machine or VM as opposed to indirectly discovering bios issues through the
-operating system. For one thing, the OSes tend to hide bios problems from the
-end user. The other is that we have more control of what we wanted to test
-and how by directly using acpica interpreter on top of the bios on a running
-system. More details on the inspiration for developing biosbits and its real
-life uses can be found in [#a]_ and [#b]_.
+machine or in a VM as opposed to indirectly discovering bios issues through the
+operating system (the OS). Operating systems tend to bypass bios problems and
+hide them from the end user. We have more control of what we wanted to test and
+how by being as close to the bios on a running system as possible without a
+complicated software component such as an operating system coming in between.
+Another issue is that we cannot exercise bios components such as ACPI and
+SMBIOS without being in the highest hardware privilege level, ring 0 for
+example in case of x86. Since the OS executes from ring 0 whereas normal user
+land software resides in unprivileged ring 3, operating system must be modified
+in order to write our test routines that exercise and test the bios. This is
+not possible in all cases. Lastly, test frameworks and routines are preferably
+written using a high level scripting language such as python. OSes and
+OS modules are generally written using low level languages such as C and
+low level assembly machine language. Writing test routines in a low level
+language makes things more cumbersome. These and other reasons makes using
+bios-bits very attractive for testing bioses. More details on the inspiration
+for developing biosbits and its real life uses can be found in [#a]_ and [#b]_.
+
 For QEMU, we maintain a fork of bios bits in gitlab along with all the
-dependent submodules here: https://gitlab.com/qemu-project/biosbits-bits
+dependent submodules `here <https://gitlab.com/qemu-project/biosbits-bits>`__.
 This fork contains numerous fixes, a newer acpica and changes specific to
 running this avocado QEMU tests using bits. The author of this document
-is the sole maintainer of the QEMU fork of bios bits repo.
+is the sole maintainer of the QEMU fork of bios bits repository. For more
+information, please see author's `FOSDEM talk on this bios-bits based test
+framework 
<https://fosdem.org/2024/schedule/event/fosdem-2024-2262-exercising-qemu-generated-acpi-smbios-tables-using-biosbits-from-within-a-guest-vm-/>`__.
+
+*
+Description of the test framework
+*
 
 Under the directory ``tests/avocado/``, ``acpi-bits.py`` is a QEMU avocado
 test that drives all this.
@@ -120,8 +142,9 @@ Under ``tests/avocado/`` as the root we have:
(b) Add a SPDX license header.
(c) Perform modifications to the test.
 
-   Commits (a), (b) and (c) should go under separate commits so that the 
original
-   test script and the changes we have made are separated and clear.
+   Commits (a), (b) and (c) preferably should go under separate commits so that
+   the original test script and the changes we have made are separated and
+   clear. (

Re: [PATCH v2 07/20] smbios: avoid mangling user provided tables

[Ani Sinha]

> On 06-Mar-2024, at 12:11, Ani Sinha  wrote:
> 
> 
> 
> On Tue, 5 Mar 2024, Igor Mammedov wrote:
> 
>> currently smbios_entry_add() preserves internally '-smbios type='
>> options but tables provided with '-smbios file=' are stored directly
>> into blob that eventually will be exposed to VM. And then later
>> QEMU adds default/'-smbios type' entries on top into the same blob.
>> 
>> It makes impossible to generate tables more than once, hence
>> 'immutable' guard was used.
>> Make it possible to regenerate final blob by storing user provided
>> blobs into a dedicated area (usr_blobs) and then copy it when
>> composing final blob. Which also makes handling of -smbios
>> options consistent.
>> 
>> As side effect of this and previous commits there is no need to
>> generate legacy smbios_entries at the time options are parsed.
>> Instead compose smbios_entries on demand from  usr_blobs like
>> it is done for non-legacy SMBIOS tables.
>> 
>> Signed-off-by: Igor Mammedov 
>> Tested-by: Fiona Ebner 
> 
> Reviewed-by: Ani Sinha 
> 
>> ---
>> hw/smbios/smbios.c | 179 +++--
>> 1 file changed, 92 insertions(+), 87 deletions(-)
>> 
>> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
>> index c46fc93357..aa2cc5bdbd 100644
>> --- a/hw/smbios/smbios.c
>> +++ b/hw/smbios/smbios.c
>> @@ -57,6 +57,14 @@ static size_t smbios_entries_len;
>> static bool smbios_uuid_encoded = true;
>> /* end: legacy structures & constants for <= 2.0 machines */
>> 
>> +/*
>> + * SMBIOS tables provided by user with '-smbios file=' option
>> + */
>> +uint8_t *usr_blobs;
>> +size_t usr_blobs_len;
>> +static GArray *usr_blobs_sizes;
>> +static unsigned usr_table_max;
>> +static unsigned usr_table_cnt;
>> 
>> uint8_t *smbios_tables;
>> size_t smbios_tables_len;
>> @@ -67,7 +75,6 @@ static SmbiosEntryPointType smbios_ep_type = 
>> SMBIOS_ENTRY_POINT_TYPE_32;
>> static SmbiosEntryPoint ep;
>> 
>> static int smbios_type4_count = 0;
>> -static bool smbios_immutable;
>> static bool smbios_have_defaults;
>> static uint32_t smbios_cpuid_version, smbios_cpuid_features;
>> 
>> @@ -569,9 +576,8 @@ static void smbios_build_type_1_fields(void)
>> 
>> uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length)
>> {
>> -/* drop unwanted version of command-line file blob(s) */
>> -g_free(smbios_tables);
>> -smbios_tables = NULL;
>> +int i;
>> +size_t usr_offset;
>> 
>> /* also complain if fields were given for types > 1 */
>> if (find_next_bit(have_fields_bitmap,
>> @@ -581,12 +587,33 @@ uint8_t *smbios_get_table_legacy(uint32_t 
>> expected_t4_count, size_t *length)
>> exit(1);
>> }
>> 
>> -if (!smbios_immutable) {
>> -smbios_build_type_0_fields();
>> -smbios_build_type_1_fields();
>> -smbios_validate_table(expected_t4_count);
>> -smbios_immutable = true;
>> +g_free(smbios_entries);
>> +smbios_entries_len = sizeof(uint16_t);
>> +smbios_entries = g_malloc0(smbios_entries_len);
>> +
>> +for (i = 0, usr_offset = 0; usr_blobs_sizes && i < usr_blobs_sizes->len;
>> + i++)
>> +{
>> +struct smbios_table *table;
>> +struct smbios_structure_header *header;
>> +size_t size = g_array_index(usr_blobs_sizes, size_t, i);
>> +
>> +header = (struct smbios_structure_header *)(usr_blobs + usr_offset);
>> +smbios_entries = g_realloc(smbios_entries, smbios_entries_len +
>> +   size + sizeof(*table));
>> +table = (struct smbios_table *)(smbios_entries + 
>> smbios_entries_len);
>> +table->header.type = SMBIOS_TABLE_ENTRY;
>> +table->header.length = cpu_to_le16(sizeof(*table) + size);
>> +memcpy(table->data, header, size);
>> +smbios_entries_len += sizeof(*table) + size;
>> +(*(uint16_t *)smbios_entries) =
>> +cpu_to_le16(le16_to_cpu(*(uint16_t *)smbios_entries) + 1);
> 
> I know this comes from existing code but can you please explain why we add
> 1 to it? This is confusing and a comment here would be nice.
> 
>> +usr_offset += size;
> 
> It would be better if we could add a comment here describing a bit what
> this is all about.
> 
> user blobs are an array of smbios_structure_header entries whereas 

Re: [PATCH v2 20/20] tests: acpi: update expected SSDT.dimmpxm blob

[Ani Sinha]

> On 05-Mar-2024, at 21:27, Igor Mammedov  wrote:
> 
> address shift is caused by switch to 32-bit SMBIOS entry point
> which has slightly different size from 64-bit one and happens
> to trigger a bit different memory layout.

Why does it affect only q35 machines and not i440fx as well?

> 
> Expected diff:
> 
> -Name (MEMA, 0x07FFE000)
> +Name (MEMA, 0x07FFF000)
> 
> Signed-off-by: Igor Mammedov 

Acked-by: Ani Sinha 

> ---
> tests/qtest/bios-tables-test-allowed-diff.h |   1 -
> tests/data/acpi/q35/SSDT.dimmpxm| Bin 1815 -> 1815 bytes
> 2 files changed, 1 deletion(-)
> 
> diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
> b/tests/qtest/bios-tables-test-allowed-diff.h
> index 81148a604f..dfb8523c8b 100644
> --- a/tests/qtest/bios-tables-test-allowed-diff.h
> +++ b/tests/qtest/bios-tables-test-allowed-diff.h
> @@ -1,2 +1 @@
> /* List of comma-separated changed AML files to ignore */
> -"tests/data/acpi/q35/SSDT.dimmpxm",
> diff --git a/tests/data/acpi/q35/SSDT.dimmpxm 
> b/tests/data/acpi/q35/SSDT.dimmpxm
> index 
> 70f133412f5e0aa128ab210245a8de7304eeb843..9ea4e0d0ceaa8a5cbd706afb6d49de853fafe654
>  100644
> GIT binary patch
> delta 23
> ecmbQvH=U0wIM^jboSlJzam_|9E_UV*|JeaVTLvQl
> 
> delta 23
> ecmbQvH=U0wIM^jboSlJzanD9BE_UVz|JeaVy9Ofw
> 
> -- 
> 2.39.3
> 

Re: [PATCH v2 18/20] tests: acpi/smbios: whitelist expected blobs

[Ani Sinha]

> On 05-Mar-2024, at 21:27, Igor Mammedov  wrote:
> 
> Signed-off-by: Igor Mammedov 

Acked-by: Ani Sinha 

> ---
> tests/qtest/bios-tables-test-allowed-diff.h | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
> b/tests/qtest/bios-tables-test-allowed-diff.h
> index dfb8523c8b..81148a604f 100644
> --- a/tests/qtest/bios-tables-test-allowed-diff.h
> +++ b/tests/qtest/bios-tables-test-allowed-diff.h
> @@ -1 +1,2 @@
> /* List of comma-separated changed AML files to ignore */
> +"tests/data/acpi/q35/SSDT.dimmpxm",
> -- 
> 2.39.3
> 

Re: [PATCH v2 17/20] smbios: clear smbios_type4_count before building tables

[Ani Sinha]

> On 05-Mar-2024, at 21:27, Igor Mammedov  wrote:
> 
> it will help to keep type 4 tables accounting correct in case
> SMBIOS tables are built multiple times.


I suggest you arrange this before patch 15 where you are actually calling 
smbios_get_tables_ep() multiple times. That way there is no window where things 
can break between patches.

> 
> Signed-off-by: Igor Mammedov 
> Tested-by: Fiona Ebner 
> ---
> hw/smbios/smbios.c | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index bf5c7a8885..b64d3bc227 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -981,6 +981,7 @@ static bool smbios_get_tables_ep(MachineState *ms,
>ep_type == SMBIOS_ENTRY_POINT_TYPE_64);
> 
> g_free(smbios_tables);
> +smbios_type4_count = 0;

Nit: Can you put this before g_free() because gfree(smbios_tables) and 
smbios_tables = memdup2() etc are related. This is kind of coming in between.

> smbios_tables = g_memdup2(usr_blobs, usr_blobs_len);
> smbios_tables_len = usr_blobs_len;
> smbios_table_max = usr_table_max;
> -- 
> 2.39.3
> 

Re: [PATCH v2 11/20] smbios: build legacy mode code only for 'pc' machine

[Ani Sinha]

> On 05-Mar-2024, at 21:27, Igor Mammedov  wrote:
> 
> basically moving code around without functional change.
> And exposing some symbols so that they could be shared
> between smbbios.c and new smbios_legacy.c
> 
> plus some meson magic to build smbios_legacy.c only
> for 'pc' machine and otherwise replace it with stub
> if not selected.

When I apply this, I get:

Applying: smbios: build legacy mode code only for 'pc' machine
.git/rebase-apply/patch:483: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

Can you please look into this? Modulo that,

> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
> v2:
>  moved type0/type1/have_binfile_bitmap/have_fields_bitmap rename into
>  a separate patch
> ---
> include/hw/firmware/smbios.h   |   5 +
> hw/i386/Kconfig|   1 +
> hw/smbios/Kconfig  |   2 +
> hw/smbios/meson.build  |   4 +
> hw/smbios/smbios.c | 164 +-
> hw/smbios/smbios_legacy.c  | 179 +
> hw/smbios/smbios_legacy_stub.c |  16 +++
> 7 files changed, 208 insertions(+), 163 deletions(-)
> create mode 100644 hw/smbios/smbios_legacy.c
> create mode 100644 hw/smbios/smbios_legacy_stub.c
> 
> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
> index bea5c3f1b1..7f47475aa4 100644
> --- a/include/hw/firmware/smbios.h
> +++ b/include/hw/firmware/smbios.h
> @@ -17,6 +17,9 @@
>  *
>  */
> 
> +extern uint8_t *usr_blobs;
> +extern GArray *usr_blobs_sizes;
> +
> typedef struct {
> const char *vendor, *version, *date;
> bool have_major_minor, uefi;
> @@ -306,6 +309,8 @@ struct smbios_type_127 {
> struct smbios_structure_header header;
> } QEMU_PACKED;
> 
> +void smbios_validate_table(void);
> +void smbios_add_usr_blob_size(size_t size);
> void smbios_entry_add(QemuOpts *opts, Error **errp);
> void smbios_set_cpuid(uint32_t version, uint32_t features);
> void smbios_set_defaults(const char *manufacturer, const char *product,
> diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
> index a1846be6f7..a6ee052f9a 100644
> --- a/hw/i386/Kconfig
> +++ b/hw/i386/Kconfig
> @@ -76,6 +76,7 @@ config I440FX
> select PIIX
> select DIMM
> select SMBIOS
> +select SMBIOS_LEGACY
> select FW_CFG_DMA
> 
> config ISAPC
> diff --git a/hw/smbios/Kconfig b/hw/smbios/Kconfig
> index 553adf4bfc..8d989a2f1b 100644
> --- a/hw/smbios/Kconfig
> +++ b/hw/smbios/Kconfig
> @@ -1,2 +1,4 @@
> config SMBIOS
> bool
> +config SMBIOS_LEGACY
> +bool
> diff --git a/hw/smbios/meson.build b/hw/smbios/meson.build
> index 7046967462..a59039f669 100644
> --- a/hw/smbios/meson.build
> +++ b/hw/smbios/meson.build
> @@ -4,5 +4,9 @@ smbios_ss.add(when: 'CONFIG_IPMI',
>   if_true: files('smbios_type_38.c'),
>   if_false: files('smbios_type_38-stub.c'))
> 
> +smbios_ss.add(when: 'CONFIG_SMBIOS_LEGACY',
> +  if_true: files('smbios_legacy.c'),
> +  if_false: files('smbios_legacy_stub.c'))
> +
> system_ss.add_all(when: 'CONFIG_SMBIOS', if_true: smbios_ss)
> system_ss.add(when: 'CONFIG_SMBIOS', if_false: files('smbios-stub.c'))
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 86cf66b5ce..fb1f05fcde 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -31,38 +31,12 @@
> #include "hw/pci/pci_device.h"
> #include "smbios_build.h"
> 
> -/* legacy structures and constants for <= 2.0 machines */
> -struct smbios_header {
> -uint16_t length;
> -uint8_t type;
> -} QEMU_PACKED;
> -
> -struct smbios_field {
> -struct smbios_header header;
> -uint8_t type;
> -uint16_t offset;
> -uint8_t data[];
> -} QEMU_PACKED;
> -
> -struct smbios_table {
> -struct smbios_header header;
> -uint8_t data[];
> -} QEMU_PACKED;
> -
> -#define SMBIOS_FIELD_ENTRY 0
> -#define SMBIOS_TABLE_ENTRY 1
> -
> -static uint8_t *smbios_entries;
> -static size_t smbios_entries_len;
> static bool smbios_uuid_encoded = true;
> -/* end: legacy structures & constants for <= 2.0 machines */
> -
> /*
>  * SMBIOS tables provided by user with '-smbios file=' option
>  */
> uint8_t *usr_blobs;
> size_t usr_blobs_len;
> -static GArray *usr_blobs_sizes;
> static unsigned usr_table_max;
> static unsigned usr_table_cnt;
> 
> @@ -483,7 +457,7 @@ static void smbios_check_type4_count(uint32_t 
> expected_t4_count)
> }
> }
> 
> -static void smbios_validate_table(void)
> +void smbios_validate_table(void)
> {
> if (smbios_ep_type == SMBIOS_ENTRY_POINT_TYPE_32 &&
>   

Re: [PATCH v2 10/20] smbios: rename/expose structures/bitmaps used by both legacy and modern code

[Ani Sinha]

On Tue, 5 Mar 2024, Igor Mammedov wrote:

> As a preparation to move legacy handling into a separate file,
> add prefix 'smbios_' to type0/type1/have_binfile_bitmap/have_fields_bitmap
> and expose them in smbios.h so that they can be reused in
> legacy and modern code.
>
> Doing it as a separate patch to avoid rename cluttering follow-up
> patch which will move legacy code into a separate file.
>

I checked that after application of this patch in the patcset, QEMU build
goes through fine. Therefore,

> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
>  include/hw/firmware/smbios.h |  16 +
>  hw/smbios/smbios.c   | 113 ---
>  2 files changed, 69 insertions(+), 60 deletions(-)
>
> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
> index 1fbff3c55f..bea5c3f1b1 100644
> --- a/include/hw/firmware/smbios.h
> +++ b/include/hw/firmware/smbios.h
> @@ -2,6 +2,7 @@
>  #define QEMU_SMBIOS_H
>
>  #include "qapi/qapi-types-machine.h"
> +#include "qemu/bitmap.h"
>
>  /*
>   * SMBIOS Support
> @@ -16,8 +17,23 @@
>   *
>   */
>
> +typedef struct {
> +const char *vendor, *version, *date;
> +bool have_major_minor, uefi;
> +uint8_t major, minor;
> +} smbios_type0_t;
> +extern smbios_type0_t smbios_type0;
> +
> +typedef struct {
> +const char *manufacturer, *product, *version, *serial, *sku, *family;
> +/* uuid is in qemu_uuid */
> +} smbios_type1_t;
> +extern smbios_type1_t smbios_type1;
>
>  #define SMBIOS_MAX_TYPE 127
> +extern DECLARE_BITMAP(smbios_have_binfile_bitmap, SMBIOS_MAX_TYPE + 1);
> +extern DECLARE_BITMAP(smbios_have_fields_bitmap, SMBIOS_MAX_TYPE + 1);
> +
>  #define offsetofend(TYPE, MEMBER) \
> (offsetof(TYPE, MEMBER) + sizeof_field(TYPE, MEMBER))
>
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 01180bd82c..86cf66b5ce 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -78,19 +78,11 @@ static int smbios_type4_count = 0;
>  static bool smbios_have_defaults;
>  static uint32_t smbios_cpuid_version, smbios_cpuid_features;
>
> -static DECLARE_BITMAP(have_binfile_bitmap, SMBIOS_MAX_TYPE+1);
> -static DECLARE_BITMAP(have_fields_bitmap, SMBIOS_MAX_TYPE+1);
> +DECLARE_BITMAP(smbios_have_binfile_bitmap, SMBIOS_MAX_TYPE + 1);
> +DECLARE_BITMAP(smbios_have_fields_bitmap, SMBIOS_MAX_TYPE + 1);
>
> -static struct {
> -const char *vendor, *version, *date;
> -bool have_major_minor, uefi;
> -uint8_t major, minor;
> -} type0;
> -
> -static struct {
> -const char *manufacturer, *product, *version, *serial, *sku, *family;
> -/* uuid is in qemu_uuid */
> -} type1;
> +smbios_type0_t smbios_type0;
> +smbios_type1_t smbios_type1;
>
>  static struct {
>  const char *manufacturer, *product, *version, *serial, *asset, *location;
> @@ -536,36 +528,36 @@ static void smbios_maybe_add_str(int type, int offset, 
> const char *data)
>  static void smbios_build_type_0_fields(void)
>  {
>  smbios_maybe_add_str(0, offsetof(struct smbios_type_0, vendor_str),
> - type0.vendor);
> + smbios_type0.vendor);
>  smbios_maybe_add_str(0, offsetof(struct smbios_type_0, bios_version_str),
> - type0.version);
> + smbios_type0.version);
>  smbios_maybe_add_str(0, offsetof(struct smbios_type_0,
>   bios_release_date_str),
> - type0.date);
> -if (type0.have_major_minor) {
> + smbios_type0.date);
> +if (smbios_type0.have_major_minor) {
>  smbios_add_field(0, offsetof(struct smbios_type_0,
>   system_bios_major_release),
> - , 1);
> + _type0.major, 1);
>  smbios_add_field(0, offsetof(struct smbios_type_0,
>   system_bios_minor_release),
> - , 1);
> + _type0.minor, 1);
>  }
>  }
>
>  static void smbios_build_type_1_fields(void)
>  {
>  smbios_maybe_add_str(1, offsetof(struct smbios_type_1, manufacturer_str),
> - type1.manufacturer);
> + smbios_type1.manufacturer);
>  smbios_maybe_add_str(1, offsetof(struct smbios_type_1, product_name_str),
> - type1.product);
> + smbios_type1.product);
>  smbios_maybe_add_str(1, offsetof(struct smbios_type_1, version_str),
> - type1.version);
> + 

Re: [PATCH v2 09/20] smbios: add smbios_add_usr_blob_size() helper

[Ani Sinha]

> On 05-Mar-2024, at 21:27, Igor Mammedov  wrote:
> 
> it will be used by follow up patch when legacy handling
> is moved out into a separate file.
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
> hw/smbios/smbios.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 97cf762228..01180bd82c 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -1287,6 +1287,14 @@ static bool save_opt_list(size_t *ndest, char ***dest, 
> QemuOpts *opts,
> return true;
> }
> 
> +static void smbios_add_usr_blob_size(size_t size)
> +{
> +if (!usr_blobs_sizes) {
> +usr_blobs_sizes = g_array_new(false, false, sizeof(size_t));
> +}
> +g_array_append_val(usr_blobs_sizes, size);
> +}
> +
> void smbios_entry_add(QemuOpts *opts, Error **errp)
> {
> const char *val;
> @@ -1334,10 +1342,12 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
> smbios_type4_count++;
> }
> 
> -if (!usr_blobs_sizes) {
> -usr_blobs_sizes = g_array_new(false, false, sizeof(size_t));
> -}
> -g_array_append_val(usr_blobs_sizes, size);
> +/*
> + * preserve blob size for legacy mode so it could build its
> + * blobs flavor from 'usr_blobs'
> + */
> +smbios_add_usr_blob_size(size);
> +
> usr_blobs_len += size;
> if (size > usr_table_max) {
> usr_table_max = size;
> -- 
> 2.39.3
> 

Re: [PATCH v2 07/20] smbios: avoid mangling user provided tables

[Ani Sinha]

On Tue, 5 Mar 2024, Igor Mammedov wrote:

> currently smbios_entry_add() preserves internally '-smbios type='
> options but tables provided with '-smbios file=' are stored directly
> into blob that eventually will be exposed to VM. And then later
> QEMU adds default/'-smbios type' entries on top into the same blob.
>
> It makes impossible to generate tables more than once, hence
> 'immutable' guard was used.
> Make it possible to regenerate final blob by storing user provided
> blobs into a dedicated area (usr_blobs) and then copy it when
> composing final blob. Which also makes handling of -smbios
> options consistent.
>
> As side effect of this and previous commits there is no need to
> generate legacy smbios_entries at the time options are parsed.
> Instead compose smbios_entries on demand from  usr_blobs like
> it is done for non-legacy SMBIOS tables.
>
> Signed-off-by: Igor Mammedov 
> Tested-by: Fiona Ebner 

Reviewed-by: Ani Sinha 

> ---
>  hw/smbios/smbios.c | 179 +++--
>  1 file changed, 92 insertions(+), 87 deletions(-)
>
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index c46fc93357..aa2cc5bdbd 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -57,6 +57,14 @@ static size_t smbios_entries_len;
>  static bool smbios_uuid_encoded = true;
>  /* end: legacy structures & constants for <= 2.0 machines */
>
> +/*
> + * SMBIOS tables provided by user with '-smbios file=' option
> + */
> +uint8_t *usr_blobs;
> +size_t usr_blobs_len;
> +static GArray *usr_blobs_sizes;
> +static unsigned usr_table_max;
> +static unsigned usr_table_cnt;
>
>  uint8_t *smbios_tables;
>  size_t smbios_tables_len;
> @@ -67,7 +75,6 @@ static SmbiosEntryPointType smbios_ep_type = 
> SMBIOS_ENTRY_POINT_TYPE_32;
>  static SmbiosEntryPoint ep;
>
>  static int smbios_type4_count = 0;
> -static bool smbios_immutable;
>  static bool smbios_have_defaults;
>  static uint32_t smbios_cpuid_version, smbios_cpuid_features;
>
> @@ -569,9 +576,8 @@ static void smbios_build_type_1_fields(void)
>
>  uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length)
>  {
> -/* drop unwanted version of command-line file blob(s) */
> -g_free(smbios_tables);
> -smbios_tables = NULL;
> +int i;
> +size_t usr_offset;
>
>  /* also complain if fields were given for types > 1 */
>  if (find_next_bit(have_fields_bitmap,
> @@ -581,12 +587,33 @@ uint8_t *smbios_get_table_legacy(uint32_t 
> expected_t4_count, size_t *length)
>  exit(1);
>  }
>
> -if (!smbios_immutable) {
> -smbios_build_type_0_fields();
> -smbios_build_type_1_fields();
> -smbios_validate_table(expected_t4_count);
> -smbios_immutable = true;
> +g_free(smbios_entries);
> +smbios_entries_len = sizeof(uint16_t);
> +smbios_entries = g_malloc0(smbios_entries_len);
> +
> +for (i = 0, usr_offset = 0; usr_blobs_sizes && i < usr_blobs_sizes->len;
> + i++)
> +{
> +struct smbios_table *table;
> +struct smbios_structure_header *header;
> +size_t size = g_array_index(usr_blobs_sizes, size_t, i);
> +
> +header = (struct smbios_structure_header *)(usr_blobs + usr_offset);
> +smbios_entries = g_realloc(smbios_entries, smbios_entries_len +
> +   size + sizeof(*table));
> +table = (struct smbios_table *)(smbios_entries + smbios_entries_len);
> +table->header.type = SMBIOS_TABLE_ENTRY;
> +table->header.length = cpu_to_le16(sizeof(*table) + size);
> +memcpy(table->data, header, size);
> +smbios_entries_len += sizeof(*table) + size;
> +(*(uint16_t *)smbios_entries) =
> +cpu_to_le16(le16_to_cpu(*(uint16_t *)smbios_entries) + 1);

I know this comes from existing code but can you please explain why we add
1 to it? This is confusing and a comment here would be nice.

> +usr_offset += size;

It would be better if we could add a comment here describing a bit what
this is all about.

user blobs are an array of smbios_structure_header entries whereas legacy
tables are an array of smbios_table structures where
smbios_table->data represents the a single user provided table blob in
smbios_structure_header.

>  }
> +
> +smbios_build_type_0_fields();
> +smbios_build_type_1_fields();
> +smbios_validate_table(expected_t4_count);
>  *length = smbios_entries_len;
>  return smbios_entries;
>  }
> @@ -1094,67 +1121,67 @@ void smbios_get_tables(MachineState *ms,
>  {
>  unsigned i, dimm_cnt, offset;
>
> -/* drop un

Re: [PATCH 18/19] pc/q35: set SMBIOS entry point type to 'auto' by default

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> Use smbios-entry-point-type='auto' for newer machine types as a workaround
> for Windows not detecting SMBIOS tables. Which makes QEMU pick SMBIOS tables
> based on configuration (with 2.x preferred and fallback to 3.x if the former
> isn't compatible with configuration)
> 
> Default compat setting of smbios-entry-point-type after series
> for pc/q35 machines:
>  * 9.0-newer: 'auto'
>  * 8.1-8.2: '64'
>  * 8.0-older: '32'
> 
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2008
> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
> hw/i386/pc.c  | 2 +-
> hw/i386/pc_piix.c | 4 
> hw/i386/pc_q35.c  | 3 +++
> 3 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 56562e7d9e..2f69dfd0a8 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1831,7 +1831,7 @@ static void pc_machine_class_init(ObjectClass *oc, void 
> *data)
> mc->nvdimm_supported = true;
> mc->smp_props.dies_supported = true;
> mc->default_ram_id = "pc.ram";
> -pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_64;
> +pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_AUTO;
> 
> object_class_property_add(oc, PC_MACHINE_MAX_RAM_BELOW_4G, "size",
> pc_machine_get_max_ram_below_4g, pc_machine_set_max_ram_below_4g,
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index ec7c07b362..f9da942c55 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -535,12 +535,16 @@ DEFINE_I440FX_MACHINE(v9_0, "pc-i440fx-9.0", NULL,
> 
> static void pc_i440fx_8_2_machine_options(MachineClass *m)
> {
> +PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> +
> pc_i440fx_9_0_machine_options(m);
> m->alias = NULL;
> m->is_default = false;
> 
> compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
> compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
> +/* For pc-i44fx-8.2 and 8.1, use SMBIOS 3.X by default */
> +pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_64;
> }
> 
> DEFINE_I440FX_MACHINE(v8_2, "pc-i440fx-8.2", NULL,
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 53fb3db26d..da3f92bea7 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -371,10 +371,13 @@ DEFINE_Q35_MACHINE(v9_0, "pc-q35-9.0", NULL,
> 
> static void pc_q35_8_2_machine_options(MachineClass *m)
> {
> +PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> pc_q35_9_0_machine_options(m);
> m->alias = NULL;
> compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
> compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
> +/* For pc-q35-8.2 and 8.1, use SMBIOS 3.X by default */
> +pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_64;
> }
> 
> DEFINE_Q35_MACHINE(v8_2, "pc-q35-8.2", NULL,
> -- 
> 2.39.3
> 

Re: [PATCH 15/19] smbios: error out when building type 4 table is not possible

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> If SMBIOS v2 version is requested but number of cores/threads
> are more than it's possible to describe with v2, error out
> instead of silently ignoring the fact and filling core/thread
> count with bogus values.
> 
> This will help caller to decide if it should fallback to
> SMBIOSv3 when smbios-entry-point-type='auto'
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
> hw/smbios/smbios.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index e54a9f21e6..bf5c7a8885 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -605,7 +605,8 @@ static void smbios_build_type_3_table(void)
> }
> 
> static void smbios_build_type_4_table(MachineState *ms, unsigned instance,
> -  SmbiosEntryPointType ep_type)
> +  SmbiosEntryPointType ep_type,
> +  Error **errp)
> {
> char sock_str[128];
> size_t tbl_len = SMBIOS_TYPE_4_LEN_V28;
> @@ -659,6 +660,12 @@ static void smbios_build_type_4_table(MachineState *ms, 
> unsigned instance,
> if (tbl_len == SMBIOS_TYPE_4_LEN_V30) {
> t->core_count2 = t->core_enabled2 = cpu_to_le16(cores_per_socket);
> t->thread_count2 = cpu_to_le16(threads_per_socket);
> +} else if (t->core_count == 0xFF || t->thread_count == 0xFF) {
> +error_setg(errp, "SMBIOS 2.0 doesn't support number of processor "
> + "cores/threads more than 255, use "
> + "-machine smbios-entry-point-type=64 option to 
> enable "
> + "SMBIOS 3.0 support");
> +return;
> }
> 
> SMBIOS_BUILD_TABLE_POST;
> @@ -987,7 +994,10 @@ static bool smbios_get_tables_ep(MachineState *ms,
> assert(ms->smp.sockets >= 1);
> 
> for (i = 0; i < ms->smp.sockets; i++) {
> -smbios_build_type_4_table(ms, i, ep_type);
> +smbios_build_type_4_table(ms, i, ep_type, errp);
> +if (*errp) {
> +goto err_exit;
> +}
> }
> 
> smbios_build_type_8_table();
> -- 
> 2.39.3
> 

Re: [PATCH 13/19] smbios: extend smbios-entry-point-type with 'auto' value

[Ani Sinha]

On Tue, 27 Feb 2024, Igor Mammedov wrote:

> later patches will use it to pick SMBIOS version at runtime
> depending on configuration.
>
> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
>  qapi/machine.json | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/qapi/machine.json b/qapi/machine.json
> index 93b4677286..4c68528507 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -1802,10 +1802,13 @@
>  #
>  # @64: SMBIOS version 3.0 (64-bit) Entry Point
>  #
> +# @auto: Either 2.x or 3.x SMBIOS version, 2.x if configuration can be 
> described
> +#by it and 3.x otherwise (since: 9.0)
> +#
>  # Since: 7.0
>  ##
>  { 'enum': 'SmbiosEntryPointType',
> -  'data': [ '32', '64' ] }
> +  'data': [ '32', '64', 'auto' ] }
>
>  ##
>  # @MemorySizeConfiguration:
> --
> 2.39.3
>
>

Re: [PATCH 12/19] get rid of global smbios_ep_type

[Ani Sinha]

please add "smbios:" prefix just like your other patches in the commit
header.

On Tue, 27 Feb 2024, Igor Mammedov wrote:

> Signed-off-by: Igor Mammedov 

I have not checked all the code paths for the changed function signatures
and left that instead for the compiler. Assuming the build is fine,

Reviewed-by: Ani Sinha 

> ---
>  hw/i386/fw_cfg.h |  3 ++-
>  include/hw/firmware/smbios.h |  5 +++--
>  hw/arm/virt.c|  4 ++--
>  hw/i386/fw_cfg.c |  8 
>  hw/i386/pc.c |  2 +-
>  hw/loongarch/virt.c  |  7 ---
>  hw/riscv/virt.c  |  6 +++---
>  hw/smbios/smbios.c   | 27 +++
>  hw/smbios/smbios_legacy.c|  2 +-
>  9 files changed, 35 insertions(+), 29 deletions(-)
>
> diff --git a/hw/i386/fw_cfg.h b/hw/i386/fw_cfg.h
> index 1e1de6b4a3..92e310f5fd 100644
> --- a/hw/i386/fw_cfg.h
> +++ b/hw/i386/fw_cfg.h
> @@ -23,7 +23,8 @@
>  FWCfgState *fw_cfg_arch_create(MachineState *ms,
> uint16_t boot_cpus,
> uint16_t apic_id_limit);
> -void fw_cfg_build_smbios(PCMachineState *ms, FWCfgState *fw_cfg);
> +void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
> + SmbiosEntryPointType ep_type);
>  void fw_cfg_build_feature_control(MachineState *ms, FWCfgState *fw_cfg);
>  void fw_cfg_add_acpi_dsdt(Aml *scope, FWCfgState *fw_cfg);
>
> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
> index d1194c9cc2..d59c2f5a13 100644
> --- a/include/hw/firmware/smbios.h
> +++ b/include/hw/firmware/smbios.h
> @@ -310,16 +310,17 @@ struct smbios_type_127 {
>  struct smbios_structure_header header;
>  } QEMU_PACKED;
>
> -bool smbios_validate_table(Error **errp);
> +bool smbios_validate_table(SmbiosEntryPointType ep_type, Error **errp);
>  void smbios_add_usr_blob_size(size_t size);
>  void smbios_entry_add(QemuOpts *opts, Error **errp);
>  void smbios_set_cpuid(uint32_t version, uint32_t features);
>  void smbios_set_defaults(const char *manufacturer, const char *product,
>   const char *version,
> - bool uuid_encoded, SmbiosEntryPointType ep_type);
> + bool uuid_encoded);
>  void smbios_set_default_processor_family(uint16_t processor_family);
>  uint8_t *smbios_get_table_legacy(size_t *length, Error **errp);
>  void smbios_get_tables(MachineState *ms,
> +   SmbiosEntryPointType ep_type,
> const struct smbios_phys_mem_area *mem_array,
> const unsigned int mem_array_size,
> uint8_t **tables, size_t *tables_len,
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 8588681f27..780224ee5b 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1634,13 +1634,13 @@ static void virt_build_smbios(VirtMachineState *vms)
>
>  smbios_set_defaults("QEMU", product,
>  vmc->smbios_old_sys_ver ? "1.0" : mc->name,
> -true, SMBIOS_ENTRY_POINT_TYPE_64);
> +true);
>
>  /* build the array of physical mem area from base_memmap */
>  mem_array.address = vms->memmap[VIRT_MEM].base;
>  mem_array.length = ms->ram_size;
>
> -smbios_get_tables(ms, _array, 1,
> +smbios_get_tables(ms, SMBIOS_ENTRY_POINT_TYPE_64, _array, 1,
>_tables, _tables_len,
>_anchor, _anchor_len,
>_fatal);
> diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
> index e387bf50d0..d802d2787f 100644
> --- a/hw/i386/fw_cfg.c
> +++ b/hw/i386/fw_cfg.c
> @@ -48,7 +48,8 @@ const char *fw_cfg_arch_key_name(uint16_t key)
>  return NULL;
>  }
>
> -void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg)
> +void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState *fw_cfg,
> + SmbiosEntryPointType ep_type)
>  {
>  #ifdef CONFIG_SMBIOS
>  uint8_t *smbios_tables, *smbios_anchor;
> @@ -63,8 +64,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
> *fw_cfg)
>  if (pcmc->smbios_defaults) {
>  /* These values are guest ABI, do not change */
>  smbios_set_defaults("QEMU", mc->desc, mc->name,
> -pcmc->smbios_uuid_encoded,
> -pcms->smbios_entry_point_type);
> +pcmc->smbios_uuid_encoded);
>  }
>
>  /* tell smbios about cpuid version and features */
> @@ -89,7 +89,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
> *

Re: [PATCH 14/19] smbios: in case of entry point is 'auto' try to build v2 tables 1st

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> QEMU for some time now uses SMBIOS 3.0 for PC/Q35 machines by
> default, however Windows has a bug in locating SMBIOS 3.0
> entrypoint and fails to find tables when booted on SeaBIOS
> (on UEFI SMBIOS 3.0 tables work fine since firmware hands
> over tables in another way)
> 
> Missing SMBIOS tables may lead to some issues for guest
> though (worst are: possible reactiveation, inability to
> get virtio drivers from 'Windows Update')
> 
> It's unclear  at this point if MS will fix the issue on their
> side. So instead of it (or rather in addition) this patch
> will try to workaround the issue.
> 
> aka, use smbios-entry-point-type=auto to make QEMU try
> generating conservative SMBIOS 2.0 tables and if that
> fails (due to limits/requested configuration) fallback
> to SMBIOS 3.0 tables.
> 
> With this in place majority of users will use SMBIOS 2.0
> tables which work fine with (Windows + legacy BIOS).
> The configurations that is not to possible to describe
> with SMBIOS 2.0 will switch automatically to SMBIOS 3.0
> (which will trigger Windows bug but there is nothing
> QEMU can do here, so go and aks Microsoft to real fix).
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
> hw/smbios/smbios.c | 52 +++---
> 1 file changed, 49 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 5a791fd9eb..e54a9f21e6 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -959,7 +959,7 @@ static void smbios_entry_point_setup(SmbiosEntryPointType 
> ep_type)
> }
> }
> 
> -void smbios_get_tables(MachineState *ms,
> +static bool smbios_get_tables_ep(MachineState *ms,
>SmbiosEntryPointType ep_type,
>const struct smbios_phys_mem_area *mem_array,
>const unsigned int mem_array_size,
> @@ -968,6 +968,7 @@ void smbios_get_tables(MachineState *ms,
>Error **errp)
> {
> unsigned i, dimm_cnt, offset;
> +ERRP_GUARD();
> 
> assert(ep_type == SMBIOS_ENTRY_POINT_TYPE_32 ||
>ep_type == SMBIOS_ENTRY_POINT_TYPE_64);
> @@ -1052,11 +1053,56 @@ void smbios_get_tables(MachineState *ms,
> abort();
> }
> 
> -return;
> +return true;
> err_exit:
> g_free(smbios_tables);
> smbios_tables = NULL;
> -return;
> +return false;
> +}
> +
> +void smbios_get_tables(MachineState *ms,
> +   SmbiosEntryPointType ep_type,
> +   const struct smbios_phys_mem_area *mem_array,
> +   const unsigned int mem_array_size,
> +   uint8_t **tables, size_t *tables_len,
> +   uint8_t **anchor, size_t *anchor_len,
> +   Error **errp)
> +{
> +Error *local_err = NULL;
> +bool is_valid;
> +ERRP_GUARD();
> +
> +switch (ep_type) {
> +case SMBIOS_ENTRY_POINT_TYPE_AUTO:
> +case SMBIOS_ENTRY_POINT_TYPE_32:
> +is_valid = smbios_get_tables_ep(ms, SMBIOS_ENTRY_POINT_TYPE_32,
> +mem_array, mem_array_size,
> +tables, tables_len,
> +anchor, anchor_len,
> +_err);
> +if (is_valid || ep_type != SMBIOS_ENTRY_POINT_TYPE_AUTO) {
> +break;
> +}
> +/*
> + * fall through in case AUTO endpoint is selected and
> + * SMBIOS 2.x tables can't be generated, to try if SMBIOS 3.x
> + * tables would work
> + */
> +case SMBIOS_ENTRY_POINT_TYPE_64:
> +error_free(local_err);
> +local_err = NULL;
> +is_valid = smbios_get_tables_ep(ms, SMBIOS_ENTRY_POINT_TYPE_64,
> +mem_array, mem_array_size,
> +tables, tables_len,
> +anchor, anchor_len,
> +_err);
> +break;
> +default:
> +abort();
> +}
> +if (!is_valid) {
> +error_propagate(errp, local_err);
> +}
> }
> 
> static void save_opt(const char **dest, QemuOpts *opts, const char *name)
> -- 
> 2.39.3
> 

Re: [PATCH 11/19] smbios: clear smbios_tables pointer after freeing

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> that will avoid double free if smbios_get_tables() is called
> multiple times.
> 
> Signed-off-by: Igor Mammedov 

Maybe we can squash this with patch 10.

Other than that, 

Reviewed-by: Ani Sinha 

> ---
> hw/smbios/smbios.c | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 7c28b5f748..d9ba2072b1 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -1052,6 +1052,8 @@ void smbios_get_tables(MachineState *ms,
> return;
> err_exit:
> g_free(smbios_tables);
> +smbios_tables = NULL;
> +return;
> }
> 
> static void save_opt(const char **dest, QemuOpts *opts, const char *name)
> -- 
> 2.39.3
> 

Re: [PATCH 10/19] smbios: handle errors consistently

[Ani Sinha]

> On 04-Mar-2024, at 19:09, Igor Mammedov  wrote:
> 
> On Mon, 4 Mar 2024 16:44:34 +0530 (IST)
> Ani Sinha  wrote:
> 
>> On Tue, 27 Feb 2024, Igor Mammedov wrote:
>> 
>>> Current code uses mix of error_report()+exit(1)
>>> and error_setg() to handle errors.
>>> Use newer error_setg() everywhere, beside consistency
>>> it will allow to detect error condition without killing
>>> QEMU and attempt switch-over to SMBIOS3.x tables/entrypoint
>>> in follow up patch.
>>> 
>>> Signed-off-by: Igor Mammedov   
>> 
>> Other than the nit below,
>> 
>> Reviewed-by: Ani Sinha 
>> 
>>> ---
>>> include/hw/firmware/smbios.h |  4 ++--
>>> hw/i386/fw_cfg.c |  3 ++-
>>> hw/smbios/smbios.c   | 32 
>>> hw/smbios/smbios_legacy.c| 22 ++
>>> 4 files changed, 38 insertions(+), 23 deletions(-)
>>> 
>>> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
>>> index a6d8fd6591..d1194c9cc2 100644
>>> --- a/include/hw/firmware/smbios.h
>>> +++ b/include/hw/firmware/smbios.h
>>> @@ -310,7 +310,7 @@ struct smbios_type_127 {
>>> struct smbios_structure_header header;
>>> } QEMU_PACKED;
>>> 
>>> -void smbios_validate_table(void);
>>> +bool smbios_validate_table(Error **errp);
>>> void smbios_add_usr_blob_size(size_t size);
>>> void smbios_entry_add(QemuOpts *opts, Error **errp);
>>> void smbios_set_cpuid(uint32_t version, uint32_t features);
>>> @@ -318,7 +318,7 @@ void smbios_set_defaults(const char *manufacturer, 
>>> const char *product,
>>>  const char *version,
>>>  bool uuid_encoded, SmbiosEntryPointType ep_type);
>>> void smbios_set_default_processor_family(uint16_t processor_family);
>>> -uint8_t *smbios_get_table_legacy(size_t *length);
>>> +uint8_t *smbios_get_table_legacy(size_t *length, Error **errp);
>>> void smbios_get_tables(MachineState *ms,
>>>const struct smbios_phys_mem_area *mem_array,
>>>const unsigned int mem_array_size,
>>> diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
>>> index d1281066f4..e387bf50d0 100644
>>> --- a/hw/i386/fw_cfg.c
>>> +++ b/hw/i386/fw_cfg.c
>>> @@ -71,7 +71,8 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
>>> *fw_cfg)
>>> smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
>>> 
>>> if (pcmc->smbios_legacy_mode) {
>>> -smbios_tables = smbios_get_table_legacy(_tables_len);
>>> +smbios_tables = smbios_get_table_legacy(_tables_len,
>>> +_fatal);
>>> fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
>>>  smbios_tables, smbios_tables_len);
>>> return;
>>> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
>>> index fb1f05fcde..7c28b5f748 100644
>>> --- a/hw/smbios/smbios.c
>>> +++ b/hw/smbios/smbios.c
>>> @@ -19,7 +19,6 @@
>>> #include "qemu/units.h"
>>> #include "qapi/error.h"
>>> #include "qemu/config-file.h"
>>> -#include "qemu/error-report.h"
>>> #include "qemu/module.h"
>>> #include "qemu/option.h"
>>> #include "sysemu/sysemu.h"
>>> @@ -448,23 +447,25 @@ opts_init(smbios_register_config);
>>>  */
>>> #define SMBIOS_21_MAX_TABLES_LEN 0x
>>> 
>>> -static void smbios_check_type4_count(uint32_t expected_t4_count)
>>> +static bool smbios_check_type4_count(uint32_t expected_t4_count, Error 
>>> **errp)
>>> {
>>> if (smbios_type4_count && smbios_type4_count != expected_t4_count) {
>>> -error_report("Expected %d SMBIOS Type 4 tables, got %d instead",
>>> - expected_t4_count, smbios_type4_count);
>>> -exit(1);
>>> +error_setg(errp, "Expected %d SMBIOS Type 4 tables, got %d 
>>> instead",
>>> +   expected_t4_count, smbios_type4_count);
>>> +return false;
>>> }
>>> +return true;
>>> }
>>> 
>>> -void smbios_validate_table(void)
>>> +bool smbios_validate_table(Error **errp)
>>> {
>>> if (smbios_ep_type == SMBIOS_ENTRY_POINT_TYPE_32 &

Re: [PATCH 10/19] smbios: handle errors consistently

[Ani Sinha]

On Tue, 27 Feb 2024, Igor Mammedov wrote:

> Current code uses mix of error_report()+exit(1)
> and error_setg() to handle errors.
> Use newer error_setg() everywhere, beside consistency
> it will allow to detect error condition without killing
> QEMU and attempt switch-over to SMBIOS3.x tables/entrypoint
> in follow up patch.
>
> Signed-off-by: Igor Mammedov 

Other than the nit below,

Reviewed-by: Ani Sinha 

> ---
>  include/hw/firmware/smbios.h |  4 ++--
>  hw/i386/fw_cfg.c |  3 ++-
>  hw/smbios/smbios.c   | 32 
>  hw/smbios/smbios_legacy.c| 22 ++
>  4 files changed, 38 insertions(+), 23 deletions(-)
>
> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
> index a6d8fd6591..d1194c9cc2 100644
> --- a/include/hw/firmware/smbios.h
> +++ b/include/hw/firmware/smbios.h
> @@ -310,7 +310,7 @@ struct smbios_type_127 {
>  struct smbios_structure_header header;
>  } QEMU_PACKED;
>
> -void smbios_validate_table(void);
> +bool smbios_validate_table(Error **errp);
>  void smbios_add_usr_blob_size(size_t size);
>  void smbios_entry_add(QemuOpts *opts, Error **errp);
>  void smbios_set_cpuid(uint32_t version, uint32_t features);
> @@ -318,7 +318,7 @@ void smbios_set_defaults(const char *manufacturer, const 
> char *product,
>   const char *version,
>   bool uuid_encoded, SmbiosEntryPointType ep_type);
>  void smbios_set_default_processor_family(uint16_t processor_family);
> -uint8_t *smbios_get_table_legacy(size_t *length);
> +uint8_t *smbios_get_table_legacy(size_t *length, Error **errp);
>  void smbios_get_tables(MachineState *ms,
> const struct smbios_phys_mem_area *mem_array,
> const unsigned int mem_array_size,
> diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
> index d1281066f4..e387bf50d0 100644
> --- a/hw/i386/fw_cfg.c
> +++ b/hw/i386/fw_cfg.c
> @@ -71,7 +71,8 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
> *fw_cfg)
>  smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
>
>  if (pcmc->smbios_legacy_mode) {
> -smbios_tables = smbios_get_table_legacy(_tables_len);
> +smbios_tables = smbios_get_table_legacy(_tables_len,
> +_fatal);
>  fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
>   smbios_tables, smbios_tables_len);
>  return;
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index fb1f05fcde..7c28b5f748 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -19,7 +19,6 @@
>  #include "qemu/units.h"
>  #include "qapi/error.h"
>  #include "qemu/config-file.h"
> -#include "qemu/error-report.h"
>  #include "qemu/module.h"
>  #include "qemu/option.h"
>  #include "sysemu/sysemu.h"
> @@ -448,23 +447,25 @@ opts_init(smbios_register_config);
>   */
>  #define SMBIOS_21_MAX_TABLES_LEN 0x
>
> -static void smbios_check_type4_count(uint32_t expected_t4_count)
> +static bool smbios_check_type4_count(uint32_t expected_t4_count, Error 
> **errp)
>  {
>  if (smbios_type4_count && smbios_type4_count != expected_t4_count) {
> -error_report("Expected %d SMBIOS Type 4 tables, got %d instead",
> - expected_t4_count, smbios_type4_count);
> -exit(1);
> +error_setg(errp, "Expected %d SMBIOS Type 4 tables, got %d instead",
> +   expected_t4_count, smbios_type4_count);
> +return false;
>  }
> +return true;
>  }
>
> -void smbios_validate_table(void)
> +bool smbios_validate_table(Error **errp)
>  {
>  if (smbios_ep_type == SMBIOS_ENTRY_POINT_TYPE_32 &&
>  smbios_tables_len > SMBIOS_21_MAX_TABLES_LEN) {
> -error_report("SMBIOS 2.1 table length %zu exceeds %d",
> - smbios_tables_len, SMBIOS_21_MAX_TABLES_LEN);
> -exit(1);
> +error_setg(errp, "SMBIOS 2.1 table length %zu exceeds %d",
> +   smbios_tables_len, SMBIOS_21_MAX_TABLES_LEN);
> +return false;
>  }
> +return true;
>  }
>
>  bool smbios_skip_table(uint8_t type, bool required_table)
> @@ -1027,15 +1028,18 @@ void smbios_get_tables(MachineState *ms,
>  smbios_build_type_41_table(errp);
>  smbios_build_type_127_table();
>
> -smbios_check_type4_count(ms->smp.sockets);
> -smbios_validate_table();
> +if (!smbios_check_type4_count(ms->smp.sockets, errp)) {

nit: I would do a gfree

Re: [PATCH 09/19] smbios: build legacy mode code only for 'pc' machine

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> basically moving code around without functional change.
> And exposing some symbols so that they could be shared
> between smbbios.c and new smbios_legacy.c
> 
> plus some meson magic to build smbios_legacy.c only
> for 'pc' machine and otherwise replace it with stub
> if not selected.
> 
> Signed-off-by: Igor Mammedov 
> ---
> include/hw/firmware/smbios.h   |  22 +++
> hw/i386/Kconfig|   1 +
> hw/smbios/Kconfig  |   2 +
> hw/smbios/meson.build  |   4 +
> hw/smbios/smbios.c | 251 ++---
> hw/smbios/smbios_legacy.c  | 179 +++
> hw/smbios/smbios_legacy_stub.c |  16 +++
> 7 files changed, 270 insertions(+), 205 deletions(-)
> create mode 100644 hw/smbios/smbios_legacy.c
> create mode 100644 hw/smbios/smbios_legacy_stub.c
> 
> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
> index 1fbff3c55f..a6d8fd6591 100644
> --- a/include/hw/firmware/smbios.h
> +++ b/include/hw/firmware/smbios.h
> @@ -2,6 +2,7 @@
> #define QEMU_SMBIOS_H
> 
> #include "qapi/qapi-types-machine.h"
> +#include "qemu/bitmap.h"
> 
> /*
>  * SMBIOS Support
> @@ -16,8 +17,27 @@
>  *
>  */
> 
> +extern uint8_t *usr_blobs;
> +extern GArray *usr_blobs_sizes;
> +
> +typedef struct {
> +const char *vendor, *version, *date;
> +bool have_major_minor, uefi;
> +uint8_t major, minor;
> +} smbios_type0_t;
> +extern smbios_type0_t smbios_type0;
> +
> +typedef struct {
> +const char *manufacturer, *product, *version, *serial, *sku, *family;
> +/* uuid is in qemu_uuid */
> +} smbios_type1_t;
> +extern smbios_type1_t smbios_type1;
> +
> 
> #define SMBIOS_MAX_TYPE 127
> +extern DECLARE_BITMAP(smbios_have_binfile_bitmap, SMBIOS_MAX_TYPE + 1);
> +extern DECLARE_BITMAP(smbios_have_fields_bitmap, SMBIOS_MAX_TYPE + 1);
> +
> #define offsetofend(TYPE, MEMBER) \
>(offsetof(TYPE, MEMBER) + sizeof_field(TYPE, MEMBER))
> 
> @@ -290,6 +310,8 @@ struct smbios_type_127 {
> struct smbios_structure_header header;
> } QEMU_PACKED;
> 
> +void smbios_validate_table(void);
> +void smbios_add_usr_blob_size(size_t size);
> void smbios_entry_add(QemuOpts *opts, Error **errp);
> void smbios_set_cpuid(uint32_t version, uint32_t features);
> void smbios_set_defaults(const char *manufacturer, const char *product,
> diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
> index a1846be6f7..a6ee052f9a 100644
> --- a/hw/i386/Kconfig
> +++ b/hw/i386/Kconfig
> @@ -76,6 +76,7 @@ config I440FX
> select PIIX
> select DIMM
> select SMBIOS
> +select SMBIOS_LEGACY
> select FW_CFG_DMA
> 
> config ISAPC
> diff --git a/hw/smbios/Kconfig b/hw/smbios/Kconfig
> index 553adf4bfc..8d989a2f1b 100644
> --- a/hw/smbios/Kconfig
> +++ b/hw/smbios/Kconfig
> @@ -1,2 +1,4 @@
> config SMBIOS
> bool
> +config SMBIOS_LEGACY
> +bool
> diff --git a/hw/smbios/meson.build b/hw/smbios/meson.build
> index 7046967462..a59039f669 100644
> --- a/hw/smbios/meson.build
> +++ b/hw/smbios/meson.build
> @@ -4,5 +4,9 @@ smbios_ss.add(when: 'CONFIG_IPMI',
>   if_true: files('smbios_type_38.c'),
>   if_false: files('smbios_type_38-stub.c'))
> 
> +smbios_ss.add(when: 'CONFIG_SMBIOS_LEGACY',
> +  if_true: files('smbios_legacy.c'),
> +  if_false: files('smbios_legacy_stub.c'))
> +
> system_ss.add_all(when: 'CONFIG_SMBIOS', if_true: smbios_ss)
> system_ss.add(when: 'CONFIG_SMBIOS', if_false: files('smbios-stub.c'))
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 97cf762228..fb1f05fcde 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -31,38 +31,12 @@
> #include "hw/pci/pci_device.h"
> #include "smbios_build.h"
> 
> -/* legacy structures and constants for <= 2.0 machines */
> -struct smbios_header {
> -uint16_t length;
> -uint8_t type;
> -} QEMU_PACKED;
> -
> -struct smbios_field {
> -struct smbios_header header;
> -uint8_t type;
> -uint16_t offset;
> -uint8_t data[];
> -} QEMU_PACKED;
> -
> -struct smbios_table {
> -struct smbios_header header;
> -uint8_t data[];
> -} QEMU_PACKED;
> -
> -#define SMBIOS_FIELD_ENTRY 0
> -#define SMBIOS_TABLE_ENTRY 1
> -
> -static uint8_t *smbios_entries;
> -static size_t smbios_entries_len;
> static bool smbios_uuid_encoded = true;
> -/* end: legacy structures & constants for <= 2.0 machines */
> -
> /*
>  * SMBIOS tables provided by user with '-smbios file=' option
>  */
> uint8_t *usr_blobs;
> size_t usr_blobs_len;
> -static GArray *usr_blobs_sizes;
> static unsigned usr_table_max;
> static unsigned usr_table_cnt;
> 
> @@ -78,19 +52,11 @@ static int smbios_type4_count = 0;
> static bool smbios_have_defaults;
> static uint32_t smbios_cpuid_version, smbios_cpuid_features;
> 
> -static DECLARE_BITMAP(have_binfile_bitmap, SMBIOS_MAX_TYPE+1);
> -static DECLARE_BITMAP(have_fields_bitmap, SMBIOS_MAX_TYPE+1);
> -
> -static struct {
> -const char *vendor, *version, 

Re: [PATCH 07/19] smbios: avoid mangling user provided tables

[Ani Sinha]

On Tue, 27 Feb 2024, Igor Mammedov wrote:

> currently smbios_entry_add() preserves internally '-smbios type='
> options but tables provided with '-smbios file=' are stored directly
> into blob that eventually will be exposed to VM. And then later
> QEMU adds default/'-smbios type' entries on top into the same blob.
>
> It makes impossible to generate tables more than once, hence
> 'immutable' guard was used.
> Make it possible to regenerate final blob by storing user provided
> blobs into a dedicated area (usr_blobs) and then copy it when
> composing final blob. Which also makes handling of -smbios
> options consistent.
>
> As side effect of this and previous commits there is no need to
> generate legacy smbios_entries at the time options are parsed.
> Instead compose smbios_entries on demand from  usr_blobs like
> it is done for non-legacy SMBIOS tables.
>

This patch is very dense and even after taking several iterations through
it, I am not confident that I have not missed anything.

> Signed-off-by: Igor Mammedov 
> ---
>  hw/smbios/smbios.c | 179 +++--
>  1 file changed, 92 insertions(+), 87 deletions(-)
>
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index c46fc93357..aa2cc5bdbd 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -57,6 +57,14 @@ static size_t smbios_entries_len;
>  static bool smbios_uuid_encoded = true;
>  /* end: legacy structures & constants for <= 2.0 machines */
>
> +/*
> + * SMBIOS tables provided by user with '-smbios file=' option
> + */
> +uint8_t *usr_blobs;
> +size_t usr_blobs_len;
> +static GArray *usr_blobs_sizes;
> +static unsigned usr_table_max;
> +static unsigned usr_table_cnt;
>
>  uint8_t *smbios_tables;
>  size_t smbios_tables_len;
> @@ -67,7 +75,6 @@ static SmbiosEntryPointType smbios_ep_type = 
> SMBIOS_ENTRY_POINT_TYPE_32;
>  static SmbiosEntryPoint ep;
>
>  static int smbios_type4_count = 0;
> -static bool smbios_immutable;
>  static bool smbios_have_defaults;
>  static uint32_t smbios_cpuid_version, smbios_cpuid_features;
>
> @@ -569,9 +576,8 @@ static void smbios_build_type_1_fields(void)
>
>  uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length)
>  {
> -/* drop unwanted version of command-line file blob(s) */
> -g_free(smbios_tables);
> -smbios_tables = NULL;
> +int i;
> +size_t usr_offset;
>
>  /* also complain if fields were given for types > 1 */
>  if (find_next_bit(have_fields_bitmap,
> @@ -581,12 +587,33 @@ uint8_t *smbios_get_table_legacy(uint32_t 
> expected_t4_count, size_t *length)
>  exit(1);
>  }
>
> -if (!smbios_immutable) {
> -smbios_build_type_0_fields();
> -smbios_build_type_1_fields();
> -smbios_validate_table(expected_t4_count);
> -smbios_immutable = true;
> +g_free(smbios_entries);
> +smbios_entries_len = sizeof(uint16_t);
> +smbios_entries = g_malloc0(smbios_entries_len);
> +
> +for (i = 0, usr_offset = 0; usr_blobs_sizes && i < usr_blobs_sizes->len;
> + i++)
> +{
> +struct smbios_table *table;
> +struct smbios_structure_header *header;
> +size_t size = g_array_index(usr_blobs_sizes, size_t, i);
> +
> +header = (struct smbios_structure_header *)(usr_blobs + usr_offset);
> +smbios_entries = g_realloc(smbios_entries, smbios_entries_len +
> +   size + sizeof(*table));
> +table = (struct smbios_table *)(smbios_entries + smbios_entries_len);
> +table->header.type = SMBIOS_TABLE_ENTRY;
> +table->header.length = cpu_to_le16(sizeof(*table) + size);
> +memcpy(table->data, header, size);
> +smbios_entries_len += sizeof(*table) + size;
> +(*(uint16_t *)smbios_entries) =
> +cpu_to_le16(le16_to_cpu(*(uint16_t *)smbios_entries) + 1);
> +usr_offset += size;
>  }
> +
> +smbios_build_type_0_fields();
> +smbios_build_type_1_fields();
> +smbios_validate_table(expected_t4_count);
>  *length = smbios_entries_len;
>  return smbios_entries;
>  }
> @@ -1094,67 +1121,67 @@ void smbios_get_tables(MachineState *ms,
>  {
>  unsigned i, dimm_cnt, offset;
>
> -/* drop unwanted (legacy) version of command-line file blob(s) */
> -g_free(smbios_entries);
> -smbios_entries = NULL;
> +g_free(smbios_tables);
> +smbios_tables = g_memdup2(usr_blobs, usr_blobs_len);

Why can't we do a memdup even for the legacy case instead of memcpy?

Secondly, here and other places we should check for NULL returns.
https://docs.gtk.org/glib/func.memdup2.html
return from memdup2 can be null.


> +smbios_tables_len = usr_blobs_len;
> +smbios_table_max = usr_table_max;
> +smbios_table_cnt = usr_table_cnt;
>
> -if (!smbios_immutable) {
> -smbios_build_type_0_table();
> -smbios_build_type_1_table();
> -smbios_build_type_2_table();
> -

Re: [PATCH 08/19] smbios: don't check type4 structures in legacy mode

[Ani Sinha]

On Tue, 27 Feb 2024, Igor Mammedov wrote:

> legacy mode doesn't support structures of type 2 and more,
> and CLI has a check for '-smbios type' option, however it's
> still possible to sneak in type4 as a blob with '-smbios file'
> option. However doing the later makes SMBIOS tables broken
> since SeaBIOS doesn't expect that.
>
> Rather than trying to add support for type4 to legacy code
> (both QEMU and SeaBIOS), simplify smbios_get_table_legacy()
> by dropping not relevant check in legacy code and error out
> on type4 blob.
>
> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
>  * The issue affects 'isapc' and pc-i440fx-2.0. the later is
>in deprecated state and to be dropped in near future
>  * possibly the same issue applies to other SMBIOS types above type 1
>but I haven't tested that, and well tables that aren't
>generated by SeaBIOS can get be added just fine
>(tested type11 blob). So I went with a minimal change
>to fixup type4 only that I'm touching. Leaving the rest
>for other time or when someone complains about it, which is
>very unlikely given it's really only remaining isapc machine.
>
>I'd very much prefer to deprecate 'isapc' and then drop
>all legacy related code (it will benefit not only SMBIOS
>but other code as well).
>BTW: 'isapc' is in semi-dead, I cna't boot RHEL6 on it
>with KVM enabled anymore (RHEL9 host), TCG still boots though.
>One more reason to get deprecate it.
> ---
>  include/hw/firmware/smbios.h |  2 +-
>  hw/i386/fw_cfg.c |  3 +--
>  hw/smbios/smbios.c   | 18 ++
>  3 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
> index 0818184834..1fbff3c55f 100644
> --- a/include/hw/firmware/smbios.h
> +++ b/include/hw/firmware/smbios.h
> @@ -296,7 +296,7 @@ void smbios_set_defaults(const char *manufacturer, const 
> char *product,
>   const char *version,
>   bool uuid_encoded, SmbiosEntryPointType ep_type);
>  void smbios_set_default_processor_family(uint16_t processor_family);
> -uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length);
> +uint8_t *smbios_get_table_legacy(size_t *length);
>  void smbios_get_tables(MachineState *ms,
> const struct smbios_phys_mem_area *mem_array,
> const unsigned int mem_array_size,
> diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
> index c1e9c0fd9c..d1281066f4 100644
> --- a/hw/i386/fw_cfg.c
> +++ b/hw/i386/fw_cfg.c
> @@ -71,8 +71,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
> *fw_cfg)
>  smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
>
>  if (pcmc->smbios_legacy_mode) {
> -smbios_tables = smbios_get_table_legacy(ms->smp.cpus,
> -_tables_len);
> +smbios_tables = smbios_get_table_legacy(_tables_len);
>  fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
>   smbios_tables, smbios_tables_len);
>  return;
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index aa2cc5bdbd..97cf762228 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -482,14 +482,17 @@ opts_init(smbios_register_config);
>   */
>  #define SMBIOS_21_MAX_TABLES_LEN 0x
>
> -static void smbios_validate_table(uint32_t expected_t4_count)
> +static void smbios_check_type4_count(uint32_t expected_t4_count)
>  {
>  if (smbios_type4_count && smbios_type4_count != expected_t4_count) {
>  error_report("Expected %d SMBIOS Type 4 tables, got %d instead",
>   expected_t4_count, smbios_type4_count);
>  exit(1);
>  }
> +}
>
> +static void smbios_validate_table(void)
> +{
>  if (smbios_ep_type == SMBIOS_ENTRY_POINT_TYPE_32 &&
>  smbios_tables_len > SMBIOS_21_MAX_TABLES_LEN) {
>  error_report("SMBIOS 2.1 table length %zu exceeds %d",
> @@ -574,7 +577,7 @@ static void smbios_build_type_1_fields(void)
>  }
>  }
>
> -uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length)
> +uint8_t *smbios_get_table_legacy(size_t *length)
>  {
>  int i;
>  size_t usr_offset;
> @@ -587,6 +590,12 @@ uint8_t *smbios_get_table_legacy(uint32_t 
> expected_t4_count, size_t *length)
>  exit(1);
>  }
>
> +if (test_bit(4, have_binfile_bitmap)) {
> +error_report("can't process table for smbios "
> + "type 4 on machine versions < 2.1!");
>

Re: [PATCH 06/19] smbios: get rid of smbios_legacy global

[Ani Sinha]

> On 29-Feb-2024, at 19:59, Igor Mammedov  wrote:
> 
> On Thu, 29 Feb 2024 16:23:21 +0530
> Ani Sinha  wrote:
> 
>>> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
>>> 
>>> clean up smbios_set_defaults() which is reused by legacy
>>> and non legacy machines from being aware of 'legacy' notion
>>> and need to turn it off. And push legacy handling up to
>>> PC machine code where it's relevant.
>>> 
>>> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

>>> ---
>>> PS: I've moved/kept legacy smbios_entries to smbios_get_tables()
>>> but it at least is not visible to API users. To get rid of it
>>> as well, it would be necessary to change how '-smbios' CLI
>>> option is processed. Which is done later in the series.
>>> ---
>>> include/hw/firmware/smbios.h |  2 +-
>>> hw/arm/virt.c|  2 +-
>>> hw/i386/fw_cfg.c |  7 ---
>>> hw/loongarch/virt.c  |  2 +-
>>> hw/riscv/virt.c  |  2 +-
>>> hw/smbios/smbios.c   | 35 +++
>>> 6 files changed, 23 insertions(+), 27 deletions(-)
>>> 
>>> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
>>> index a187fbbd3d..0818184834 100644
>>> --- a/include/hw/firmware/smbios.h
>>> +++ b/include/hw/firmware/smbios.h
>>> @@ -293,7 +293,7 @@ struct smbios_type_127 {
>>> void smbios_entry_add(QemuOpts *opts, Error **errp);
>>> void smbios_set_cpuid(uint32_t version, uint32_t features);
>>> void smbios_set_defaults(const char *manufacturer, const char *product,
>>> - const char *version, bool legacy_mode,
>>> + const char *version,
>>> bool uuid_encoded, SmbiosEntryPointType ep_type);
>>> void smbios_set_default_processor_family(uint16_t processor_family);
>>> uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t 
>>> *length);
>>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>>> index 0af1943697..8588681f27 100644
>>> --- a/hw/arm/virt.c
>>> +++ b/hw/arm/virt.c
>>> @@ -1633,7 +1633,7 @@ static void virt_build_smbios(VirtMachineState *vms)
>>>}
>>> 
>>>smbios_set_defaults("QEMU", product,
>>> -vmc->smbios_old_sys_ver ? "1.0" : mc->name, false,
>>> +vmc->smbios_old_sys_ver ? "1.0" : mc->name,
>>>true, SMBIOS_ENTRY_POINT_TYPE_64);
>>> 
>>>/* build the array of physical mem area from base_memmap */
>>> diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
>>> index fcb4fb0769..c1e9c0fd9c 100644
>>> --- a/hw/i386/fw_cfg.c
>>> +++ b/hw/i386/fw_cfg.c
>>> @@ -63,15 +63,16 @@ void fw_cfg_build_smbios(PCMachineState *pcms, 
>>> FWCfgState *fw_cfg)
>>>if (pcmc->smbios_defaults) {
>>>/* These values are guest ABI, do not change */
>>>smbios_set_defaults("QEMU", mc->desc, mc->name,
>>> -pcmc->smbios_legacy_mode, 
>>> pcmc->smbios_uuid_encoded,
>>> +pcmc->smbios_uuid_encoded,
>>>pcms->smbios_entry_point_type);
>>>}
>>> 
>>>/* tell smbios about cpuid version and features */
>>>smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
>>> 
>>> -smbios_tables = smbios_get_table_legacy(ms->smp.cpus, 
>>> _tables_len);
>>> -if (smbios_tables) {
>>> +if (pcmc->smbios_legacy_mode) {
>>> +smbios_tables = smbios_get_table_legacy(ms->smp.cpus,
>>> +_tables_len);
>>>fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
>>> smbios_tables, smbios_tables_len);
>>>return;
>>> diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
>>> index 0ad7d8c887..73fb3522ba 100644
>>> --- a/hw/loongarch/virt.c
>>> +++ b/hw/loongarch/virt.c
>>> @@ -320,7 +320,7 @@ static void virt_build_smbios(LoongArchMachineState 
>>> *lams)
>>>return;
>>>}
>>> 
>>> -smbios_set_defaults("QEMU", product, mc->name, false,
>>> +smbios_set_defaults("QEMU", product, mc->name,
>>>true, SMBIO

Re: [PATCH 06/19] smbios: get rid of smbios_legacy global

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> clean up smbios_set_defaults() which is reused by legacy
> and non legacy machines from being aware of 'legacy' notion
> and need to turn it off. And push legacy handling up to
> PC machine code where it's relevant.
> 
> Signed-off-by: Igor Mammedov 
> ---
> PS: I've moved/kept legacy smbios_entries to smbios_get_tables()
> but it at least is not visible to API users. To get rid of it
> as well, it would be necessary to change how '-smbios' CLI
> option is processed. Which is done later in the series.
> ---
> include/hw/firmware/smbios.h |  2 +-
> hw/arm/virt.c|  2 +-
> hw/i386/fw_cfg.c |  7 ---
> hw/loongarch/virt.c  |  2 +-
> hw/riscv/virt.c  |  2 +-
> hw/smbios/smbios.c   | 35 +++
> 6 files changed, 23 insertions(+), 27 deletions(-)
> 
> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
> index a187fbbd3d..0818184834 100644
> --- a/include/hw/firmware/smbios.h
> +++ b/include/hw/firmware/smbios.h
> @@ -293,7 +293,7 @@ struct smbios_type_127 {
> void smbios_entry_add(QemuOpts *opts, Error **errp);
> void smbios_set_cpuid(uint32_t version, uint32_t features);
> void smbios_set_defaults(const char *manufacturer, const char *product,
> - const char *version, bool legacy_mode,
> + const char *version,
>  bool uuid_encoded, SmbiosEntryPointType ep_type);
> void smbios_set_default_processor_family(uint16_t processor_family);
> uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length);
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 0af1943697..8588681f27 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1633,7 +1633,7 @@ static void virt_build_smbios(VirtMachineState *vms)
> }
> 
> smbios_set_defaults("QEMU", product,
> -vmc->smbios_old_sys_ver ? "1.0" : mc->name, false,
> +vmc->smbios_old_sys_ver ? "1.0" : mc->name,
> true, SMBIOS_ENTRY_POINT_TYPE_64);
> 
> /* build the array of physical mem area from base_memmap */
> diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
> index fcb4fb0769..c1e9c0fd9c 100644
> --- a/hw/i386/fw_cfg.c
> +++ b/hw/i386/fw_cfg.c
> @@ -63,15 +63,16 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
> *fw_cfg)
> if (pcmc->smbios_defaults) {
> /* These values are guest ABI, do not change */
> smbios_set_defaults("QEMU", mc->desc, mc->name,
> -pcmc->smbios_legacy_mode, 
> pcmc->smbios_uuid_encoded,
> +pcmc->smbios_uuid_encoded,
> pcms->smbios_entry_point_type);
> }
> 
> /* tell smbios about cpuid version and features */
> smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
> 
> -smbios_tables = smbios_get_table_legacy(ms->smp.cpus, 
> _tables_len);
> -if (smbios_tables) {
> +if (pcmc->smbios_legacy_mode) {
> +smbios_tables = smbios_get_table_legacy(ms->smp.cpus,
> +_tables_len);
> fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
>  smbios_tables, smbios_tables_len);
> return;
> diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
> index 0ad7d8c887..73fb3522ba 100644
> --- a/hw/loongarch/virt.c
> +++ b/hw/loongarch/virt.c
> @@ -320,7 +320,7 @@ static void virt_build_smbios(LoongArchMachineState *lams)
> return;
> }
> 
> -smbios_set_defaults("QEMU", product, mc->name, false,
> +smbios_set_defaults("QEMU", product, mc->name,
> true, SMBIOS_ENTRY_POINT_TYPE_64);
> 
> smbios_get_tables(ms, NULL, 0, _tables, _tables_len,
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index fd35c74781..e2c9529df2 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -1235,7 +1235,7 @@ static void virt_build_smbios(RISCVVirtState *s)
> product = "KVM Virtual Machine";
> }
> 
> -smbios_set_defaults("QEMU", product, mc->name, false,
> +smbios_set_defaults("QEMU", product, mc->name,
> true, SMBIOS_ENTRY_POINT_TYPE_64);
> 
> if (riscv_is_32bit(>soc[0])) {
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 15339d8dbe..c46fc93357 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -54,7 +54,6 @@ struct smbios_table {
> 
> static uint8_t *smbios_entries;
> static size_t smbios_entries_len;
> -static bool smbios_legacy = true;
> static bool smbios_uuid_encoded = true;
> /* end: legacy structures & constants for <= 2.0 machines */
> 
> @@ -570,9 +569,16 @@ static void smbios_build_type_1_fields(void)
> 
> uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length)
> {
> -if (!smbios_legacy) {
> -*length = 0;
> -return NULL;
> +/* drop unwanted 

Re: [PATCH 05/19] smbios: get rid of smbios_smp_sockets global

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> it makes smbios_validate_table() independent from
> smbios_smp_sockets global, which in turn lets
> smbios_get_tables() avoid using not related legacy code.
> 
Good cleanup!

> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 


> ---
> goal here is to isolate legacy handling from generic smbios_get_tables()
> ---
> include/hw/firmware/smbios.h |  2 +-
> hw/i386/fw_cfg.c |  2 +-
> hw/smbios/smbios.c   | 22 +-
> 3 files changed, 11 insertions(+), 15 deletions(-)
> 
> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
> index 6e514982d4..a187fbbd3d 100644
> --- a/include/hw/firmware/smbios.h
> +++ b/include/hw/firmware/smbios.h
> @@ -296,7 +296,7 @@ void smbios_set_defaults(const char *manufacturer, const 
> char *product,
>  const char *version, bool legacy_mode,
>  bool uuid_encoded, SmbiosEntryPointType ep_type);
> void smbios_set_default_processor_family(uint16_t processor_family);
> -uint8_t *smbios_get_table_legacy(MachineState *ms, size_t *length);
> +uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length);
> void smbios_get_tables(MachineState *ms,
>const struct smbios_phys_mem_area *mem_array,
>const unsigned int mem_array_size,
> diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
> index a635234e68..fcb4fb0769 100644
> --- a/hw/i386/fw_cfg.c
> +++ b/hw/i386/fw_cfg.c
> @@ -70,7 +70,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
> *fw_cfg)
> /* tell smbios about cpuid version and features */
> smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
> 
> -smbios_tables = smbios_get_table_legacy(ms, _tables_len);
> +smbios_tables = smbios_get_table_legacy(ms->smp.cpus, 
> _tables_len);
> if (smbios_tables) {
> fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
>  smbios_tables, smbios_tables_len);
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 8e86c62184..15339d8dbe 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -70,7 +70,7 @@ static SmbiosEntryPoint ep;
> static int smbios_type4_count = 0;
> static bool smbios_immutable;
> static bool smbios_have_defaults;
> -static uint32_t smbios_cpuid_version, smbios_cpuid_features, 
> smbios_smp_sockets;
> +static uint32_t smbios_cpuid_version, smbios_cpuid_features;
> 
> static DECLARE_BITMAP(have_binfile_bitmap, SMBIOS_MAX_TYPE+1);
> static DECLARE_BITMAP(have_fields_bitmap, SMBIOS_MAX_TYPE+1);
> @@ -476,14 +476,11 @@ opts_init(smbios_register_config);
>  */
> #define SMBIOS_21_MAX_TABLES_LEN 0x
> 
> -static void smbios_validate_table(MachineState *ms)
> +static void smbios_validate_table(uint32_t expected_t4_count)
> {
> -uint32_t expect_t4_count = smbios_legacy ?
> -ms->smp.cpus : smbios_smp_sockets;
> -
> -if (smbios_type4_count && smbios_type4_count != expect_t4_count) {
> +if (smbios_type4_count && smbios_type4_count != expected_t4_count) {
> error_report("Expected %d SMBIOS Type 4 tables, got %d instead",
> - expect_t4_count, smbios_type4_count);
> + expected_t4_count, smbios_type4_count);
> exit(1);
> }
> 
> @@ -571,7 +568,7 @@ static void smbios_build_type_1_fields(void)
> }
> }
> 
> -uint8_t *smbios_get_table_legacy(MachineState *ms, size_t *length)
> +uint8_t *smbios_get_table_legacy(uint32_t expected_t4_count, size_t *length)
> {
> if (!smbios_legacy) {
> *length = 0;
> @@ -581,7 +578,7 @@ uint8_t *smbios_get_table_legacy(MachineState *ms, size_t 
> *length)
> if (!smbios_immutable) {
> smbios_build_type_0_fields();
> smbios_build_type_1_fields();
> -smbios_validate_table(ms);
> +smbios_validate_table(expected_t4_count);
> smbios_immutable = true;
> }
> *length = smbios_entries_len;
> @@ -1112,10 +1109,9 @@ void smbios_get_tables(MachineState *ms,
> smbios_build_type_2_table();
> smbios_build_type_3_table();
> 
> -smbios_smp_sockets = ms->smp.sockets;
> -assert(smbios_smp_sockets >= 1);
> +assert(ms->smp.sockets >= 1);
> 
> -for (i = 0; i < smbios_smp_sockets; i++) {
> +for (i = 0; i < ms->smp.sockets; i++) {
> smbios_build_type_4_table(ms, i);
> }
> 
> @@ -1160,7 +1156,7 @@ void smbios_get_tables(MachineState *ms,
> smbios_build_type_41_table(errp);
> smbios_build_type_127_table();
> 
> -smbios_validate_table(ms);
> +smbios_validate_table(ms->smp.sockets);
> smbios_entry_point_setup();
> smbios_immutable = true;
> }
> -- 
> 2.39.3
> 

[PATCH v5] pc: q35: Bump max_cpus to 4096 vcpus

[Ani Sinha]

Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow up 
to 4096 vCPUs")
Linux kernel can support upto a maximum number of 4096 vcpus when MAXSMP is
enabled in the kernel. At present, QEMU has been tested to correctly boot a
linux guest with 4096 vcpus using the current edk2 upstream master branch that
has the fixes corresponding to the following two PRs:

https://github.com/tianocore/edk2/pull/5410
https://github.com/tianocore/edk2/pull/5418

The changes merged into edk2 with the above PRs will be in the upcoming 2024-05
release. With current seabios firmware, it boots fine with 4096 vcpus already.
So bump up the value max_cpus to 4096 for q35 machines versions 9 and newer.
Q35 machines versions 8.2 and older continue to support 1024 maximum vcpus
as before for compatibility reasons.

If KVM is not able to support the specified number of vcpus, QEMU would
return the following error messages:

$ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 1728
qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (1728) 
exceeds the recommended cpus supported by KVM (12)
qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus requested 
(1728) exceeds the recommended cpus supported by KVM (12)
Number of SMP cpus requested (1728) exceeds the maximum cpus supported by KVM 
(1024)

Cc: Daniel P. Berrangé 
Cc: Igor Mammedov 
Cc: Michael S. Tsirkin 
Cc: Julia Suvorova 
Cc: kra...@redhat.com
Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Igor Mammedov 
Reviewed-by: Gerd Hoffmann 
Signed-off-by: Ani Sinha 
---
 hw/i386/pc_q35.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Changelog:
v5: mention the PRs in the commit message. Add tags.
v4: tweaked commit message as per suggestion from danpb explicitly
stating that 4096 vcpus work with edk2 fixes that are going to be
available in the coming edk2 release.
v3: bump up to 4096 vcpus. It has now been tested to work with edk2.
See RH Jira: https://issues.redhat.com/browse/RHEL-22202
v2: bump up the vcpu number to 1856. Add failure messages from ekd2 in
the commit description.

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 45a4102e75..df63a92b78 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -350,7 +350,7 @@ static void pc_q35_machine_options(MachineClass *m)
 m->default_nic = "e1000e";
 m->default_kernel_irqchip_split = false;
 m->no_floppy = 1;
-m->max_cpus = 1024;
+m->max_cpus = 4096;
 m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
@@ -371,6 +371,7 @@ static void pc_q35_8_2_machine_options(MachineClass *m)
 {
 pc_q35_9_0_machine_options(m);
 m->alias = NULL;
+m->max_cpus = 1024;
 compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
 compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
 }
-- 
2.42.0

Re: [PATCH 03/19] tests: smbios: add test for legacy mode CLI options

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> Unfortunately having 2.0 machine type deprecated is not enough
> to get rid of legacy SMBIOS handling since 'isapc' also uses
> that and it's staying around.
> 
> Hence add test for CLI options handling to be sure that it
> ain't broken during SMBIOS code refactoring.
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
> tests/data/smbios/type11_blob.legacy | Bin 0 -> 10 bytes
> tests/qtest/bios-tables-test.c   |  17 +
> 2 files changed, 17 insertions(+)
> create mode 100644 tests/data/smbios/type11_blob.legacy
> 
> diff --git a/tests/data/smbios/type11_blob.legacy 
> b/tests/data/smbios/type11_blob.legacy
> new file mode 100644
> index 
> ..aef463aab903405958b0a85f85c5980671c08bee
> GIT binary patch
> literal 10
> Rcmd;PW!S(N;u;*n000Tp0s;U4
> 
> literal 0
> HcmV?d1
> 
> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
> index a116f88e1d..d1ff4db7a2 100644
> --- a/tests/qtest/bios-tables-test.c
> +++ b/tests/qtest/bios-tables-test.c
> @@ -2106,6 +2106,21 @@ static void test_acpi_pc_smbios_blob(void)
> free_test_data();
> }
> 
> +static void test_acpi_isapc_smbios_legacy(void)
> +{
> +uint8_t req_type11[] = { 1, 11 };
> +test_data data = {
> +.machine = "isapc",
> +.variant = ".pc_smbios_legacy",
> +.required_struct_types = req_type11,
> +.required_struct_types_len = ARRAY_SIZE(req_type11),
> +};
> +
> +test_smbios("-smbios file=tests/data/smbios/type11_blob.legacy "
> +"-smbios type=1,family=TEST", );
> +free_test_data();
> +}
> +
> static void test_oem_fields(test_data *data)
> {
> int i;
> @@ -2261,6 +2276,8 @@ int main(int argc, char *argv[])
>test_acpi_pc_smbios_options);
> qtest_add_func("acpi/piix4/smbios-blob",
>test_acpi_pc_smbios_blob);
> +qtest_add_func("acpi/piix4/smbios-legacy",
> +   test_acpi_isapc_smbios_legacy);
> }
> if (qtest_has_machine(MACHINE_Q35)) {
> qtest_add_func("acpi/q35", test_acpi_q35_tcg);
> -- 
> 2.39.3
> 

Re: [PATCH v4] pc: q35: Bump max_cpus to 4096 vcpus

[Ani Sinha]

> On 28-Feb-2024, at 17:12, Gerd Hoffmann  wrote:
> 
> On Wed, Feb 21, 2024 at 07:32:27PM +0530, Ani Sinha wrote:
>> Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow 
>> up to 4096 vCPUs")
>> Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
>> enabled in the kernel. At present, QEMU has been tested to correctly boot a
>> linux guest with 4096 vcpus with edk2 pending various upstream EDK2 fixes
>> which will probably be in the 2024-05 release to be released in the coming
> 
> Merged meanwhile, so 2024-05 release is a sure thing and latest edk2
> master branch is good too.
> 
> You might refine the commit message saying so.

Can I refer to your two pull requests 
https://github.com/tianocore/edk2/pull/5410
https://github.com/tianocore/edk2/pull/5418

In the commit log? I think they are not ephemeral.

> With or without that:
> Reviewed-by: Gerd Hoffmann 
> 
> take care,
>  Gerd
> 

Re: [PATCH 04/19] smbios: cleanup smbios_get_tables() from legacy handling

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> smbios_get_tables() bails out right away if leagacy mode is enabled
> and won't generate any SMBIOS tables. At the same time x86 specific
> fw_cfg_build_smbios() will genarate legacy tables and then proceed
> to preparing temporary mem_array for useless call to
> smbios_get_tables() and then discard it.
> 
> Drop legacy related check in smbios_get_tables() and return from
> fw_cfg_build_smbios() early if legacy tables where built without
> proceeding to non legacy part of the function.
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
> hw/i386/fw_cfg.c   | 1 +
> hw/smbios/smbios.c | 6 --
> 2 files changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
> index 98a478c276..a635234e68 100644
> --- a/hw/i386/fw_cfg.c
> +++ b/hw/i386/fw_cfg.c
> @@ -74,6 +74,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
> *fw_cfg)
> if (smbios_tables) {
> fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
>  smbios_tables, smbios_tables_len);
> +return;
> }
> 
> /* build the array of physical mem area from e820 table */
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index a3c4e52ce9..8e86c62184 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -1106,12 +1106,6 @@ void smbios_get_tables(MachineState *ms,
> {
> unsigned i, dimm_cnt, offset;
> 
> -if (smbios_legacy) {
> -*tables = *anchor = NULL;
> -*tables_len = *anchor_len = 0;
> -return;
> -}
> -
> if (!smbios_immutable) {
> smbios_build_type_0_table();
> smbios_build_type_1_table();
> -- 
> 2.39.3
> 

Re: [PATCH 03/19] tests: smbios: add test for legacy mode CLI options

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> Unfortunately having 2.0 machine type deprecated is not enough
> to get rid of legacy SMBIOS handling since 'isapc' also uses
> that and it's staying around.
> 
> Hence add test for CLI options handling to be sure that it
> ain't broken during SMBIOS code refactoring.
> 
> Signed-off-by: Igor Mammedov 
> ---
> tests/data/smbios/type11_blob.legacy | Bin 0 -> 10 bytes
> tests/qtest/bios-tables-test.c   |  17 +
> 2 files changed, 17 insertions(+)
> create mode 100644 tests/data/smbios/type11_blob.legacy
> 
> diff --git a/tests/data/smbios/type11_blob.legacy 
> b/tests/data/smbios/type11_blob.legacy
> new file mode 100644
> index 
> ..aef463aab903405958b0a85f85c5980671c08bee
> GIT binary patch
> literal 10
> Rcmd;PW!S(N;u;*n000Tp0s;U4
> 
> literal 0
> HcmV?d1
> 
> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
> index a116f88e1d..d1ff4db7a2 100644
> --- a/tests/qtest/bios-tables-test.c
> +++ b/tests/qtest/bios-tables-test.c
> @@ -2106,6 +2106,21 @@ static void test_acpi_pc_smbios_blob(void)
> free_test_data();
> }
> 
> +static void test_acpi_isapc_smbios_legacy(void)
> +{
> +uint8_t req_type11[] = { 1, 11 };

Ok so looking at the code, it won’t let you specify smbios type other than 1 …

See the following in smbios_set_defaults()

  if (smbios_legacy) {
g_free(smbios_tables);
/* in legacy mode, also complain if fields were given for types >1 */
if (find_next_bit(have_fields_bitmap,
  SMBIOS_MAX_TYPE+1, 2) < SMBIOS_MAX_TYPE+1) {
error_report("can't process fields for smbios "
 "types > 1 on machine versions < 2.1!");
exit(1);
}
} else {

BUT you lets you load a blob of type 11? Is that a bug in QEMU? Should we also 
add a similar check for have_binfile_bitmap? 

> +test_data data = {
> +.machine = "isapc",
> +.variant = ".pc_smbios_legacy",
> +.required_struct_types = req_type11,
> +.required_struct_types_len = ARRAY_SIZE(req_type11),
> +};
> +
> +test_smbios("-smbios file=tests/data/smbios/type11_blob.legacy "
> +"-smbios type=1,family=TEST", );
> +free_test_data();
> +}
> +
> static void test_oem_fields(test_data *data)
> {
> int i;
> @@ -2261,6 +2276,8 @@ int main(int argc, char *argv[])
>test_acpi_pc_smbios_options);
> qtest_add_func("acpi/piix4/smbios-blob",
>test_acpi_pc_smbios_blob);
> +qtest_add_func("acpi/piix4/smbios-legacy",
> +   test_acpi_isapc_smbios_legacy);
> }
> if (qtest_has_machine(MACHINE_Q35)) {
> qtest_add_func("acpi/q35", test_acpi_q35_tcg);
> -- 
> 2.39.3
> 

Re: [PATCH 02/19] tests: smbios: add test for -smbios type=11 option

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> Signed-off-by: Igor Mammedov 

Empty description is not nice. Other than that,

Reviewed-by: Ani Sinha 

> ---
> tests/data/smbios/type11_blob  | Bin 0 -> 11 bytes
> tests/qtest/bios-tables-test.c |  17 +
> 2 files changed, 17 insertions(+)
> create mode 100644 tests/data/smbios/type11_blob
> 
> diff --git a/tests/data/smbios/type11_blob b/tests/data/smbios/type11_blob
> new file mode 100644
> index 
> ..1d8fea4b0c6f040a13ba99c3fad762538b795614
> GIT binary patch
> literal 11
> Scmd;PW!S(N;u;*nzyJUX)?m
> 
> literal 0
> HcmV?d1
> 
> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
> index b2992bafa8..a116f88e1d 100644
> --- a/tests/qtest/bios-tables-test.c
> +++ b/tests/qtest/bios-tables-test.c
> @@ -2091,6 +2091,21 @@ static void test_acpi_pc_smbios_options(void)
> free_test_data();
> }
> 
> +static void test_acpi_pc_smbios_blob(void)
> +{
> +uint8_t req_type11[] = { 11 };
> +test_data data = {
> +.machine = MACHINE_PC,
> +.variant = ".pc_smbios_blob",
> +.required_struct_types = req_type11,
> +.required_struct_types_len = ARRAY_SIZE(req_type11),
> +};
> +
> +test_smbios("-machine smbios-entry-point-type=32 "
> +"-smbios file=tests/data/smbios/type11_blob", );
> +free_test_data();
> +}
> +
> static void test_oem_fields(test_data *data)
> {
> int i;
> @@ -2244,6 +2259,8 @@ int main(int argc, char *argv[])
> #endif
> qtest_add_func("acpi/piix4/smbios-options",
>test_acpi_pc_smbios_options);
> +qtest_add_func("acpi/piix4/smbios-blob",
> +   test_acpi_pc_smbios_blob);
> }
> if (qtest_has_machine(MACHINE_Q35)) {
> qtest_add_func("acpi/q35", test_acpi_q35_tcg);
> -- 
> 2.39.3
> 

Re: [PATCH 01/19] tests: smbios: make it possible to write SMBIOS only test

[Ani Sinha]

> On 27-Feb-2024, at 21:17, Igor Mammedov  wrote:
> 
> Cureently it not possible to run SMBIOS test without ACPI one,
> which gets into the way when testing ACPI-less configs.
> 
> Extract SMBIOS testing into separate routines that could also
> be run without ACPI dependency and use that for testing SMBIOS.
> 
> As the 1st user add "acpi/piix4/smbios-options" test case.
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Ani Sinha 

> ---
> tests/qtest/bios-tables-test.c | 47 +++---
> 1 file changed, 38 insertions(+), 9 deletions(-)
> 
> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
> index 21811a1ab5..b2992bafa8 100644
> --- a/tests/qtest/bios-tables-test.c
> +++ b/tests/qtest/bios-tables-test.c
> @@ -858,16 +858,8 @@ static void test_vm_prepare(const char *params, 
> test_data *data)
> g_free(args);
> }
> 
> -static void process_acpi_tables_noexit(test_data *data)
> +static void process_smbios_tables_noexit(test_data *data)
> {
> -test_acpi_load_tables(data);
> -
> -if (getenv(ACPI_REBUILD_EXPECTED_AML)) {
> -dump_aml_files(data, true);
> -} else {
> -test_acpi_asl(data);
> -}
> -
> /*
>  * TODO: make SMBIOS tests work with UEFI firmware,
>  * Bug on uefi-test-tools to provide entry point:
> @@ -879,6 +871,27 @@ static void process_acpi_tables_noexit(test_data *data)
> }
> }
> 
> +static void test_smbios(const char *params, test_data *data)
> +{
> +test_vm_prepare(params, data);
> +boot_sector_test(data->qts);
> +process_smbios_tables_noexit(data);
> +qtest_quit(data->qts);
> +}
> +
> +static void process_acpi_tables_noexit(test_data *data)
> +{
> +test_acpi_load_tables(data);
> +
> +if (getenv(ACPI_REBUILD_EXPECTED_AML)) {
> +dump_aml_files(data, true);
> +} else {
> +test_acpi_asl(data);
> +}
> +
> +process_smbios_tables_noexit(data);
> +}
> +
> static void process_acpi_tables(test_data *data)
> {
> process_acpi_tables_noexit(data);
> @@ -2064,6 +2077,20 @@ static void test_acpi_q35_pvpanic_isa(void)
> free_test_data();
> }
> 
> +static void test_acpi_pc_smbios_options(void)
> +{
> +uint8_t req_type11[] = { 11 };
> +test_data data = {
> +.machine = MACHINE_PC,
> +.variant = ".pc_smbios_options",
> +.required_struct_types = req_type11,
> +.required_struct_types_len = ARRAY_SIZE(req_type11),
> +};
> +
> +test_smbios("-smbios type=11,value=TEST", );
> +free_test_data();
> +}
> +
> static void test_oem_fields(test_data *data)
> {
> int i;
> @@ -2215,6 +2242,8 @@ int main(int argc, char *argv[])
> #ifdef CONFIG_POSIX
> qtest_add_func("acpi/piix4/acpierst", test_acpi_piix4_acpi_erst);
> #endif
> +qtest_add_func("acpi/piix4/smbios-options",
> +   test_acpi_pc_smbios_options);
> }
> if (qtest_has_machine(MACHINE_Q35)) {
> qtest_add_func("acpi/q35", test_acpi_q35_tcg);
> -- 
> 2.39.3
> 

[PATCH v4] pc: q35: Bump max_cpus to 4096 vcpus

[Ani Sinha]

Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow up 
to 4096 vCPUs")
Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
enabled in the kernel. At present, QEMU has been tested to correctly boot a
linux guest with 4096 vcpus with edk2 pending various upstream EDK2 fixes
which will probably be in the 2024-05 release to be released in the coming
months. With current seabios firmware, it boots fine with 4096 vcpus already.
So bump up the value max_cpus to 4096 for q35 machines versions 9 and newer.
Q35 machines versions 8.2 and older continue to support 1024 maximum vcpus
as before for compatibility reasons.

If KVM is not able to support the specified number of vcpus, QEMU would
return the following error messages:

$ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 1728
qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (1728) 
exceeds the recommended cpus supported by KVM (12)
qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus requested 
(1728) exceeds the recommended cpus supported by KVM (12)
Number of SMP cpus requested (1728) exceeds the maximum cpus supported by KVM 
(1024)

Cc: Daniel P. Berrangé 
Cc: Igor Mammedov 
Cc: Michael S. Tsirkin 
Cc: Julia Suvorova 
Cc: kra...@redhat.com
Reviewed-by: Daniel P. Berrangé 
Signed-off-by: Ani Sinha 
---
 hw/i386/pc_q35.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Changelog:
v4: tweaked commit message as per suggestion from danpb explicitly
stating that 4096 vcpus work with edk2 fixes that are going to be
available in the coming edk2 release.
v3: bump up to 4096 vcpus. It has now been tested to work with edk2.
See RH Jira: https://issues.redhat.com/browse/RHEL-22202
v2: bump up the vcpu number to 1856. Add failure messages from ekd2 in
the commit description.


diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d346fa3b1d..ae60e6b919 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -366,7 +366,7 @@ static void pc_q35_machine_options(MachineClass *m)
 m->default_nic = "e1000e";
 m->default_kernel_irqchip_split = false;
 m->no_floppy = 1;
-m->max_cpus = 1024;
+m->max_cpus = 4096;
 m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
@@ -387,6 +387,7 @@ static void pc_q35_8_2_machine_options(MachineClass *m)
 {
 pc_q35_9_0_machine_options(m);
 m->alias = NULL;
+m->max_cpus = 1024;
 compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
 compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
 }
-- 
2.42.0

Re: [PATCH v3] pc: q35: Bump max_cpus to 4096 vcpus

[Ani Sinha]

> On 20-Feb-2024, at 21:46, Gerd Hoffmann  wrote:
> 
> On Tue, Feb 20, 2024 at 03:50:57PM +, Daniel P. Berrangé wrote:
>> On Tue, Feb 20, 2024 at 09:12:04PM +0530, Ani Sinha wrote:
>>> Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow 
>>> up to 4096 vCPUs")
>>> Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
>>> enabled in the kernel. At present, QEMU has been tested to correctly boot a
>>> linux guest with 4096 vcpus both with edk2 and seabios firmwares.
>>> So bump up the value max_cpus to 4096 for q35 machines versions 9 and newer.
>>> Q35 machines versions 8.2 and older continue to support 1024 maximum vcpus
>>> as before for compatibility reasons.
>>> 
>>> If KVM is not able to support the specified number of vcpus, QEMU would
>>> return the following error messages:
>>> 
>>> $ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 1728
>>> qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested 
>>> (1728) exceeds the recommended cpus supported by KVM (12)
>>> qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus 
>>> requested (1728) exceeds the recommended cpus supported by KVM (12)
>>> Number of SMP cpus requested (1728) exceeds the maximum cpus supported by 
>>> KVM (1024)
>>> 
>>> Cc: Daniel P. Berrangé 
>>> Cc: Igor Mammedov 
>>> Cc: Michael S. Tsirkin 
>>> Cc: Julia Suvorova 
>>> Cc: kra...@redhat.com
>>> Signed-off-by: Ani Sinha 
>>> ---
>>> hw/i386/pc_q35.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> Changelog:
>>> v3: bump up to 4096 vcpus. It has now been tested to work with edk2.
>>> See RH Jira: https://issues.redhat.com/browse/RHEL-22202
>> 
>> That bug indicates a dependancy on a EDK2 patch
>> 
>>  
>> https://github.com/kraxel/edk2/commit/7a03c17f0f4f4a9003d77db2660c8e087604b2f0
>> 
>> we'll need to rebase the EDK2 ROMs in QEMU to get that included.
> 
> Which will btw take a while.  edk2 is in freeze for the 2024-02 release
> right now, I expect the changes land upstream shortly thereafter and
> will be part of the 2024-05 release.  So end may / early june would be
> the time when rebasing to release, or somewhen in march or april when we
> rebase to a git snapshot ...
> 
>> Meanwhile, plesae at least call out this EDK2 commit as a
>> pre-requisite in the commit message, so people know the
>> EDK2 ROMs in QEMU won't work (yet).
> 
> That surely makes sense.
> 
> Oh, and it's more than just that one commit.  I don't think it makes
> sense to compile a list of commits given this is a moving target
> (upstream review is in progress right now).

Looking at the edk2 GH, are these the PR that are waiting for upstream 
review/merge that relate to vcpu scaling?

https://github.com/tianocore/edk2/pull/5375
https://github.com/tianocore/edk2/pull/5327

[PATCH v3] pc: q35: Bump max_cpus to 4096 vcpus

[Ani Sinha]

Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow up 
to 4096 vCPUs")
Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
enabled in the kernel. At present, QEMU has been tested to correctly boot a
linux guest with 4096 vcpus both with edk2 and seabios firmwares.
So bump up the value max_cpus to 4096 for q35 machines versions 9 and newer.
Q35 machines versions 8.2 and older continue to support 1024 maximum vcpus
as before for compatibility reasons.

If KVM is not able to support the specified number of vcpus, QEMU would
return the following error messages:

$ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 1728
qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (1728) 
exceeds the recommended cpus supported by KVM (12)
qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus requested 
(1728) exceeds the recommended cpus supported by KVM (12)
Number of SMP cpus requested (1728) exceeds the maximum cpus supported by KVM 
(1024)

Cc: Daniel P. Berrangé 
Cc: Igor Mammedov 
Cc: Michael S. Tsirkin 
Cc: Julia Suvorova 
Cc: kra...@redhat.com
Signed-off-by: Ani Sinha 
---
 hw/i386/pc_q35.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Changelog:
v3: bump up to 4096 vcpus. It has now been tested to work with edk2.
See RH Jira: https://issues.redhat.com/browse/RHEL-22202

v2: bump up the vcpu number to 1856. Add failure messages from ekd2 in
the commit description.

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d346fa3b1d..ae60e6b919 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -366,7 +366,7 @@ static void pc_q35_machine_options(MachineClass *m)
 m->default_nic = "e1000e";
 m->default_kernel_irqchip_split = false;
 m->no_floppy = 1;
-m->max_cpus = 1024;
+m->max_cpus = 4096;
 m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
@@ -387,6 +387,7 @@ static void pc_q35_8_2_machine_options(MachineClass *m)
 {
 pc_q35_9_0_machine_options(m);
 m->alias = NULL;
+m->max_cpus = 1024;
 compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
 compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
 }
-- 
2.42.0

Re: [PATCH v2] pc: q35: Bump max_cpus to 1856 vcpus

[Ani Sinha]

> On 31-Jan-2024, at 17:24, Gerd Hoffmann  wrote:
> 
> On Wed, Jan 31, 2024 at 08:19:06AM +0530, Ani Sinha wrote:
> 
>> This error exists only with edk2. Seabios currently can boot a linux guest
>> fine with 4096 vcpus. Since the lowest common denominator for a working VM 
>> for
>> both edk2 and seabios is 1856 vcpus, bump up the value max_cpus to 1856 for 
>> q35
>> machines versions 9 and newer. Q35 machines versions 8.2 and older continue
>> to support 1024 maximum vcpus as before for compatibility reasons.
> 
> There is a high chance this limit will be gone soon.
> 
> https://github.com/kraxel/edk2/commit/7a03c17f0f4f4a9003d77db2660c8e087604b2f0
> 
> If 4096 works fine with seabios, I'd suggest to go with 4096 as limit.

Any updates on this? Looking at https://issues.redhat.com/browse/RHEL-22202 , 
seems there is still some outstanding issues?

Re: [PATCH v2] pc: q35: Bump max_cpus to 1856 vcpus

[Ani Sinha]

On Wed, Jan 31, 2024 at 9:27 AM Zhao Liu  wrote:
>
> Hi Ani,
>
> On Wed, Jan 31, 2024 at 08:19:06AM +0530, Ani Sinha wrote:
> > Date: Wed, 31 Jan 2024 08:19:06 +0530
> > From: Ani Sinha 
> > Subject: [PATCH v2] pc: q35: Bump max_cpus to 1856 vcpus
> > X-Mailer: git-send-email 2.42.0
> >
> > Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow 
> > up to 4096 vCPUs")
> > Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
> > enabled in the kernel. At present, QEMU has been tested to correctly boot a
> > linux guest with 1856 vcpus and no more both with edk2 and seabios 
> > firmwares.
>
> About background, could I ask if there will be Host machines with so
> much CPUs? What are the benefits of vCPUs that far exceed the number
> of Host CPUs?

Yes HPE has SAP HANA host machines with large numbers of physical
cores and memory. For example QEMU was tested on a system with 3840
cores.

>
> Thanks,
> Zhao
>
> > If an additional vcpu is added, that is with 1857 vcpus, edk2 currently 
> > fails
> > with the following error messages:
> >
> > AllocatePages failed: No 0x400 Pages is available.
> > There is only left 0x2BF pages memory resource to be allocated.
> > ERROR: Out of aligned pages
> > ASSERT 
> > /builddir/build/BUILD/edk2-ba91d0292e/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c(814):
> >  BigPageAddress != 0
> >
> > This error exists only with edk2. Seabios currently can boot a linux guest
> > fine with 4096 vcpus. Since the lowest common denominator for a working VM 
> > for
> > both edk2 and seabios is 1856 vcpus, bump up the value max_cpus to 1856 for 
> > q35
> > machines versions 9 and newer. Q35 machines versions 8.2 and older continue
> > to support 1024 maximum vcpus as before for compatibility reasons.
> >
> > If KVM is not able to support the specified number of vcpus, QEMU would
> > return the following error messages:
> >
> > $ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 1728
> > qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested 
> > (1728) exceeds the recommended cpus supported by KVM (12)
> > qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus 
> > requested (1728) exceeds the recommended cpus supported by KVM (12)
> > Number of SMP cpus requested (1728) exceeds the maximum cpus supported by 
> > KVM (1024)
> >
> > Cc: Daniel P. Berrangé 
> > Cc: Igor Mammedov 
> > Cc: Michael S. Tsirkin 
> > Cc: Julia Suvorova 
> > Cc: kra...@redhat.com
> > Signed-off-by: Ani Sinha 
> > ---
> >  hw/i386/pc_q35.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > Changelog:
> > v2: bump up the vcpu number to 1856. Add failure messages from ekd2 in
> > the commit description.
> > See also RH Jira https://issues.redhat.com/browse/RHEL-22202
> >
> > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> > index f43d5142b8..f9c4b6594d 100644
> > --- a/hw/i386/pc_q35.c
> > +++ b/hw/i386/pc_q35.c
> > @@ -375,7 +375,7 @@ static void pc_q35_machine_options(MachineClass *m)
> >  m->default_nic = "e1000e";
> >  m->default_kernel_irqchip_split = false;
> >  m->no_floppy = 1;
> > -m->max_cpus = 1024;
> > +m->max_cpus = 1856;
> >  m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
> >  machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
> >  machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
> > @@ -396,6 +396,7 @@ static void pc_q35_8_2_machine_options(MachineClass *m)
> >  {
> >  pc_q35_9_0_machine_options(m);
> >  m->alias = NULL;
> > +m->max_cpus = 1024;
> >  compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
> >  compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
> >  }
> > --
> > 2.42.0
> >
> >
>

[PATCH v2] pc: q35: Bump max_cpus to 1856 vcpus

[Ani Sinha]

Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow up 
to 4096 vCPUs")
Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
enabled in the kernel. At present, QEMU has been tested to correctly boot a
linux guest with 1856 vcpus and no more both with edk2 and seabios firmwares.
If an additional vcpu is added, that is with 1857 vcpus, edk2 currently fails
with the following error messages:

AllocatePages failed: No 0x400 Pages is available.
There is only left 0x2BF pages memory resource to be allocated.
ERROR: Out of aligned pages
ASSERT 
/builddir/build/BUILD/edk2-ba91d0292e/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c(814):
 BigPageAddress != 0

This error exists only with edk2. Seabios currently can boot a linux guest
fine with 4096 vcpus. Since the lowest common denominator for a working VM for
both edk2 and seabios is 1856 vcpus, bump up the value max_cpus to 1856 for q35
machines versions 9 and newer. Q35 machines versions 8.2 and older continue
to support 1024 maximum vcpus as before for compatibility reasons.

If KVM is not able to support the specified number of vcpus, QEMU would
return the following error messages:

$ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 1728
qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (1728) 
exceeds the recommended cpus supported by KVM (12)
qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus requested 
(1728) exceeds the recommended cpus supported by KVM (12)
Number of SMP cpus requested (1728) exceeds the maximum cpus supported by KVM 
(1024)

Cc: Daniel P. Berrangé 
Cc: Igor Mammedov 
Cc: Michael S. Tsirkin 
Cc: Julia Suvorova 
Cc: kra...@redhat.com
Signed-off-by: Ani Sinha 
---
 hw/i386/pc_q35.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Changelog:
v2: bump up the vcpu number to 1856. Add failure messages from ekd2 in
the commit description.
See also RH Jira https://issues.redhat.com/browse/RHEL-22202

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index f43d5142b8..f9c4b6594d 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -375,7 +375,7 @@ static void pc_q35_machine_options(MachineClass *m)
 m->default_nic = "e1000e";
 m->default_kernel_irqchip_split = false;
 m->no_floppy = 1;
-m->max_cpus = 1024;
+m->max_cpus = 1856;
 m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
@@ -396,6 +396,7 @@ static void pc_q35_8_2_machine_options(MachineClass *m)
 {
 pc_q35_9_0_machine_options(m);
 m->alias = NULL;
+m->max_cpus = 1024;
 compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
 compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
 }
-- 
2.42.0

Re: [PATCH v2 3/3] hw/arm: Add `\n` to hint message

[Ani Sinha]

> On 30-Jan-2024, at 22:07, Greg Kurz  wrote:
> 
> error_printf() doesn't add newlines.
> 
> Signed-off-by: Greg Kurz 

Reviewed-by: Ani Sinha 

> ---
> hw/arm/virt-acpi-build.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 17aeec7a6f56..48febde1ccd1 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -1008,7 +1008,7 @@ void virt_acpi_build(VirtMachineState *vms, 
> AcpiBuildTables *tables)
> " migration may not work",
> tables_blob->len, ACPI_BUILD_TABLE_SIZE / 2);
> error_printf("Try removing CPUs, NUMA nodes, memory slots"
> - " or PCI bridges.");
> + " or PCI bridges.\n");
> }
> acpi_align_size(tables_blob, ACPI_BUILD_TABLE_SIZE);
> 
> -- 
> 2.43.0
> 

Re: [PATCH] pc: q35: Bump max_cpus to 1728 vcpus

[Ani Sinha]

> On 30-Jan-2024, at 22:17, Daniel P. Berrangé  wrote:
> 
> On Tue, Jan 30, 2024 at 10:14:28PM +0530, Ani Sinha wrote:
>> Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow 
>> up to 4096 vCPUs")
>> Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
>> enabled in the kernel. QEMU has been tested to correctly boot a linux guest
>> with 1728 vcpus both with edk2 and seabios firmwares. So bump up the max_cpus
>> value for q35 machines versions 9 and newer to 1728. Q35 machines versions
>> 8.2 and older continue to support 1024 maximum vcpus as before for
>> compatibility.
> 
> Where does the 1728 number come from ?
> 
> Did something break at 1729, or did the test machine simply not
> have sufficient resources to do practical larger tests ?

Actual limit currently is 1856 for EDK2. The HPE folks tested QEMU with edk2 
and QEMU fails to boot beyond that limit.
There are RH internal bugs tracking this and Gerd is working on it from RH side 
[1].

We would ultimately like to go to 8192 vcpus for SAP HANA but 1728 vcpus is our 
immediate target for now. If you want, I can resend the patch with 1856 since 
that is currently the tested limit.

1. https://issues.redhat.com/browse/RHEL-22202


> 
>> 
>> If KVM is not able to support the specified number of vcpus, QEMU would
>> return the following error messages:
>> 
>> $ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 1728
>> qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (1728) 
>> exceeds the recommended cpus supported by KVM (12)
>> qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus 
>> requested (1728) exceeds the recommended cpus supported by KVM (12)
>> Number of SMP cpus requested (1728) exceeds the maximum cpus supported by 
>> KVM (1024)
>> 
>> Cc: Daniel P. Berrangé 
>> Cc: Igor Mammedov 
>> Cc: Michael S. Tsirkin 
>> Cc: Julia Suvorova 
>> Signed-off-by: Ani Sinha 
>> ---
>> hw/i386/pc_q35.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
>> index f43d5142b8..bfa627a70b 100644
>> --- a/hw/i386/pc_q35.c
>> +++ b/hw/i386/pc_q35.c
>> @@ -375,7 +375,7 @@ static void pc_q35_machine_options(MachineClass *m)
>> m->default_nic = "e1000e";
>> m->default_kernel_irqchip_split = false;
>> m->no_floppy = 1;
>> -m->max_cpus = 1024;
>> +m->max_cpus = 1728;
>> m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
>> machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
>> machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
>> @@ -396,6 +396,7 @@ static void pc_q35_8_2_machine_options(MachineClass *m)
>> {
>> pc_q35_9_0_machine_options(m);
>> m->alias = NULL;
>> +m->max_cpus = 1024;
>> compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
>> compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
>> }
>> -- 
>> 2.42.0
>> 
> 
> With regards,
> Daniel
> -- 
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [PATCH v2 1/3] hw/i386: Add `\n` to hint message

[Ani Sinha]

> On 30-Jan-2024, at 22:07, Greg Kurz  wrote:
> 
> error_printf() doesn't add newlines.
> 
> Signed-off-by: Greg Kurz 

Reviewed-by: Ani Sinha 

> ---
> hw/i386/acpi-build.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index edc979379c03..e990b0ae927f 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2697,7 +2697,7 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
> *machine)
> " migration may not work",
> tables_blob->len, legacy_table_size);
> error_printf("Try removing CPUs, NUMA nodes, memory slots"
> - " or PCI bridges.");
> + " or PCI bridges.\n");
> }
> g_array_set_size(tables_blob, legacy_table_size);
> } else {
> @@ -2709,7 +2709,7 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
> *machine)
> " migration may not work",
> tables_blob->len, ACPI_BUILD_TABLE_SIZE / 2);
> error_printf("Try removing CPUs, NUMA nodes, memory slots"
> - " or PCI bridges.");
> + " or PCI bridges.\n");
> }
> acpi_align_size(tables_blob, ACPI_BUILD_TABLE_SIZE);
> }
> -- 
> 2.43.0
> 

Re: [PATCH v2 2/3] hw/loongarch: Add `\n` to hint message

[Ani Sinha]

> On 30-Jan-2024, at 22:07, Greg Kurz  wrote:
> 
> error_printf() doesn't add newlines.
> 
> Signed-off-by: Greg Kurz 

Reviewed-by: Ani Sinha 

> ---
> hw/loongarch/acpi-build.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/loongarch/acpi-build.c b/hw/loongarch/acpi-build.c
> index 730bc4a748c4..a1c419874123 100644
> --- a/hw/loongarch/acpi-build.c
> +++ b/hw/loongarch/acpi-build.c
> @@ -509,7 +509,7 @@ static void acpi_build(AcpiBuildTables *tables, 
> MachineState *machine)
> " migration may not work",
> tables_blob->len, ACPI_BUILD_TABLE_SIZE / 2);
> error_printf("Try removing CPUs, NUMA nodes, memory slots"
> - " or PCI bridges.");
> + " or PCI bridges.\n");
> }
> 
> acpi_align_size(tables->linker->cmd_blob, ACPI_BUILD_ALIGN_SIZE);
> -- 
> 2.43.0
> 

[PATCH] pc: q35: Bump max_cpus to 1728 vcpus

[Ani Sinha]

Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow up 
to 4096 vCPUs")
Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
enabled in the kernel. QEMU has been tested to correctly boot a linux guest
with 1728 vcpus both with edk2 and seabios firmwares. So bump up the max_cpus
value for q35 machines versions 9 and newer to 1728. Q35 machines versions
8.2 and older continue to support 1024 maximum vcpus as before for
compatibility.

If KVM is not able to support the specified number of vcpus, QEMU would
return the following error messages:

$ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 1728
qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (1728) 
exceeds the recommended cpus supported by KVM (12)
qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus requested 
(1728) exceeds the recommended cpus supported by KVM (12)
Number of SMP cpus requested (1728) exceeds the maximum cpus supported by KVM 
(1024)

Cc: Daniel P. Berrangé 
Cc: Igor Mammedov 
Cc: Michael S. Tsirkin 
Cc: Julia Suvorova 
Signed-off-by: Ani Sinha 
---
 hw/i386/pc_q35.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index f43d5142b8..bfa627a70b 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -375,7 +375,7 @@ static void pc_q35_machine_options(MachineClass *m)
 m->default_nic = "e1000e";
 m->default_kernel_irqchip_split = false;
 m->no_floppy = 1;
-m->max_cpus = 1024;
+m->max_cpus = 1728;
 m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
@@ -396,6 +396,7 @@ static void pc_q35_8_2_machine_options(MachineClass *m)
 {
 pc_q35_9_0_machine_options(m);
 m->alias = NULL;
+m->max_cpus = 1024;
 compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
 compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
 }
-- 
2.42.0

Re: [PATCH 1/3] hw/i386: Add `\n` to hint message

[Ani Sinha]

> On 30-Jan-2024, at 21:26, Greg Kurz  wrote:
> 
> error_fprintf() doesn't add newlines.

^

Should be error_printf(). Ditto for other patches.

> 
> Signed-off-by: Greg Kurz 
> ---
> hw/i386/acpi-build.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index edc979379c03..e990b0ae927f 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2697,7 +2697,7 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
> *machine)
> " migration may not work",
> tables_blob->len, legacy_table_size);
> error_printf("Try removing CPUs, NUMA nodes, memory slots"
> - " or PCI bridges.");
> + " or PCI bridges.\n");
> }
> g_array_set_size(tables_blob, legacy_table_size);
> } else {
> @@ -2709,7 +2709,7 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
> *machine)
> " migration may not work",
> tables_blob->len, ACPI_BUILD_TABLE_SIZE / 2);
> error_printf("Try removing CPUs, NUMA nodes, memory slots"
> - " or PCI bridges.");
> + " or PCI bridges.\n");
> }
> acpi_align_size(tables_blob, ACPI_BUILD_TABLE_SIZE);
> }
> -- 
> 2.43.0
> 

Re: [PATCH v2 1/2] hw/smbios: Fix OEM strings table option validation

[Ani Sinha]

> On 29-Jan-2024, at 13:33, Akihiko Odaki  wrote:
> 
> qemu_smbios_type11_opts did not have the list terminator and that
> resulted in out-of-bound memory access. It also needs to have an element
> for the type option.
> 
> Cc: qemu-sta...@nongnu.org
> Fixes: 2d6dcbf93fb0 ("smbios: support setting OEM strings table")
> Signed-off-by: Akihiko Odaki 
> Reviewed-by: Michael Tokarev 

Reviewed-by: Ani Sinha 
> ---
> hw/smbios/smbios.c | 6 ++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 2a90601ac5d9..522ed1ed9fe3 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -369,6 +369,11 @@ static const QemuOptDesc qemu_smbios_type8_opts[] = {
> };
> 
> static const QemuOptDesc qemu_smbios_type11_opts[] = {
> +{
> +.name = "type",
> +.type = QEMU_OPT_NUMBER,
> +.help = "SMBIOS element type",
> +},
> {
> .name = "value",
> .type = QEMU_OPT_STRING,
> @@ -379,6 +384,7 @@ static const QemuOptDesc qemu_smbios_type11_opts[] = {
> .type = QEMU_OPT_STRING,
> .help = "OEM string data from file",
> },
> +{ /* end of list */ }
> };
> 
> static const QemuOptDesc qemu_smbios_type17_opts[] = {
> 
> -- 
> 2.43.0
> 

Re: [PATCH v2 2/2] hw/smbios: Fix port connector option validation

[Ani Sinha]

> On 29-Jan-2024, at 13:33, Akihiko Odaki  wrote:
> 
> qemu_smbios_type8_opts did not have the list terminator and that
> resulted in out-of-bound memory access. It also needs to have an element
> for the type option.
> 
> Cc: qemu-sta...@nongnu.org
> Fixes: fd8caa253c56 ("hw/smbios: support for type 8 (port connector)")
> Signed-off-by: Akihiko Odaki 
> Reviewed-by: Michael Tokarev 

Reviewed-by: Ani Sinha 

> ---
> hw/smbios/smbios.c | 6 ++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 522ed1ed9fe3..8a44d3f271de 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -346,6 +346,11 @@ static const QemuOptDesc qemu_smbios_type4_opts[] = {
> };
> 
> static const QemuOptDesc qemu_smbios_type8_opts[] = {
> +{
> +.name = "type",
> +.type = QEMU_OPT_NUMBER,
> +.help = "SMBIOS element type",
> +},
> {
> .name = "internal_reference",
> .type = QEMU_OPT_STRING,
> @@ -366,6 +371,7 @@ static const QemuOptDesc qemu_smbios_type8_opts[] = {
> .type = QEMU_OPT_NUMBER,
> .help = "port type",
> },
> +{ /* end of list */ }
> };
> 
> static const QemuOptDesc qemu_smbios_type11_opts[] = {
> 
> -- 
> 2.43.0
> 

Re: [PULL 03/15] tests/acpi/bios-tables-test: do not write new blobs unless there are changes

[Ani Sinha]

> On 24-Jan-2024, at 14:28, Igor Mammedov  wrote:
> 
> On Fri, 1 Dec 2023 12:15:16 -0500
> "Michael S. Tsirkin"  wrote:
> 
>> From: Ani Sinha 
>> 
>> When dumping table blobs using rebuild-expected-aml.sh, table blobs from all
>> test variants are dumped regardless of whether there are any actual changes 
>> to
>> the tables or not. This creates lot of new files for various test variants 
>> that
>> are not part of the git repository. This is because we do not check in all 
>> table
>> blobs for all test variants into the repository. Only those blobs for those
>> variants that are different from the generic test-variant agnostic blob are
>> checked in.
>> 
>> This change makes the test smarter by checking if at all there are any 
>> changes
>> in the tables from the checked-in gold master blobs and take actions
>> accordingly.
>> 
>> When there are no changes:
>> - No new table blobs would be written.
>> - Existing table blobs will be refreshed (git diff will show no changes).
>> When there are changes:
>> - New table blob files will be dumped.
>> - Existing table blobs will be refreshed (git diff will show that the files
>>   changed, asl diff will show the actual changes).
> 
>> When new tables are introduced:
>> - Zero byte empty file blobs for new tables as instructed in the header of
>>   bios-tables-test.c will be regenerated to actual table blobs.
> 
> Ani,
> 
> what previously worked is the is there weren't _any_ expected blobs
> (exact match/fallback) found a new table would be dumped.
> So then later 'git status' would show a list of new files.

Yes this was the original complaint from Peter. Lots of new files were 
generated when basically they were identical but differed in naming.

> With this commit it's however not dumping new files files,
> and explodes at
> #5  0x5556808e in load_expected_aml (data=0x7fffd7b0) at 
> tests/qtest/bios-tables-test.c:414
> #6  0x555676b0 in dump_aml_files (data=0x7fffd7b0, rebuild=true) 
> at tests/qtest/bios-tables-test.c:256
> 
> sure it can be worked around by manually creating empty files
> for expected files

Yes this has already been documented in the commit log.

> but if it's a new machine type, one has to create
> a bunch of them basically running multiple iterations of rebuild in V=2
> mode to see what's missing.
> (IMHO cure turned out to be worse than illness)

I don’t know how common it is to create new machines. 

> 
> for reproducing create a test for other than default machine type, ex:
> 
>test_data data = { 
>   
>.machine = "pc-i440fx-2.0",
>   
>.variant = ".pc_legacy",   
>
>}; 
> 
> 
> is it possible to fix it so that one doesn't have to create empty files 
> manually?
> 
>> 
>> This would make analyzing changes to tables less confusing and there would
>> be no need to clean useless untracked files when there are no table changes.
>> 
>> CC: peter.mayd...@linaro.org
>> Signed-off-by: Ani Sinha 
>> Message-Id: <20231107044952.5461-1-anisi...@redhat.com>
>> Reviewed-by: Michael S. Tsirkin 
>> Signed-off-by: Michael S. Tsirkin 
>> ---
>> tests/qtest/bios-tables-test.c | 14 +-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>> 
>> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
>> index 71af5cf69f..fe6a9a8563 100644
>> --- a/tests/qtest/bios-tables-test.c
>> +++ b/tests/qtest/bios-tables-test.c
>> @@ -112,6 +112,7 @@ static const char *iasl;
>> #endif
>> 
>> static int verbosity_level;
>> +static GArray *load_expected_aml(test_data *data);
>> 
>> static bool compare_signature(const AcpiSdtTable *sdt, const char *signature)
>> {
>> @@ -244,21 +245,32 @@ static void test_acpi_fadt_table(test_data *data)
>> 
>> static void dump_aml_files(test_data *data, bool rebuild)
>> {
>> -AcpiSdtTable *sdt;
>> +AcpiSdtTable *sdt, *exp_sdt;
>> GError *error = NULL;
>> gchar *aml_file = NULL;
>> +test_data exp_data = {};
>> gint fd;
>> ssize_t ret;
>> int i;
>> 
>> +exp_data.tables = load_expected_aml(data);
>> for (i = 0; i < data->tables->len; ++i) {
>> const char *ext = data->variant ? data->variant : "";
>> sdt = _array_index(data->tables, AcpiSdtTable, 

[PATCH v2] acpi/tests/avocado/bits: wait for 200 seconds for SHUTDOWN event from bits VM

[Ani Sinha]

By default, the timeout to receive any specified event from the QEMU VM is 60
seconds set by the python avocado test framework. Please see event_wait() and
events_wait() in python/qemu/machine/machine.py. If the matching event is not
triggered within that interval, an asyncio.TimeoutError is generated. Since the
timeout for the bits avocado test is 200 secs, we need to make event_wait()
timeout of the same value as well so that an early timeout is not triggered by
the avocado framework.

CC: peter.mayd...@linaro.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2077
Signed-off-by: Ani Sinha 
---
 tests/avocado/acpi-bits.py | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

changelog:
v2: cosmetic comment updates in code and patch description.

diff --git a/tests/avocado/acpi-bits.py b/tests/avocado/acpi-bits.py
index 68b9e98d4e..efe4f52ee0 100644
--- a/tests/avocado/acpi-bits.py
+++ b/tests/avocado/acpi-bits.py
@@ -54,6 +54,8 @@
 deps = ["xorriso", "mformat"] # dependent tools needed in the test setup/box.
 supported_platforms = ['x86_64'] # supported test platforms.
 
+# default timeout of 120 secs is sometimes not enough for bits test.
+BITS_TIMEOUT = 200
 
 def which(tool):
 """ looks up the full path for @tool, returns None if not found
@@ -133,7 +135,7 @@ class AcpiBitsTest(QemuBaseTest): #pylint: 
disable=too-many-instance-attributes
 
 """
 # in slower systems the test can take as long as 3 minutes to complete.
-timeout = 200
+timeout = BITS_TIMEOUT
 
 def __init__(self, *args, **kwargs):
 super().__init__(*args, **kwargs)
@@ -400,7 +402,8 @@ def test_acpi_smbios_bits(self):
 
 # biosbits has been configured to run all the specified test suites
 # in batch mode and then automatically initiate a vm shutdown.
-# Rely on avocado's unit test timeout.
-self._vm.event_wait('SHUTDOWN')
+# Set timeout to BITS_TIMEOUT for SHUTDOWN event from bits VM at par
+# with the avocado test timeout.
+self._vm.event_wait('SHUTDOWN', timeout=BITS_TIMEOUT)
 self._vm.wait(timeout=None)
 self.parse_log()
-- 
2.39.2

[PATCH] acpi/tests/avocado/bits: wait for 200 seconds for SHUTDOWN event from bits VM

[Ani Sinha]

By default, the timeout to receive any specified event from the QEMU VM is 60
seconds set by the python avocado test framework. Please see event_wait() and
events_wait() in python/qemu/machine/machine.py. If the matching event is not
triggered within that interval, an asyncio.TimeoutError is generated. Since the
default timeout for the bits avocado test is 200 secs, we need to make
event_wait() timeout the same value as well so that an early timeout is not
triggered by the avocado framework.

CC: peter.mayd...@linaro.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2077
Signed-off-by: Ani Sinha 
---
 tests/avocado/acpi-bits.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/avocado/acpi-bits.py b/tests/avocado/acpi-bits.py
index 68b9e98d4e..870cd2e36c 100644
--- a/tests/avocado/acpi-bits.py
+++ b/tests/avocado/acpi-bits.py
@@ -53,7 +53,7 @@
 
 deps = ["xorriso", "mformat"] # dependent tools needed in the test setup/box.
 supported_platforms = ['x86_64'] # supported test platforms.
-
+BITS_TIMEOUT = 200
 
 def which(tool):
 """ looks up the full path for @tool, returns None if not found
@@ -133,7 +133,7 @@ class AcpiBitsTest(QemuBaseTest): #pylint: 
disable=too-many-instance-attributes
 
 """
 # in slower systems the test can take as long as 3 minutes to complete.
-timeout = 200
+timeout = BITS_TIMEOUT
 
 def __init__(self, *args, **kwargs):
 super().__init__(*args, **kwargs)
@@ -401,6 +401,6 @@ def test_acpi_smbios_bits(self):
 # biosbits has been configured to run all the specified test suites
 # in batch mode and then automatically initiate a vm shutdown.
 # Rely on avocado's unit test timeout.
-self._vm.event_wait('SHUTDOWN')
+self._vm.event_wait('SHUTDOWN', timeout=BITS_TIMEOUT)
 self._vm.wait(timeout=None)
 self.parse_log()
-- 
2.39.2

Re: [PATCH 1/2] acpi/tests/avocado/bits: import smilatency test from bits in order to disable it

[Ani Sinha]

> On 08-Jan-2024, at 4:28 PM, Peter Maydell  wrote:
> 
> On Mon, 8 Jan 2024 at 10:35, Ani Sinha  wrote:
>> 
>> Add smilatency test script in the bits avocado tests from bios-bits. No 
>> changes
>> have been made to the original test script. The test will be disabled in the
>> subsequent patch.
>> 
>> CC: peter.mayd...@linaro.org
>> CC: cr...@redhat.com
>> CC: phi...@linaro.org
>> CC: bl...@redhat.com
>> CC: m...@redhat.com
>> CC: waine...@redhat.com
>> Signed-off-by: Ani Sinha 
>> ---
>> .../acpi-bits/bits-tests/smilatency.py2   | 106 ++
>> 1 file changed, 106 insertions(+)
>> create mode 100644 tests/avocado/acpi-bits/bits-tests/smilatency.py2
> 
> I'm confused -- why do we need to *add* the test? This
> test already exists somewhere,

That “somewhere" is within the bios-bits image. See
https://www.qemu.org/docs/master/devel/acpi-bits.html
See "tests/avocado/acpi-bits/bits-tests” section.

> because we're running it.
> So why isn't the patch "disable that existing test"?
> 
> thanks
> -- PMM

Re: acpiBitsTest.test_acpi_smbios_bits test intermittently times out

[Ani Sinha]

> On 07-Jan-2024, at 9:56 PM, Ani Sinha  wrote:
> 
> On Sat, Jan 6, 2024 at 5:39 PM Peter Maydell  wrote:
>> 
>> On Sat, 6 Jan 2024 at 05:41, Ani Sinha  wrote:
>>> 
>>> On Sat, Jan 6, 2024 at 10:05 AM Ani Sinha  wrote:
>>>> 
>>>> On Sat, Jan 6, 2024 at 12:11 AM Peter Maydell  
>>>> wrote:
>>>>> 
>>>>> The avocado test acpiBitsTest.test_acpi_smbios_bits seems to be
>>>>> flaky in CI -- sometimes it appears to time out.
>>>>> 
>>>>> https://gitlab.com/qemu-project/qemu/-/issues/2077
>>>>> has the details (including links to jobs etc).
>>>> 
>>>> Do you have more data points in terms of the jobs that failed?
>>> 
>>> I just noticed that you attached three examples of failed tests. In
>>> all of them the test seems to be stuck at the ami latency test.
>> 
>> OK, if you think that subtest is suspicious, could you send a
>> patch that disables just that subpart, and we'll see if it helps?
> 
> I pushed the patches here:
> https://gitlab.com/anisinha/qemu/-/commits/disable-smilatency
> and ran the pipeline. It passed
> https://gitlab.com/anisinha/qemu/-/jobs/5878585312
> 
> and the smilatency test was not run:
> https://anisinha.gitlab.io/-/qemu/-/jobs/5878585312/artifacts/build/tests/results/latest/test-results/01-tests_avocado_acpi-bits.py_AcpiBitsTest.test_acpi_smbios_bits/debug.log
> 
> Not sure what we can do to have some confidence that disabling the
> test got rid of the flakiness.

I ran the avocado jobs avocado-system-centos and avocado-system-opensuse a few 
times and all times they passed. So I sent out the patches. Hope this settles 
it.


> I can send out those two patches in the
> list.

[PATCH 0/2] acpi/tests/avocado/bits: disable smilatency tests

[Ani Sinha]

Import smilatency test from bios-bits and disable it. It is causing some
flakyness and occassional failures in bios-bits avocado tests.
Please see ticket https://gitlab.com/qemu-project/qemu/-/issues/2077

CC: peter.mayd...@linaro.org
CC: cr...@redhat.com
CC: phi...@linaro.org
CC: bl...@redhat.com
CC: m...@redhat.com
CC: waine...@redhat.com
CC: qemu-devel@nongnu.org

Ani Sinha (2):
  acpi/tests/avocado/bits: import smilatency test from bits in order to
disable it
  acpi/tests/avocado/bits: disable smilatency tests

 .../acpi-bits/bits-tests/smilatency.py2   | 107 ++
 1 file changed, 107 insertions(+)
 create mode 100644 tests/avocado/acpi-bits/bits-tests/smilatency.py2

-- 
2.42.0

[PATCH 1/2] acpi/tests/avocado/bits: import smilatency test from bits in order to disable it

[Ani Sinha]

Add smilatency test script in the bits avocado tests from bios-bits. No changes
have been made to the original test script. The test will be disabled in the
subsequent patch.

CC: peter.mayd...@linaro.org
CC: cr...@redhat.com
CC: phi...@linaro.org
CC: bl...@redhat.com
CC: m...@redhat.com
CC: waine...@redhat.com
Signed-off-by: Ani Sinha 
---
 .../acpi-bits/bits-tests/smilatency.py2   | 106 ++
 1 file changed, 106 insertions(+)
 create mode 100644 tests/avocado/acpi-bits/bits-tests/smilatency.py2

diff --git a/tests/avocado/acpi-bits/bits-tests/smilatency.py2 
b/tests/avocado/acpi-bits/bits-tests/smilatency.py2
new file mode 100644
index 00..48083bfb0d
--- /dev/null
+++ b/tests/avocado/acpi-bits/bits-tests/smilatency.py2
@@ -0,0 +1,106 @@
+# Copyright (c) 2015, Intel Corporation
+# All rights reserved.
+#
+# SPDX-License-Identifier: BSD-3-Clause
+
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# * Redistributions of source code must retain the above copyright notice,
+#   this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright 
notice,
+#   this list of conditions and the following disclaimer in the 
documentation
+#   and/or other materials provided with the distribution.
+# * Neither the name of Intel Corporation nor the names of its contributors
+#   may be used to endorse or promote products derived from this software
+#   without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE 
FOR
+# ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
DAMAGES
+# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND 
ON
+# ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+# This script runs only from the biosbits VM.
+
+"""SMI latency test."""
+
+import bits
+from collections import namedtuple
+import testsuite
+import time
+import usb
+
+def register_tests():
+testsuite.add_test("SMI latency test", smi_latency);
+testsuite.add_test("SMI latency test with USB disabled via BIOS handoff", 
test_with_usb_disabled, runall=False);
+
+def smi_latency():
+MSR_SMI_COUNT = 0x34
+
+print "Warning: touching the keyboard can affect the results of this test."
+
+tsc_per_sec = bits.tsc_per_sec()
+tsc_per_usec = tsc_per_sec / (1000 * 1000)
+bins = [long(tsc_per_usec * 10**i) for i in range(9)]
+bin_descs = [
+"0 < t <=   1us",
+"1us   < t <=  10us",
+"10us  < t <= 100us",
+"100us < t <=   1ms",
+"1ms   < t <=  10ms",
+"10ms  < t <= 100ms",
+"100ms < t <=   1s ",
+"1s< t <=  10s ",
+"10s   < t <= 100s ",
+"100s  < t ",
+]
+
+print "Starting test. Wait here, I will be back in 15 seconds."
+(max_latency, smi_count_delta, bins) = bits.smi_latency(long(15 * 
tsc_per_sec), bins)
+BinType = namedtuple('BinType', ("max", "total", "count", "times"))
+bins = [BinType(*b) for b in bins]
+
+testsuite.test("SMI latency < 150us to minimize risk of OS timeouts", 
max_latency / tsc_per_usec <= 150)
+if not testsuite.show_detail():
+return
+
+for bin, desc in zip(bins, bin_descs):
+if bin.count == 0:
+continue
+testsuite.print_detail("{}; average = {}; count = {}".format(desc, 
bits.format_tsc(bin.total/bin.count), bin.count))
+deltas = (bits.format_tsc(t2 - t1) for t1,t2 in zip(bin.times, 
bin.times[1:]))
+testsuite.print_detail(" Times between first few observations: 
{}".format(" ".join("{:>6}".format(delta) for delta in deltas)))
+
+if smi_count_delta is not None:
+testsuite.print_detail("{} SMI detected using MSR_SMI_COUNT (MSR 
{:#x})".format(smi_count_delta, MSR_SMI_COUNT))
+
+testsuite.print_detail("Summary of impact: observed maximum latency = 
{}".format(bits.format_tsc(max_latency)))
+
+def test_with_usb_disabled():
+if usb.handoff_to_os():

[PATCH 2/2] acpi/tests/avocado/bits: disable smilatency tests

[Ani Sinha]

smilatncy tests in bios bits seems to generate some flakyness in running the
bits avocado tests. Disable them for now.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2077

CC: peter.mayd...@linaro.org
CC: cr...@redhat.com
CC: phi...@linaro.org
CC: bl...@redhat.com
CC: m...@redhat.com
CC: waine...@redhat.com
Signed-off-by: Ani Sinha 
---
 tests/avocado/acpi-bits/bits-tests/smilatency.py2 | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/avocado/acpi-bits/bits-tests/smilatency.py2 
b/tests/avocado/acpi-bits/bits-tests/smilatency.py2
index 48083bfb0d..405af67e19 100644
--- a/tests/avocado/acpi-bits/bits-tests/smilatency.py2
+++ b/tests/avocado/acpi-bits/bits-tests/smilatency.py2
@@ -37,8 +37,9 @@ import time
 import usb
 
 def register_tests():
-testsuite.add_test("SMI latency test", smi_latency);
-testsuite.add_test("SMI latency test with USB disabled via BIOS handoff", 
test_with_usb_disabled, runall=False);
+ pass
+#testsuite.add_test("SMI latency test", smi_latency);
+#testsuite.add_test("SMI latency test with USB disabled via BIOS handoff", 
test_with_usb_disabled, runall=False);
 
 def smi_latency():
 MSR_SMI_COUNT = 0x34
-- 
2.42.0

[PATCH 1/2] acpi/tests/avocado/bits: import smilatency test from bits in order to disable it

[Ani Sinha]

Add smilatency test script in the bits avocado tests from bios-bits. No changes
have been made to the original test script. The test will be disabled in the
subsequent patch.

CC: peter.mayd...@linaro.org
CC: cr...@redhat.com
CC: phi...@linaro.org
CC: bl...@redhat.com
CC: m...@redhat.com
CC: waine...@redhat.com
Signed-off-by: Ani Sinha 
---
 .../acpi-bits/bits-tests/smilatency.py2   | 106 ++
 1 file changed, 106 insertions(+)
 create mode 100644 tests/avocado/acpi-bits/bits-tests/smilatency.py2

diff --git a/tests/avocado/acpi-bits/bits-tests/smilatency.py2 
b/tests/avocado/acpi-bits/bits-tests/smilatency.py2
new file mode 100644
index 00..48083bfb0d
--- /dev/null
+++ b/tests/avocado/acpi-bits/bits-tests/smilatency.py2
@@ -0,0 +1,106 @@
+# Copyright (c) 2015, Intel Corporation
+# All rights reserved.
+#
+# SPDX-License-Identifier: BSD-3-Clause
+
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# * Redistributions of source code must retain the above copyright notice,
+#   this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright 
notice,
+#   this list of conditions and the following disclaimer in the 
documentation
+#   and/or other materials provided with the distribution.
+# * Neither the name of Intel Corporation nor the names of its contributors
+#   may be used to endorse or promote products derived from this software
+#   without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE 
FOR
+# ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
DAMAGES
+# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND 
ON
+# ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+# This script runs only from the biosbits VM.
+
+"""SMI latency test."""
+
+import bits
+from collections import namedtuple
+import testsuite
+import time
+import usb
+
+def register_tests():
+testsuite.add_test("SMI latency test", smi_latency);
+testsuite.add_test("SMI latency test with USB disabled via BIOS handoff", 
test_with_usb_disabled, runall=False);
+
+def smi_latency():
+MSR_SMI_COUNT = 0x34
+
+print "Warning: touching the keyboard can affect the results of this test."
+
+tsc_per_sec = bits.tsc_per_sec()
+tsc_per_usec = tsc_per_sec / (1000 * 1000)
+bins = [long(tsc_per_usec * 10**i) for i in range(9)]
+bin_descs = [
+"0 < t <=   1us",
+"1us   < t <=  10us",
+"10us  < t <= 100us",
+"100us < t <=   1ms",
+"1ms   < t <=  10ms",
+"10ms  < t <= 100ms",
+"100ms < t <=   1s ",
+"1s< t <=  10s ",
+"10s   < t <= 100s ",
+"100s  < t ",
+]
+
+print "Starting test. Wait here, I will be back in 15 seconds."
+(max_latency, smi_count_delta, bins) = bits.smi_latency(long(15 * 
tsc_per_sec), bins)
+BinType = namedtuple('BinType', ("max", "total", "count", "times"))
+bins = [BinType(*b) for b in bins]
+
+testsuite.test("SMI latency < 150us to minimize risk of OS timeouts", 
max_latency / tsc_per_usec <= 150)
+if not testsuite.show_detail():
+return
+
+for bin, desc in zip(bins, bin_descs):
+if bin.count == 0:
+continue
+testsuite.print_detail("{}; average = {}; count = {}".format(desc, 
bits.format_tsc(bin.total/bin.count), bin.count))
+deltas = (bits.format_tsc(t2 - t1) for t1,t2 in zip(bin.times, 
bin.times[1:]))
+testsuite.print_detail(" Times between first few observations: 
{}".format(" ".join("{:>6}".format(delta) for delta in deltas)))
+
+if smi_count_delta is not None:
+testsuite.print_detail("{} SMI detected using MSR_SMI_COUNT (MSR 
{:#x})".format(smi_count_delta, MSR_SMI_COUNT))
+
+testsuite.print_detail("Summary of impact: observed maximum latency = 
{}".format(bits.format_tsc(max_latency)))
+
+def test_with_usb_disabled():
+if usb.handoff_to_os():

[PATCH 2/2] acpi/tests/avocado/bits: disable smilatency tests

[Ani Sinha]

smilatncy tests in bios bits seems to generate some flakyness in running the
bits avocado tests. Disable them for now.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2077

CC: peter.mayd...@linaro.org
CC: cr...@redhat.com
CC: phi...@linaro.org
CC: bl...@redhat.com
CC: m...@redhat.com
CC: waine...@redhat.com
Signed-off-by: Ani Sinha 
---
 tests/avocado/acpi-bits/bits-tests/smilatency.py2 | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/avocado/acpi-bits/bits-tests/smilatency.py2 
b/tests/avocado/acpi-bits/bits-tests/smilatency.py2
index 48083bfb0d..405af67e19 100644
--- a/tests/avocado/acpi-bits/bits-tests/smilatency.py2
+++ b/tests/avocado/acpi-bits/bits-tests/smilatency.py2
@@ -37,8 +37,9 @@ import time
 import usb
 
 def register_tests():
-testsuite.add_test("SMI latency test", smi_latency);
-testsuite.add_test("SMI latency test with USB disabled via BIOS handoff", 
test_with_usb_disabled, runall=False);
+ pass
+#testsuite.add_test("SMI latency test", smi_latency);
+#testsuite.add_test("SMI latency test with USB disabled via BIOS handoff", 
test_with_usb_disabled, runall=False);
 
 def smi_latency():
 MSR_SMI_COUNT = 0x34
-- 
2.42.0

Re: acpiBitsTest.test_acpi_smbios_bits test intermittently times out

[Ani Sinha]

On Sat, Jan 6, 2024 at 5:39 PM Peter Maydell  wrote:
>
> On Sat, 6 Jan 2024 at 05:41, Ani Sinha  wrote:
> >
> > On Sat, Jan 6, 2024 at 10:05 AM Ani Sinha  wrote:
> > >
> > > On Sat, Jan 6, 2024 at 12:11 AM Peter Maydell  
> > > wrote:
> > > >
> > > > The avocado test acpiBitsTest.test_acpi_smbios_bits seems to be
> > > > flaky in CI -- sometimes it appears to time out.
> > > >
> > > > https://gitlab.com/qemu-project/qemu/-/issues/2077
> > > > has the details (including links to jobs etc).
> > >
> > > Do you have more data points in terms of the jobs that failed?
> >
> > I just noticed that you attached three examples of failed tests. In
> > all of them the test seems to be stuck at the ami latency test.
>
> OK, if you think that subtest is suspicious, could you send a
> patch that disables just that subpart, and we'll see if it helps?

I pushed the patches here:
https://gitlab.com/anisinha/qemu/-/commits/disable-smilatency
and ran the pipeline. It passed
https://gitlab.com/anisinha/qemu/-/jobs/5878585312

and the smilatency test was not run:
https://anisinha.gitlab.io/-/qemu/-/jobs/5878585312/artifacts/build/tests/results/latest/test-results/01-tests_avocado_acpi-bits.py_AcpiBitsTest.test_acpi_smbios_bits/debug.log

Not sure what we can do to have some confidence that disabling the
test got rid of the flakiness. I can send out those two patches in the
list.

Re: acpiBitsTest.test_acpi_smbios_bits test intermittently times out

[Ani Sinha]

On Sat, Jan 6, 2024 at 10:05 AM Ani Sinha  wrote:
>
> On Sat, Jan 6, 2024 at 12:11 AM Peter Maydell  
> wrote:
> >
> > The avocado test acpiBitsTest.test_acpi_smbios_bits seems to be
> > flaky in CI -- sometimes it appears to time out.
> >
> > https://gitlab.com/qemu-project/qemu/-/issues/2077
> > has the details (including links to jobs etc).
>
> Do you have more data points in terms of the jobs that failed?

I just noticed that you attached three examples of failed tests. In
all of them the test seems to be stuck at the ami latency test.

The one
> you point to seems to be stuck in SMI latency tests:
>
>  SMI latency test 
> 16:45:49 DEBUG|
> Warning: touching the keyboard can affect the results of this test.
> 16:45:50 DEBUG|
> Starting test. Wait here, I will be back in 15 seconds.
>
> If this is consistently timing out here, we can disable the smi
> latency test. This test was a little problematic from the get go.
>
> Meanwhile I have assigned
> https://gitlab.com/qemu-project/qemu/-/issues/2077 to myself and will
> take a look.
>
> > As far as I can
> > see, the test is still running when after about a minute it
> > gets timed out. (Though the python tracebacks in the logs are
> > not easy for me to interpret, so I might be wrong). This I find
> > a bit confusing, because tests/avocado/acpi-bits.py sets
> > "timeout = 200". So maybe that isn't taking effect properly?
> >
> > Does anybody have time to investigate this? If not, we can disable
> > the test as flaky until somebody does have the time.
> >
> > thanks
> > -- PMM
> >

Re: acpiBitsTest.test_acpi_smbios_bits test intermittently times out

[Ani Sinha]

On Sat, Jan 6, 2024 at 12:11 AM Peter Maydell  wrote:
>
> The avocado test acpiBitsTest.test_acpi_smbios_bits seems to be
> flaky in CI -- sometimes it appears to time out.
>
> https://gitlab.com/qemu-project/qemu/-/issues/2077
> has the details (including links to jobs etc).

Do you have more data points in terms of the jobs that failed? The one
you point to seems to be stuck in SMI latency tests:

 SMI latency test 
16:45:49 DEBUG|
Warning: touching the keyboard can affect the results of this test.
16:45:50 DEBUG|
Starting test. Wait here, I will be back in 15 seconds.

If this is consistently timing out here, we can disable the smi
latency test. This test was a little problematic from the get go.

Meanwhile I have assigned
https://gitlab.com/qemu-project/qemu/-/issues/2077 to myself and will
take a look.

> As far as I can
> see, the test is still running when after about a minute it
> gets timed out. (Though the python tracebacks in the logs are
> not easy for me to interpret, so I might be wrong). This I find
> a bit confusing, because tests/avocado/acpi-bits.py sets
> "timeout = 200". So maybe that isn't taking effect properly?
>
> Does anybody have time to investigate this? If not, we can disable
> the test as flaky until somebody does have the time.
>
> thanks
> -- PMM
>

Re: [PATCH] pc: q35: Bump max_cpus to 4096

[Ani Sinha]

> On 11-Dec-2023, at 11:27 AM, Thomas Huth  wrote:
> 
> On 08/12/2023 13.26, Ani Sinha wrote:
>> Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow 
>> up to 4096 vCPUs")
>> Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
>> enabled in the kernel. So bump up the max_cpus value for q35 machines 
>> versions
>> 8.3 and newer to 4096. Older q35 machines versions 8.2 and older continue to
>> support 1024 maximum vcpus as before.
>> If KVM is not able to support the specified number of vcpus, QEMU would
>> return the following error messages:
>> $ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 4096
>> qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (4096) 
>> exceeds the recommended cpus supported by KVM (12)
>> Number of SMP cpus requested (4096) exceeds the maximum cpus supported by 
>> KVM (1024)
>> Cc: Daniel P. Berrangé 
>> Cc: Igor Mammedov 
>> Cc: Michael S. Tsirkin 
>> Cc: Julia Suvorova 
>> Signed-off-by: Ani Sinha 
>> ---
>>  hw/i386/pc_q35.c | 15 ---
>>  1 file changed, 12 insertions(+), 3 deletions(-)
>> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
>> index 4f3e5412f6..2ed57814e1 100644
>> --- a/hw/i386/pc_q35.c
>> +++ b/hw/i386/pc_q35.c
>> @@ -375,7 +375,7 @@ static void pc_q35_machine_options(MachineClass *m)
>>  m->default_nic = "e1000e";
>>  m->default_kernel_irqchip_split = false;
>>  m->no_floppy = 1;
>> -m->max_cpus = 1024;
>> +m->max_cpus = 4096;
>>  m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
>>  machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
>>  machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
>> @@ -383,12 +383,22 @@ static void pc_q35_machine_options(MachineClass *m)
>>  machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE);
>>  }
>>  -static void pc_q35_8_2_machine_options(MachineClass *m)
>> +static void pc_q35_8_3_machine_options(MachineClass *m)
> 
> Hi Ani!
> 
> The next QEMU version after 8.2 is 9.0.

Ah yes I completely forgot about our versioning scheme.


> Maybe best if you rebase your patch on top of:
> 
> https://lore.kernel.org/qemu-devel/20231120094259.1191804-1-coh...@redhat.com/

Will do. I am trying to get some data with testing on edk2. It seems on legacy 
bios, we have done some testing downstream with 4096 vcpus with qemu 
modifications and patched host kernel [1] and the linux guest boots fine. With 
edk2 it seems we have tested with 1880 vcpus and it works fine with the patched 
edk2 [2]. I am working downstream with HPE folks to get some testing done with 
4096 vcpus.

[1] patched with 
https://github.com/kvm-x86/linux/commit/f10a570b093e60c6bd3f210ae909f014f421352a
 .
[2] 
https://github.com/tianocore/edk2/pull/4181/commits/03ca8224f995eda75e2769ed9a2fc437e321db8e

Re: [PULL 6/6] tests/acpi: disallow tests/data/acpi/virt/SSDT.memhp changes

[Ani Sinha]

> On 13-Dec-2023, at 8:47 PM, Michael S. Tsirkin  wrote:
> 
> On Wed, Dec 13, 2023 at 04:14:00PM +0100, Gerd Hoffmann wrote:
>>  Hi,
>> 
>>> I agree, Gerd, going forward please include the diff of the
>>> disassemled AML.
>> 
>> That is in patch 5/6 which updates the test data.
>> 
>> take care,
>>  Gerd
> 
> Oh I double checked and you are right, I'm not sure where did I look that I 
> missed it.

Yes I was talking about patch 6 having an empty description.

Re: [PULL 6/6] tests/acpi: disallow tests/data/acpi/virt/SSDT.memhp changes

[Ani Sinha]

> On 13-Dec-2023, at 8:03 PM, Michael S. Tsirkin  wrote:
> 
> On Wed, Dec 13, 2023 at 04:24:24PM +0530, Ani Sinha wrote:
>> 
>> 
>>> On 13-Dec-2023, at 4:20 PM, Gerd Hoffmann  wrote:
>>> 
>>> Signed-off-by: Gerd Hoffmann 
>> 
>> Please combine this patch with patch 5. No need to do this separately.
> 
> 
> Yes but since it's done - it's fine either way I think. No?

Yes I did not realise it was a PR and not a review. I thought it was sent for 
review. If it’s done it’s ok.
That being said, I would have preferred that the commit had a description and 
not completely empty.

> 
>>> ---
>>> tests/qtest/bios-tables-test-allowed-diff.h | 1 -
>>> 1 file changed, 1 deletion(-)
>>> 
>>> diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
>>> b/tests/qtest/bios-tables-test-allowed-diff.h
>>> index e569098abddc..dfb8523c8bf4 100644
>>> --- a/tests/qtest/bios-tables-test-allowed-diff.h
>>> +++ b/tests/qtest/bios-tables-test-allowed-diff.h
>>> @@ -1,2 +1 @@
>>> /* List of comma-separated changed AML files to ignore */
>>> -"tests/data/acpi/virt/SSDT.memhp",
>>> -- 
>>> 2.43.0
>>> 
> 

Re: [PULL 6/6] tests/acpi: disallow tests/data/acpi/virt/SSDT.memhp changes

[Ani Sinha]

> On 13-Dec-2023, at 4:20 PM, Gerd Hoffmann  wrote:
> 
> Signed-off-by: Gerd Hoffmann 

Please combine this patch with patch 5. No need to do this separately.

> ---
> tests/qtest/bios-tables-test-allowed-diff.h | 1 -
> 1 file changed, 1 deletion(-)
> 
> diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
> b/tests/qtest/bios-tables-test-allowed-diff.h
> index e569098abddc..dfb8523c8bf4 100644
> --- a/tests/qtest/bios-tables-test-allowed-diff.h
> +++ b/tests/qtest/bios-tables-test-allowed-diff.h
> @@ -1,2 +1 @@
> /* List of comma-separated changed AML files to ignore */
> -"tests/data/acpi/virt/SSDT.memhp",
> -- 
> 2.43.0
> 

Re: [PATCH] pc: q35: Bump max_cpus to 4096

[Ani Sinha]

> On 08-Dec-2023, at 6:27 PM, Daniel P. Berrangé  wrote:
> 
> On Fri, Dec 08, 2023 at 05:56:11PM +0530, Ani Sinha wrote:
>> Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow 
>> up to 4096 vCPUs")
>> Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
>> enabled in the kernel. So bump up the max_cpus value for q35 machines 
>> versions
>> 8.3 and newer to 4096. Older q35 machines versions 8.2 and older continue to
>> support 1024 maximum vcpus as before.
>> 
>> If KVM is not able to support the specified number of vcpus, QEMU would
>> return the following error messages:
>> 
>> $ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 4096
>> qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (4096) 
>> exceeds the recommended cpus supported by KVM (12)
>> Number of SMP cpus requested (4096) exceeds the maximum cpus supported by 
>> KVM (1024)
>> 
>> Cc: Daniel P. Berrangé 
>> Cc: Igor Mammedov 
>> Cc: Michael S. Tsirkin 
>> Cc: Julia Suvorova 
>> Signed-off-by: Ani Sinha 
>> ---
>> hw/i386/pc_q35.c | 15 ---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
> 
> What testing has been done to confirm if QEMU is actually capable of
> booting a guest with this CPU count, either UEFI or SeaBIOS or both ?

I admit we did not test this with 4096 cpus.

It was tested downstream with edk2 with modified kernel and increased QEMU 
limit for 
https://bugzilla.redhat.com/show_bug.cgi?id=1983086

> We validated a ~48TB, 1728 cores, and 32 socket vm using legacy
> bios from smbios 3.0, the latest qemu modified with higher vcpu limits, a=
nd
> modified kernel limits.

I am trying to get some more clarity on the testing front and checking what max 
values for max_cpu we can test with.

> 
> Historically every time we wanted to raise max cpus we've seen limits
> or scalability problems that needed fixing first. The previous bump to
> 1024 had been implicitly proven via downstream testing we had done in
> RHEL, and had required the switch to SMBIOS v3 entrypoint.
> 
>> 
>> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
>> index 4f3e5412f6..2ed57814e1 100644
>> --- a/hw/i386/pc_q35.c
>> +++ b/hw/i386/pc_q35.c
>> @@ -375,7 +375,7 @@ static void pc_q35_machine_options(MachineClass *m)
>> m->default_nic = "e1000e";
>> m->default_kernel_irqchip_split = false;
>> m->no_floppy = 1;
>> -m->max_cpus = 1024;
>> +m->max_cpus = 4096;
>> m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
>> machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
>> machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
>> @@ -383,12 +383,22 @@ static void pc_q35_machine_options(MachineClass *m)
>> machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE);
>> }
>> 
>> -static void pc_q35_8_2_machine_options(MachineClass *m)
>> +static void pc_q35_8_3_machine_options(MachineClass *m)
>> {
>> pc_q35_machine_options(m);
>> m->alias = "q35";
>> }
>> 
>> +DEFINE_Q35_MACHINE(v8_3, "pc-q35-8.3", NULL,
>> +   pc_q35_8_3_machine_options);
>> +
>> +static void pc_q35_8_2_machine_options(MachineClass *m)
>> +{
>> +pc_q35_8_3_machine_options(m);
>> +m->alias = NULL;
>> +m->max_cpus = 1024;
>> +}
>> +
>> DEFINE_Q35_MACHINE(v8_2, "pc-q35-8.2", NULL,
>>pc_q35_8_2_machine_options);
>> 
>> @@ -396,7 +406,6 @@ static void pc_q35_8_1_machine_options(MachineClass *m)
>> {
>> PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
>> pc_q35_8_2_machine_options(m);
>> -m->alias = NULL;
>> pcmc->broken_32bit_mem_addr_check = true;
>> compat_props_add(m->compat_props, hw_compat_8_1, hw_compat_8_1_len);
>> compat_props_add(m->compat_props, pc_compat_8_1, pc_compat_8_1_len);
>> -- 
>> 2.42.0
>> 
> 
> With regards,
> Daniel
> -- 
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

[PATCH] pc: q35: Bump max_cpus to 4096

[Ani Sinha]

Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow up 
to 4096 vCPUs")
Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
enabled in the kernel. So bump up the max_cpus value for q35 machines versions
8.3 and newer to 4096. Older q35 machines versions 8.2 and older continue to
support 1024 maximum vcpus as before.

If KVM is not able to support the specified number of vcpus, QEMU would
return the following error messages:

$ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 4096
qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (4096) 
exceeds the recommended cpus supported by KVM (12)
Number of SMP cpus requested (4096) exceeds the maximum cpus supported by KVM 
(1024)

Cc: Daniel P. Berrangé 
Cc: Igor Mammedov 
Cc: Michael S. Tsirkin 
Cc: Julia Suvorova 
Signed-off-by: Ani Sinha 
---
 hw/i386/pc_q35.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 4f3e5412f6..2ed57814e1 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -375,7 +375,7 @@ static void pc_q35_machine_options(MachineClass *m)
 m->default_nic = "e1000e";
 m->default_kernel_irqchip_split = false;
 m->no_floppy = 1;
-m->max_cpus = 1024;
+m->max_cpus = 4096;
 m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
@@ -383,12 +383,22 @@ static void pc_q35_machine_options(MachineClass *m)
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE);
 }
 
-static void pc_q35_8_2_machine_options(MachineClass *m)
+static void pc_q35_8_3_machine_options(MachineClass *m)
 {
 pc_q35_machine_options(m);
 m->alias = "q35";
 }
 
+DEFINE_Q35_MACHINE(v8_3, "pc-q35-8.3", NULL,
+   pc_q35_8_3_machine_options);
+
+static void pc_q35_8_2_machine_options(MachineClass *m)
+{
+pc_q35_8_3_machine_options(m);
+m->alias = NULL;
+m->max_cpus = 1024;
+}
+
 DEFINE_Q35_MACHINE(v8_2, "pc-q35-8.2", NULL,
pc_q35_8_2_machine_options);
 
@@ -396,7 +406,6 @@ static void pc_q35_8_1_machine_options(MachineClass *m)
 {
 PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 pc_q35_8_2_machine_options(m);
-m->alias = NULL;
 pcmc->broken_32bit_mem_addr_check = true;
 compat_props_add(m->compat_props, hw_compat_8_1, hw_compat_8_1_len);
 compat_props_add(m->compat_props, pc_compat_8_1, pc_compat_8_1_len);
-- 
2.42.0

Re: [PULL 03/15] tests/acpi/bios-tables-test: do not write new blobs unless there are changes

[Ani Sinha]

> On 01-Dec-2023, at 10:45 PM, Michael S. Tsirkin  wrote:
> 
> From: Ani Sinha 
> 
> When dumping table blobs using rebuild-expected-aml.sh, table blobs from all
> test variants are dumped regardless of whether there are any actual changes to
> the tables or not. This creates lot of new files for various test variants 
> that
> are not part of the git repository. This is because we do not check in all 
> table
> blobs for all test variants into the repository. Only those blobs for those
> variants that are different from the generic test-variant agnostic blob are
> checked in.
> 
> This change makes the test smarter by checking if at all there are any changes
> in the tables from the checked-in gold master blobs and take actions
> accordingly.
> 
> When there are no changes:
> - No new table blobs would be written.
> - Existing table blobs will be refreshed (git diff will show no changes).
> When there are changes:
> - New table blob files will be dumped.
> - Existing table blobs will be refreshed (git diff will show that the files
>   changed, asl diff will show the actual changes).
> When new tables are introduced:
> - Zero byte empty file blobs for new tables as instructed in the header of
>   bios-tables-test.c will be regenerated to actual table blobs.
> 
> This would make analyzing changes to tables less confusing and there would
> be no need to clean useless untracked files when there are no table changes.
> 
> CC: peter.mayd...@linaro.org
> Signed-off-by: Ani Sinha 
> Message-Id: <20231107044952.5461-1-anisi...@redhat.com>
> Reviewed-by: Michael S. Tsirkin 
> Signed-off-by: Michael S. Tsirkin 

You missed DanPB and Igor’s tags :(

> ---
> tests/qtest/bios-tables-test.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
> index 71af5cf69f..fe6a9a8563 100644
> --- a/tests/qtest/bios-tables-test.c
> +++ b/tests/qtest/bios-tables-test.c
> @@ -112,6 +112,7 @@ static const char *iasl;
> #endif
> 
> static int verbosity_level;
> +static GArray *load_expected_aml(test_data *data);
> 
> static bool compare_signature(const AcpiSdtTable *sdt, const char *signature)
> {
> @@ -244,21 +245,32 @@ static void test_acpi_fadt_table(test_data *data)
> 
> static void dump_aml_files(test_data *data, bool rebuild)
> {
> -AcpiSdtTable *sdt;
> +AcpiSdtTable *sdt, *exp_sdt;
> GError *error = NULL;
> gchar *aml_file = NULL;
> +test_data exp_data = {};
> gint fd;
> ssize_t ret;
> int i;
> 
> +exp_data.tables = load_expected_aml(data);
> for (i = 0; i < data->tables->len; ++i) {
> const char *ext = data->variant ? data->variant : "";
> sdt = _array_index(data->tables, AcpiSdtTable, i);
> +exp_sdt = _array_index(exp_data.tables, AcpiSdtTable, i);
> g_assert(sdt->aml);
> +g_assert(exp_sdt->aml);
> 
> if (rebuild) {
> aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, 
> data->machine,
>sdt->aml, ext);
> +if (!g_file_test(aml_file, G_FILE_TEST_EXISTS) &&
> +sdt->aml_len == exp_sdt->aml_len &&
> +!memcmp(sdt->aml, exp_sdt->aml, sdt->aml_len)) {
> +/* identical tables, no need to write new files */
> +g_free(aml_file);
> +continue;
> +}
> fd = g_open(aml_file, O_WRONLY|O_TRUNC|O_CREAT,
> S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH);
> if (fd < 0) {
> -- 
> MST
> 

Re: [PATCH-for-9.0 v2 5/8] hw: Prefer qdev_prop_set_bit over object_property_set_bool for QDev

[Ani Sinha]

> On 23-Nov-2023, at 8:08 PM, Philippe Mathieu-Daudé  wrote:
> 
> The QOM API is lower level than the QDev one. When an instance is
> QDev and setting the property can not fail (using _abort),
> prefer qdev_prop_set_bit() over object_property_set_bool().
> 
> Mechanical transformation using the following coccinelle patch:
> 
>  @@
>  expression o, p, v;
>  @@
>  -object_property_set_bool(OBJECT(o), p, v, _abort)
>  +qdev_prop_set_bit(DEVICE(o), p, v)
>  
>  -object_property_set_bool(o, p, v, _abort)
>  +qdev_prop_set_bit(DEVICE(o), p, v)
> 
> manually adding the missing "hw/qdev-properties.h" header.
> 
> In hw/arm/armsse.c we use the available 'cpudev' instead of 'cpuobj'.
> 
> Suggested-by: Markus Armbruster 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> hw/acpi/cpu_hotplug.c   |  7 +++
> hw/acpi/ich9.c  |  4 ++--
> hw/acpi/piix4.c |  4 ++--

For the acpi bits,
Reviewed-by: Ani Sinha 

> hw/arm/armsse.c |  3 +--
> hw/arm/armv7m.c |  3 +--
> hw/arm/aspeed_ast2400.c |  3 +--
> hw/arm/aspeed_ast2600.c |  9 +++--
> hw/arm/bcm2835_peripherals.c|  3 +--
> hw/arm/bcm2836.c|  4 ++--
> hw/arm/boot.c   |  4 ++--
> hw/arm/fsl-imx25.c  |  3 +--
> hw/arm/fsl-imx31.c  |  3 +--
> hw/arm/fsl-imx6.c   | 12 
> hw/arm/fsl-imx6ul.c |  8 
> hw/arm/fsl-imx7.c   | 10 --
> hw/arm/npcm7xx.c|  9 +++--
> hw/arm/xlnx-versal.c|  9 +++--
> hw/arm/xlnx-zynqmp.c|  9 +++--
> hw/core/bus.c   |  2 +-
> hw/core/qdev.c  |  2 +-
> hw/i386/pc_piix.c   | 19 ++-
> hw/microblaze/petalogix_ml605_mmu.c |  5 ++---
> hw/microblaze/xlnx-zynqmp-pmu.c | 18 +++---
> hw/mips/cps.c   |  3 +--
> hw/ppc/e500.c   |  3 +--
> hw/ppc/spapr_pci.c  |  3 +--
> hw/rx/rx-gdbsim.c   |  4 ++--
> hw/sparc/sun4m.c|  3 +--
> 28 files changed, 64 insertions(+), 105 deletions(-)
> 
> diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
> index 634bbecb31..1338c037b5 100644
> --- a/hw/acpi/cpu_hotplug.c
> +++ b/hw/acpi/cpu_hotplug.c
> @@ -12,6 +12,7 @@
> #include "qemu/osdep.h"
> #include "hw/acpi/cpu_hotplug.h"
> #include "qapi/error.h"
> +#include "hw/qdev-properties.h"
> #include "hw/core/cpu.h"
> #include "hw/i386/pc.h"
> #include "hw/pci/pci.h"
> @@ -41,8 +42,7 @@ static void cpu_status_write(void *opaque, hwaddr addr, 
> uint64_t data,
>  */
> if (addr == 0 && data == 0) {
> AcpiCpuHotplug *cpus = opaque;
> -object_property_set_bool(cpus->device, "cpu-hotplug-legacy", false,
> - _abort);
> +qdev_prop_set_bit(DEVICE(cpus->device), "cpu-hotplug-legacy", false);
> }
> }
> 
> @@ -66,8 +66,7 @@ static void acpi_set_cpu_present_bit(AcpiCpuHotplug *g, 
> CPUState *cpu)
> 
> cpu_id = k->get_arch_id(cpu);
> if ((cpu_id / 8) >= ACPI_GPE_PROC_LEN) {
> -object_property_set_bool(g->device, "cpu-hotplug-legacy", false,
> - _abort);
> +qdev_prop_set_bit(DEVICE(g->device), "cpu-hotplug-legacy", false);
> return;
> }
> 
> diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
> index 25e2c7243e..64b00673fe 100644
> --- a/hw/acpi/ich9.c
> +++ b/hw/acpi/ich9.c
> @@ -30,6 +30,7 @@
> #include "hw/pci/pci.h"
> #include "migration/vmstate.h"
> #include "qemu/timer.h"
> +#include "hw/qdev-properties.h"
> #include "hw/core/cpu.h"
> #include "sysemu/reset.h"
> #include "sysemu/runstate.h"
> @@ -197,8 +198,7 @@ static bool vmstate_test_use_cpuhp(void *opaque)
> static int vmstate_cpuhp_pre_load(void *opaque)
> {
> ICH9LPCPMRegs *s = opaque;
> -Object *obj = OBJECT(s->gpe_cpu.device);
> -object_property_set_bool(obj, "cpu-hotplug-legacy", false, _abort);
> +qdev_prop_set_bit(DEVICE(s->gpe_cpu.device), "cpu-hotplug-legacy", 
> false);
> return 0;
> }
> 
> diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> index dd523d2e4c..215929ac6a 100644
> --- a/hw/acpi/piix4.c
> +++ b/hw/acpi/piix4

Re: [PATCH v2] tests/acpi/bios-tables-test: do not write new blobs unless there are changes

[Ani Sinha]

> On 21-Nov-2023, at 12:39 PM, Ani Sinha  wrote:
> 
> 
> 
>> On 16-Nov-2023, at 11:30 AM, Ani Sinha  wrote:
>> 
>> 
>> 
>>> On 07-Nov-2023, at 10:19 AM, Ani Sinha  wrote:
>>> 
>>> When dumping table blobs using rebuild-expected-aml.sh, table blobs from all
>>> test variants are dumped regardless of whether there are any actual changes 
>>> to
>>> the tables or not. This creates lot of new files for various test variants 
>>> that
>>> are not part of the git repository. This is because we do not check in all 
>>> table
>>> blobs for all test variants into the repository. Only those blobs for those
>>> variants that are different from the generic test-variant agnostic blob are
>>> checked in.
>>> 
>>> This change makes the test smarter by checking if at all there are any 
>>> changes
>>> in the tables from the checked-in gold master blobs and take actions
>>> accordingly.
>>> 
>>> When there are no changes:
>>> - No new table blobs would be written.
>>> - Existing table blobs will be refreshed (git diff will show no changes).
>>> When there are changes:
>>> - New table blob files will be dumped.
>>> - Existing table blobs will be refreshed (git diff will show that the files
>>> changed, asl diff will show the actual changes).
>>> When new tables are introduced:
>>> - Zero byte empty file blobs for new tables as instructed in the header of
>>> bios-tables-test.c will be regenerated to actual table blobs.
>>> 
>>> This would make analyzing changes to tables less confusing and there would
>>> be no need to clean useless untracked files when there are no table changes.
>>> 
>>> CC: peter.mayd...@linaro.org
>>> Signed-off-by: Ani Sinha 
>>> ---
>>> tests/qtest/bios-tables-test.c | 14 +-
>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>> 
>>> changelog:
>>> v2: commit description updated to make things a little clearer.
>>>  No actual changes.
>> 
>> Ping ...
> 
> Ping again ...

Ping …

> 
>> 
>>> 
>>> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
>>> index 9f4bc15aab..743b509e93 100644
>>> --- a/tests/qtest/bios-tables-test.c
>>> +++ b/tests/qtest/bios-tables-test.c
>>> @@ -109,6 +109,7 @@ static const char *iasl;
>>> #endif
>>> 
>>> static int verbosity_level;
>>> +static GArray *load_expected_aml(test_data *data);
>>> 
>>> static bool compare_signature(const AcpiSdtTable *sdt, const char 
>>> *signature)
>>> {
>>> @@ -241,21 +242,32 @@ static void test_acpi_fadt_table(test_data *data)
>>> 
>>> static void dump_aml_files(test_data *data, bool rebuild)
>>> {
>>> -AcpiSdtTable *sdt;
>>> +AcpiSdtTable *sdt, *exp_sdt;
>>>   GError *error = NULL;
>>>   gchar *aml_file = NULL;
>>> +test_data exp_data = {};
>>>   gint fd;
>>>   ssize_t ret;
>>>   int i;
>>> 
>>> +exp_data.tables = load_expected_aml(data);
>>>   for (i = 0; i < data->tables->len; ++i) {
>>>   const char *ext = data->variant ? data->variant : "";
>>>   sdt = _array_index(data->tables, AcpiSdtTable, i);
>>> +exp_sdt = _array_index(exp_data.tables, AcpiSdtTable, i);
>>>   g_assert(sdt->aml);
>>> +g_assert(exp_sdt->aml);
>>> 
>>>   if (rebuild) {
>>>   aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, 
>>> data->machine,
>>>  sdt->aml, ext);
>>> +if (!g_file_test(aml_file, G_FILE_TEST_EXISTS) &&
>>> +sdt->aml_len == exp_sdt->aml_len &&
>>> +!memcmp(sdt->aml, exp_sdt->aml, sdt->aml_len)) {
>>> +/* identical tables, no need to write new files */
>>> +g_free(aml_file);
>>> +continue;
>>> +}
>>>   fd = g_open(aml_file, O_WRONLY|O_TRUNC|O_CREAT,
>>>   S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH);
>>>   if (fd < 0) {
>>> -- 
>>> 2.42.0

Re: [PATCH v2] tests/acpi/bios-tables-test: do not write new blobs unless there are changes

[Ani Sinha]

> On 16-Nov-2023, at 11:30 AM, Ani Sinha  wrote:
> 
> 
> 
>> On 07-Nov-2023, at 10:19 AM, Ani Sinha  wrote:
>> 
>> When dumping table blobs using rebuild-expected-aml.sh, table blobs from all
>> test variants are dumped regardless of whether there are any actual changes 
>> to
>> the tables or not. This creates lot of new files for various test variants 
>> that
>> are not part of the git repository. This is because we do not check in all 
>> table
>> blobs for all test variants into the repository. Only those blobs for those
>> variants that are different from the generic test-variant agnostic blob are
>> checked in.
>> 
>> This change makes the test smarter by checking if at all there are any 
>> changes
>> in the tables from the checked-in gold master blobs and take actions
>> accordingly.
>> 
>> When there are no changes:
>> - No new table blobs would be written.
>> - Existing table blobs will be refreshed (git diff will show no changes).
>> When there are changes:
>> - New table blob files will be dumped.
>> - Existing table blobs will be refreshed (git diff will show that the files
>>  changed, asl diff will show the actual changes).
>> When new tables are introduced:
>> - Zero byte empty file blobs for new tables as instructed in the header of
>>  bios-tables-test.c will be regenerated to actual table blobs.
>> 
>> This would make analyzing changes to tables less confusing and there would
>> be no need to clean useless untracked files when there are no table changes.
>> 
>> CC: peter.mayd...@linaro.org
>> Signed-off-by: Ani Sinha 
>> ---
>> tests/qtest/bios-tables-test.c | 14 +-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>> 
>> changelog:
>> v2: commit description updated to make things a little clearer.
>>   No actual changes.
> 
> Ping ...

Ping again ...

> 
>> 
>> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
>> index 9f4bc15aab..743b509e93 100644
>> --- a/tests/qtest/bios-tables-test.c
>> +++ b/tests/qtest/bios-tables-test.c
>> @@ -109,6 +109,7 @@ static const char *iasl;
>> #endif
>> 
>> static int verbosity_level;
>> +static GArray *load_expected_aml(test_data *data);
>> 
>> static bool compare_signature(const AcpiSdtTable *sdt, const char *signature)
>> {
>> @@ -241,21 +242,32 @@ static void test_acpi_fadt_table(test_data *data)
>> 
>> static void dump_aml_files(test_data *data, bool rebuild)
>> {
>> -AcpiSdtTable *sdt;
>> +AcpiSdtTable *sdt, *exp_sdt;
>>GError *error = NULL;
>>gchar *aml_file = NULL;
>> +test_data exp_data = {};
>>gint fd;
>>ssize_t ret;
>>int i;
>> 
>> +exp_data.tables = load_expected_aml(data);
>>for (i = 0; i < data->tables->len; ++i) {
>>const char *ext = data->variant ? data->variant : "";
>>sdt = _array_index(data->tables, AcpiSdtTable, i);
>> +exp_sdt = _array_index(exp_data.tables, AcpiSdtTable, i);
>>g_assert(sdt->aml);
>> +g_assert(exp_sdt->aml);
>> 
>>if (rebuild) {
>>aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, 
>> data->machine,
>>   sdt->aml, ext);
>> +if (!g_file_test(aml_file, G_FILE_TEST_EXISTS) &&
>> +sdt->aml_len == exp_sdt->aml_len &&
>> +!memcmp(sdt->aml, exp_sdt->aml, sdt->aml_len)) {
>> +/* identical tables, no need to write new files */
>> +g_free(aml_file);
>> +continue;
>> +}
>>fd = g_open(aml_file, O_WRONLY|O_TRUNC|O_CREAT,
>>S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH);
>>if (fd < 0) {
>> -- 
>> 2.42.0

Re: [PATCH-for-8.2?] hw/acpi/erst: Do not ignore Error* in realize handler

[Ani Sinha]

> On 20-Nov-2023, at 6:30 PM, Philippe Mathieu-Daudé  wrote:
> 
> erst_realizefn() calls functions which could update the 'errp'
> argument, but then ignores it. Use the ERRP_GUARD() macro and
> check *errp, as suggested in commit ae7c80a7bd ("error: New macro
> ERRP_GUARD()").
> 
> Cc: qemu-sta...@nongnu.org
> Fixes: f7e26ffa59 ("ACPI ERST: support for ACPI ERST feature")
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Ani Sinha 

> ---
> hw/acpi/erst.c | 10 ++
> 1 file changed, 10 insertions(+)
> 
> diff --git a/hw/acpi/erst.c b/hw/acpi/erst.c
> index 35007d8017..ba751dc60e 100644
> --- a/hw/acpi/erst.c
> +++ b/hw/acpi/erst.c
> @@ -947,6 +947,7 @@ static const VMStateDescription erst_vmstate  = {
> 
> static void erst_realizefn(PCIDevice *pci_dev, Error **errp)
> {
> +ERRP_GUARD();
> ERSTDeviceState *s = ACPIERST(pci_dev);
> 
> trace_acpi_erst_realizefn_in();
> @@ -964,9 +965,15 @@ static void erst_realizefn(PCIDevice *pci_dev, Error 
> **errp)
> 
> /* HostMemoryBackend size will be multiple of PAGE_SIZE */
> s->storage_size = object_property_get_int(OBJECT(s->hostmem), "size", 
> errp);
> +if (*errp) {
> +return;
> +}
> 
> /* Initialize backend storage and record_count */
> check_erst_backend_storage(s, errp);
> +if (*errp) {
> +return;
> +}
> 
> /* BAR 0: Programming registers */
> memory_region_init_io(>iomem_mr, OBJECT(pci_dev), _reg_ops, s,
> @@ -977,6 +984,9 @@ static void erst_realizefn(PCIDevice *pci_dev, Error 
> **errp)
> memory_region_init_ram(>exchange_mr, OBJECT(pci_dev),
> "erst.exchange",
> le32_to_cpu(s->header->record_size), errp);
> +if (*errp) {
> +return;
> +}
> pci_register_bar(pci_dev, 1, PCI_BASE_ADDRESS_SPACE_MEMORY,
> >exchange_mr);
> 
> -- 
> 2.41.0
> 

Re: [PATCH 1/3] tests/avocado: reverse_debugging drain console to prevent hang

[Ani Sinha]

> On 16-Nov-2023, at 7:01 PM, Ani Sinha  wrote:
> 
> 
> 
>> On 16-Nov-2023, at 6:56 PM, Ani Sinha  wrote:
>> 
>> 
>> 
>>> On 16-Nov-2023, at 5:23 PM, Nicholas Piggin  wrote:
>>> 
>>> Like replay_linux.py, reverse_debugging.py starts the vm with console
>>> set but does not interact with it (e.g., with wait_for_console_pattern).
>>> In this situation, the console should have a drainer attached so the
>>> socket does not fill. replay_linux.py has a drainer, but it is missing
>>> from reverse_debugging.py.
>>> 
>>> Per analysis in Link: this can cause the console socket/pipe to fill and
>>> QEMU get stuck in qemu_chr_write_buffer, leading to strange test case
>>> failures (ppc64 fails because it prints a lot to console in early bios).
>>> Attaching a drainer prevents this.
>>> 
>>> Note, this commit does not fix bugs introduced by the commits referenced
>>> in the first two Fixes: tags, but together those commits conspire to
>>> irritate the problem and cause test case failure, which this commit
>>> fixes.
>>> 
>>> Link: https://lore.kernel.org/qemu-devel/zvt-by9yor69q...@redhat.com/
>>> Fixes: 1d4796cd0083 ("python/machine: use socketpair() for console 
>>> connections")
>>> Fixes: 761a13b23946 ("tests/avocado: ppc64 reverse debugging tests for 
>>> pseries and powernv")
>>> Fixes: be52eca30978 ("tests/acceptance: add reverse debugging test")
>>> Tested-by: Thomas Huth 
>>> Signed-off-by: Nicholas Piggin 
>> 
>> Reviewed-by: Ani Sinha mailto:anisi...@redhat.com>>
> 
> This bs started happening recently once I upgraded my OS. Sorry about that.
> 
> Reviewed-by: Ani Sinha mailto:anisi...@redhat.com>>

Trying again

Reviewed-by: Ani Sinha 


> 
> 
>> 
>>> ---
>>> tests/avocado/reverse_debugging.py | 5 +
>>> 1 file changed, 5 insertions(+)
>>> 
>>> diff --git a/tests/avocado/reverse_debugging.py 
>>> b/tests/avocado/reverse_debugging.py
>>> index fc47874eda..128d85bc0e 100644
>>> --- a/tests/avocado/reverse_debugging.py
>>> +++ b/tests/avocado/reverse_debugging.py
>>> @@ -12,6 +12,7 @@
>>> 
>>> from avocado import skipIf
>>> from avocado_qemu import BUILD_DIR
>>> +from avocado.utils import datadrainer
>>> from avocado.utils import gdb
>>> from avocado.utils import process
>>> from avocado.utils.network.ports import find_free_port
>>> @@ -52,6 +53,10 @@ def run_vm(self, record, shift, args, replay_path, 
>>> image_path, port):
>>>   if args:
>>>   vm.add_args(*args)
>>>   vm.launch()
>>> +console_drainer = 
>>> datadrainer.LineLogger(vm.console_socket.fileno(),
>>> +logger=self.log.getChild('console'),
>>> +stop_check=(lambda : not 
>>> vm.is_running()))
>>> +console_drainer.start()
>>>   return vm
>>> 
>>>   @staticmethod
>>> -- 
>>> 2.42.0

Re: [PATCH 1/3] tests/avocado: reverse_debugging drain console to prevent hang

[Ani Sinha]

> On 16-Nov-2023, at 6:56 PM, Ani Sinha  wrote:
> 
> 
> 
>> On 16-Nov-2023, at 5:23 PM, Nicholas Piggin  wrote:
>> 
>> Like replay_linux.py, reverse_debugging.py starts the vm with console
>> set but does not interact with it (e.g., with wait_for_console_pattern).
>> In this situation, the console should have a drainer attached so the
>> socket does not fill. replay_linux.py has a drainer, but it is missing
>> from reverse_debugging.py.
>> 
>> Per analysis in Link: this can cause the console socket/pipe to fill and
>> QEMU get stuck in qemu_chr_write_buffer, leading to strange test case
>> failures (ppc64 fails because it prints a lot to console in early bios).
>> Attaching a drainer prevents this.
>> 
>> Note, this commit does not fix bugs introduced by the commits referenced
>> in the first two Fixes: tags, but together those commits conspire to
>> irritate the problem and cause test case failure, which this commit
>> fixes.
>> 
>> Link: https://lore.kernel.org/qemu-devel/zvt-by9yor69q...@redhat.com/
>> Fixes: 1d4796cd0083 ("python/machine: use socketpair() for console 
>> connections")
>> Fixes: 761a13b23946 ("tests/avocado: ppc64 reverse debugging tests for 
>> pseries and powernv")
>> Fixes: be52eca30978 ("tests/acceptance: add reverse debugging test")
>> Tested-by: Thomas Huth 
>> Signed-off-by: Nicholas Piggin 
> 
> Reviewed-by: Ani Sinha mailto:anisi...@redhat.com>>

This bs started happening recently once I upgraded my OS. Sorry about that.

Reviewed-by: Ani Sinha mailto:anisi...@redhat.com>>


> 
>> ---
>> tests/avocado/reverse_debugging.py | 5 +
>> 1 file changed, 5 insertions(+)
>> 
>> diff --git a/tests/avocado/reverse_debugging.py 
>> b/tests/avocado/reverse_debugging.py
>> index fc47874eda..128d85bc0e 100644
>> --- a/tests/avocado/reverse_debugging.py
>> +++ b/tests/avocado/reverse_debugging.py
>> @@ -12,6 +12,7 @@
>> 
>> from avocado import skipIf
>> from avocado_qemu import BUILD_DIR
>> +from avocado.utils import datadrainer
>> from avocado.utils import gdb
>> from avocado.utils import process
>> from avocado.utils.network.ports import find_free_port
>> @@ -52,6 +53,10 @@ def run_vm(self, record, shift, args, replay_path, 
>> image_path, port):
>>if args:
>>vm.add_args(*args)
>>vm.launch()
>> +console_drainer = datadrainer.LineLogger(vm.console_socket.fileno(),
>> +logger=self.log.getChild('console'),
>> +stop_check=(lambda : not 
>> vm.is_running()))
>> +console_drainer.start()
>>return vm
>> 
>>@staticmethod
>> -- 
>> 2.42.0

Re: [PATCH 1/3] tests/avocado: reverse_debugging drain console to prevent hang

[Ani Sinha]

> On 16-Nov-2023, at 5:23 PM, Nicholas Piggin  wrote:
> 
> Like replay_linux.py, reverse_debugging.py starts the vm with console
> set but does not interact with it (e.g., with wait_for_console_pattern).
> In this situation, the console should have a drainer attached so the
> socket does not fill. replay_linux.py has a drainer, but it is missing
> from reverse_debugging.py.
> 
> Per analysis in Link: this can cause the console socket/pipe to fill and
> QEMU get stuck in qemu_chr_write_buffer, leading to strange test case
> failures (ppc64 fails because it prints a lot to console in early bios).
> Attaching a drainer prevents this.
> 
> Note, this commit does not fix bugs introduced by the commits referenced
> in the first two Fixes: tags, but together those commits conspire to
> irritate the problem and cause test case failure, which this commit
> fixes.
> 
> Link: https://lore.kernel.org/qemu-devel/zvt-by9yor69q...@redhat.com/
> Fixes: 1d4796cd0083 ("python/machine: use socketpair() for console 
> connections")
> Fixes: 761a13b23946 ("tests/avocado: ppc64 reverse debugging tests for 
> pseries and powernv")
> Fixes: be52eca30978 ("tests/acceptance: add reverse debugging test")
> Tested-by: Thomas Huth 
> Signed-off-by: Nicholas Piggin 

Reviewed-by: Ani Sinha mailto:anisi...@redhat.com> 
<mailto:anisi...@redhat.com>>

> ---
> tests/avocado/reverse_debugging.py | 5 +
> 1 file changed, 5 insertions(+)
> 
> diff --git a/tests/avocado/reverse_debugging.py 
> b/tests/avocado/reverse_debugging.py
> index fc47874eda..128d85bc0e 100644
> --- a/tests/avocado/reverse_debugging.py
> +++ b/tests/avocado/reverse_debugging.py
> @@ -12,6 +12,7 @@
> 
> from avocado import skipIf
> from avocado_qemu import BUILD_DIR
> +from avocado.utils import datadrainer
> from avocado.utils import gdb
> from avocado.utils import process
> from avocado.utils.network.ports import find_free_port
> @@ -52,6 +53,10 @@ def run_vm(self, record, shift, args, replay_path, 
> image_path, port):
>if args:
>vm.add_args(*args)
>vm.launch()
> +console_drainer = datadrainer.LineLogger(vm.console_socket.fileno(),
> +logger=self.log.getChild('console'),
> +stop_check=(lambda : not 
> vm.is_running()))
> +console_drainer.start()
>return vm
> 
>@staticmethod
> -- 
> 2.42.0

Re: [PATCH] tests/avocado/reverse_debugging: Disable the ppc64 tests by default

[Ani Sinha]

> On 16-Nov-2023, at 2:25 PM, Daniel P. Berrangé  wrote:
> 
> On Thu, Nov 16, 2023 at 05:14:43PM +1000, Nicholas Piggin wrote:
>> On Thu Nov 16, 2023 at 1:55 PM AEST, Ani Sinha wrote:
>>> 
>>> 
>>>> On 16-Nov-2023, at 6:45 AM, Nicholas Piggin  wrote:
>>>> 
>>>> On Thu Nov 16, 2023 at 3:22 AM AEST, Daniel P. Berrangé wrote:
>>>>> On Wed, Nov 15, 2023 at 01:14:53PM +, Daniel P. Berrangé wrote:
>>>>>> On Wed, Nov 15, 2023 at 07:23:01AM +0100, Thomas Huth wrote:
>>>>>>> On 15/11/2023 02.15, Nicholas Piggin wrote:
>>>>>>>> On Wed Nov 15, 2023 at 4:29 AM AEST, Thomas Huth wrote:
>>>>>>>>> On 14/11/2023 17.37, Philippe Mathieu-Daudé wrote:
>>>>>>>>>> On 14/11/23 17:31, Thomas Huth wrote:
>>>>>>>>>>> The tests seem currently to be broken. Disable them by default
>>>>>>>>>>> until someone fixes them.
>>>>>>>>>>> 
>>>>>>>>>>> Signed-off-by: Thomas Huth 
>>>>>>>>>>> ---
>>>>>>>>>>>  tests/avocado/reverse_debugging.py | 7 ---
>>>>>>>>>>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>>>>>> 
>>>>>>>>>> Similarly, I suspect 
>>>>>>>>>> https://gitlab.com/qemu-project/qemu/-/issues/1961
>>>>>>>>>> which has a fix ready:
>>>>>>>>>> https://lore.kernel.org/qemu-devel/20231110170831.185001-1-richard.hender...@linaro.org/
>>>>>>>>>> 
>>>>>>>>>> Maybe wait the fix gets in first?
>>>>>>>>> 
>>>>>>>>> No, I applied Richard's patch, but the problem persists. Does this 
>>>>>>>>> test
>>>>>>>>> still work for you?
>>>>>>>> 
>>>>>>>> I bisected it to 1d4796cd008373 ("python/machine: use socketpair() for
>>>>>>>> console connections"),
>>>>>>> 
>>>>>>> Maybe John (who wrote that commit) can help?
>>>>>> 
>>>>>> I find it hard to believe this commit is a direct root cause of the
>>>>>> problem since all it does is change the QEMU startup sequence so that
>>>>>> instead of QEMU listening for a monitor connection, it is given a
>>>>>> pre-opened monitor connection.
>>>>>> 
>>>>>> At the very most that should affect the startup timing a little.
>>>>>> 
>>>>>> I notice all the reverse debugging tests have a skip on gitlab
>>>>>> with a comment:
>>>>>> 
>>>>>>   # unidentified gitlab timeout problem
>>>>>> 
>>>>>> this makes be suspicious that John's patch has merely made this
>>>>>> (henceforth undiagnosed) timeout more likely to ocurr.
>>>>> 
>>>>> After an absolutely horrendous hours long debugging session I think
>>>>> I figured out the problem. The QEMU process is blocking in
>>>>> 
>>>>>   qemu_chr_write_buffer
>>>>> 
>>>>> spinning in the loop on EAGAIN.
>>>> 
>>>> Great work.
>>>> 
>>>> Why does this make the gdb socket give an empty response? Something
>>>> just times out?
>>>> 
>>>>> 
>>>>> The Python  Machine() class has passed one of a pre-created socketpair
>>>>> FDs for the serial port chardev. The guest is trying to write to this
>>>>> and blocking.  Nothing in the Machine() class is reading from the
>>>>> other end of the serial port console.
>>>>> 
>>>>> 
>>>>> Before John's change, the serial port uses a chardev in server mode
>>>>> and crucially  'wait=off', and the Machine() class never opened the
>>>>> console socket unless the test case wanted to read from it.
>>>>> 
>>>>> IOW, QEMU had a background job setting there waiting for a connection
>>>>> that would never come.
>>>>> 
>>>>> As a result when QEMU started executing the guest, all the serial port
>>>>> writes get sent into to the void.
>>>>> 
>>>>> 
>>>>> So

Re: [PATCH] tests/avocado/mem-addr-space-check: Replace assertEquals() for Python 3.12

[Ani Sinha]

> On 16-Nov-2023, at 12:56 PM, Ani Sinha  wrote:
> 
> 
> 
>> On 16-Nov-2023, at 11:49 AM, Thomas Huth  wrote:
>> 
>> assertEquals() has been removed in Python 3.12 and should be replaced by
>> assertEqual(). See: https://docs.python.org/3.12/whatsnew/3.12.html#id3
>> 
>> Signed-off-by: Thomas Huth 
> 
> Acked-by: Ani Sinha mailto:anisi...@redhat.com>>

Acked-by: Ani Sinha 

> 
>> ---
>> Note: The test has just been merged, that's why I missed this file in
>> my earlier patch that replaces the assertEquals()
>> 
>> tests/avocado/mem-addr-space-check.py | 14 +++---
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>> 
>> diff --git a/tests/avocado/mem-addr-space-check.py 
>> b/tests/avocado/mem-addr-space-check.py
>> index be949222a4..363c3f12a6 100644
>> --- a/tests/avocado/mem-addr-space-check.py
>> +++ b/tests/avocado/mem-addr-space-check.py
>> @@ -49,7 +49,7 @@ def test_phybits_low_pse36(self):
>>self.vm.set_qmp_monitor(enabled=False)
>>self.vm.launch()
>>self.vm.wait()
>> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>>self.assertRegex(self.vm.get_log(), r'phys-bits too low')
>> 
>>def test_phybits_low_pae(self):
>> @@ -69,7 +69,7 @@ def test_phybits_low_pae(self):
>>self.vm.set_qmp_monitor(enabled=False)
>>self.vm.launch()
>>self.vm.wait()
>> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>>self.assertRegex(self.vm.get_log(), r'phys-bits too low')
>> 
>>def test_phybits_ok_pentium_pse36(self):
>> @@ -149,7 +149,7 @@ def test_phybits_low_nonpse36(self):
>>self.vm.set_qmp_monitor(enabled=False)
>>self.vm.launch()
>>self.vm.wait()
>> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>>self.assertRegex(self.vm.get_log(), r'phys-bits too low')
>> 
>># now lets test some 64-bit CPU cases.
>> @@ -179,7 +179,7 @@ def test_phybits_low_tcg_q35_70_amd(self):
>>self.vm.set_qmp_monitor(enabled=False)
>>self.vm.launch()
>>self.vm.wait()
>> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>>self.assertRegex(self.vm.get_log(), r'phys-bits too low')
>> 
>>def test_phybits_low_tcg_q35_71_amd(self):
>> @@ -202,7 +202,7 @@ def test_phybits_low_tcg_q35_71_amd(self):
>>self.vm.set_qmp_monitor(enabled=False)
>>self.vm.launch()
>>self.vm.wait()
>> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>>self.assertRegex(self.vm.get_log(), r'phys-bits too low')
>> 
>>def test_phybits_ok_tcg_q35_70_amd(self):
>> @@ -288,7 +288,7 @@ def test_phybits_low_tcg_q35_71_amd_41bits(self):
>>self.vm.set_qmp_monitor(enabled=False)
>>self.vm.launch()
>>self.vm.wait()
>> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>>self.assertRegex(self.vm.get_log(), r'phys-bits too low')
>> 
>>def test_phybits_ok_tcg_q35_71_amd_41bits(self):
>> @@ -332,7 +332,7 @@ def test_phybits_low_tcg_q35_intel_cxl(self):
>>self.vm.set_qmp_monitor(enabled=False)
>>self.vm.launch()
>>self.vm.wait()
>> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 
>> 1")
>>self.assertRegex(self.vm.get_log(), r'phys-bits too low')
>> 
>>def test_phybits_ok_tcg_q35_intel_cxl(self):
>> -- 
>> 2.41.0
>> 
> 

Re: [PATCH] tests/avocado/mem-addr-space-check: Replace assertEquals() for Python 3.12

[Ani Sinha]

> On 16-Nov-2023, at 11:49 AM, Thomas Huth  wrote:
> 
> assertEquals() has been removed in Python 3.12 and should be replaced by
> assertEqual(). See: https://docs.python.org/3.12/whatsnew/3.12.html#id3
> 
> Signed-off-by: Thomas Huth 

Acked-by: Ani Sinha mailto:anisi...@redhat.com>>

> ---
> Note: The test has just been merged, that's why I missed this file in
> my earlier patch that replaces the assertEquals()
> 
> tests/avocado/mem-addr-space-check.py | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/tests/avocado/mem-addr-space-check.py 
> b/tests/avocado/mem-addr-space-check.py
> index be949222a4..363c3f12a6 100644
> --- a/tests/avocado/mem-addr-space-check.py
> +++ b/tests/avocado/mem-addr-space-check.py
> @@ -49,7 +49,7 @@ def test_phybits_low_pse36(self):
> self.vm.set_qmp_monitor(enabled=False)
> self.vm.launch()
> self.vm.wait()
> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
> 1")
> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1")
> self.assertRegex(self.vm.get_log(), r'phys-bits too low')
> 
> def test_phybits_low_pae(self):
> @@ -69,7 +69,7 @@ def test_phybits_low_pae(self):
> self.vm.set_qmp_monitor(enabled=False)
> self.vm.launch()
> self.vm.wait()
> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
> 1")
> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1")
> self.assertRegex(self.vm.get_log(), r'phys-bits too low')
> 
> def test_phybits_ok_pentium_pse36(self):
> @@ -149,7 +149,7 @@ def test_phybits_low_nonpse36(self):
> self.vm.set_qmp_monitor(enabled=False)
> self.vm.launch()
> self.vm.wait()
> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
> 1")
> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1")
> self.assertRegex(self.vm.get_log(), r'phys-bits too low')
> 
> # now lets test some 64-bit CPU cases.
> @@ -179,7 +179,7 @@ def test_phybits_low_tcg_q35_70_amd(self):
> self.vm.set_qmp_monitor(enabled=False)
> self.vm.launch()
> self.vm.wait()
> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
> 1")
> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1")
> self.assertRegex(self.vm.get_log(), r'phys-bits too low')
> 
> def test_phybits_low_tcg_q35_71_amd(self):
> @@ -202,7 +202,7 @@ def test_phybits_low_tcg_q35_71_amd(self):
> self.vm.set_qmp_monitor(enabled=False)
> self.vm.launch()
> self.vm.wait()
> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
> 1")
> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1")
> self.assertRegex(self.vm.get_log(), r'phys-bits too low')
> 
> def test_phybits_ok_tcg_q35_70_amd(self):
> @@ -288,7 +288,7 @@ def test_phybits_low_tcg_q35_71_amd_41bits(self):
> self.vm.set_qmp_monitor(enabled=False)
> self.vm.launch()
> self.vm.wait()
> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
> 1")
> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1")
> self.assertRegex(self.vm.get_log(), r'phys-bits too low')
> 
> def test_phybits_ok_tcg_q35_71_amd_41bits(self):
> @@ -332,7 +332,7 @@ def test_phybits_low_tcg_q35_intel_cxl(self):
> self.vm.set_qmp_monitor(enabled=False)
> self.vm.launch()
> self.vm.wait()
> -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 
> 1")
> +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1")
> self.assertRegex(self.vm.get_log(), r'phys-bits too low')
> 
> def test_phybits_ok_tcg_q35_intel_cxl(self):
> -- 
> 2.41.0
> 

Re: [PATCH v2] tests/acpi/bios-tables-test: do not write new blobs unless there are changes

[Ani Sinha]

> On 07-Nov-2023, at 10:19 AM, Ani Sinha  wrote:
> 
> When dumping table blobs using rebuild-expected-aml.sh, table blobs from all
> test variants are dumped regardless of whether there are any actual changes to
> the tables or not. This creates lot of new files for various test variants 
> that
> are not part of the git repository. This is because we do not check in all 
> table
> blobs for all test variants into the repository. Only those blobs for those
> variants that are different from the generic test-variant agnostic blob are
> checked in.
> 
> This change makes the test smarter by checking if at all there are any changes
> in the tables from the checked-in gold master blobs and take actions
> accordingly.
> 
> When there are no changes:
> - No new table blobs would be written.
> - Existing table blobs will be refreshed (git diff will show no changes).
> When there are changes:
> - New table blob files will be dumped.
> - Existing table blobs will be refreshed (git diff will show that the files
>   changed, asl diff will show the actual changes).
> When new tables are introduced:
> - Zero byte empty file blobs for new tables as instructed in the header of
>   bios-tables-test.c will be regenerated to actual table blobs.
> 
> This would make analyzing changes to tables less confusing and there would
> be no need to clean useless untracked files when there are no table changes.
> 
> CC: peter.mayd...@linaro.org
> Signed-off-by: Ani Sinha 
> ---
> tests/qtest/bios-tables-test.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
> 
> changelog:
> v2: commit description updated to make things a little clearer.
>No actual changes.

Ping ...

> 
> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
> index 9f4bc15aab..743b509e93 100644
> --- a/tests/qtest/bios-tables-test.c
> +++ b/tests/qtest/bios-tables-test.c
> @@ -109,6 +109,7 @@ static const char *iasl;
> #endif
> 
> static int verbosity_level;
> +static GArray *load_expected_aml(test_data *data);
> 
> static bool compare_signature(const AcpiSdtTable *sdt, const char *signature)
> {
> @@ -241,21 +242,32 @@ static void test_acpi_fadt_table(test_data *data)
> 
> static void dump_aml_files(test_data *data, bool rebuild)
> {
> -AcpiSdtTable *sdt;
> +AcpiSdtTable *sdt, *exp_sdt;
> GError *error = NULL;
> gchar *aml_file = NULL;
> +test_data exp_data = {};
> gint fd;
> ssize_t ret;
> int i;
> 
> +exp_data.tables = load_expected_aml(data);
> for (i = 0; i < data->tables->len; ++i) {
> const char *ext = data->variant ? data->variant : "";
> sdt = _array_index(data->tables, AcpiSdtTable, i);
> +exp_sdt = _array_index(exp_data.tables, AcpiSdtTable, i);
> g_assert(sdt->aml);
> +g_assert(exp_sdt->aml);
> 
> if (rebuild) {
> aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, 
> data->machine,
>sdt->aml, ext);
> +if (!g_file_test(aml_file, G_FILE_TEST_EXISTS) &&
> +sdt->aml_len == exp_sdt->aml_len &&
> +!memcmp(sdt->aml, exp_sdt->aml, sdt->aml_len)) {
> +/* identical tables, no need to write new files */
> +g_free(aml_file);
> +continue;
> +}
> fd = g_open(aml_file, O_WRONLY|O_TRUNC|O_CREAT,
> S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH);
> if (fd < 0) {
> -- 
> 2.42.0
> 

Re: [PATCH] tests/avocado/reverse_debugging: Disable the ppc64 tests by default

[Ani Sinha]

> On 16-Nov-2023, at 6:45 AM, Nicholas Piggin  wrote:
> 
> On Thu Nov 16, 2023 at 3:22 AM AEST, Daniel P. Berrangé wrote:
>> On Wed, Nov 15, 2023 at 01:14:53PM +, Daniel P. Berrangé wrote:
>>> On Wed, Nov 15, 2023 at 07:23:01AM +0100, Thomas Huth wrote:
 On 15/11/2023 02.15, Nicholas Piggin wrote:
> On Wed Nov 15, 2023 at 4:29 AM AEST, Thomas Huth wrote:
>> On 14/11/2023 17.37, Philippe Mathieu-Daudé wrote:
>>> On 14/11/23 17:31, Thomas Huth wrote:
 The tests seem currently to be broken. Disable them by default
 until someone fixes them.
 
 Signed-off-by: Thomas Huth 
 ---
   tests/avocado/reverse_debugging.py | 7 ---
   1 file changed, 4 insertions(+), 3 deletions(-)
>>> 
>>> Similarly, I suspect https://gitlab.com/qemu-project/qemu/-/issues/1961
>>> which has a fix ready:
>>> https://lore.kernel.org/qemu-devel/20231110170831.185001-1-richard.hender...@linaro.org/
>>> 
>>> Maybe wait the fix gets in first?
>> 
>> No, I applied Richard's patch, but the problem persists. Does this test
>> still work for you?
> 
> I bisected it to 1d4796cd008373 ("python/machine: use socketpair() for
> console connections"),
 
 Maybe John (who wrote that commit) can help?
>>> 
>>> I find it hard to believe this commit is a direct root cause of the
>>> problem since all it does is change the QEMU startup sequence so that
>>> instead of QEMU listening for a monitor connection, it is given a
>>> pre-opened monitor connection.
>>> 
>>> At the very most that should affect the startup timing a little.
>>> 
>>> I notice all the reverse debugging tests have a skip on gitlab
>>> with a comment:
>>> 
>>># unidentified gitlab timeout problem
>>> 
>>> this makes be suspicious that John's patch has merely made this
>>> (henceforth undiagnosed) timeout more likely to ocurr.
>> 
>> After an absolutely horrendous hours long debugging session I think
>> I figured out the problem. The QEMU process is blocking in
>> 
>>qemu_chr_write_buffer
>> 
>> spinning in the loop on EAGAIN.
> 
> Great work.
> 
> Why does this make the gdb socket give an empty response? Something
> just times out?
> 
>> 
>> The Python  Machine() class has passed one of a pre-created socketpair
>> FDs for the serial port chardev. The guest is trying to write to this
>> and blocking.  Nothing in the Machine() class is reading from the
>> other end of the serial port console.
>> 
>> 
>> Before John's change, the serial port uses a chardev in server mode
>> and crucially  'wait=off', and the Machine() class never opened the
>> console socket unless the test case wanted to read from it.
>> 
>> IOW, QEMU had a background job setting there waiting for a connection
>> that would never come.
>> 
>> As a result when QEMU started executing the guest, all the serial port
>> writes get sent into to the void.
>> 
>> 
>> So John's patch has had a semantic change in behaviour, because the
>> console socket is permanently open, and thus socket buffers are liable
>> to fill up.
>> 
>> As a demo I increased the socket buffers to 1MB and everything then
>> succeeded.
>> 
>> @@ -357,6 +360,10 @@ def _pre_launch(self) -> None:
>> 
>> if self._console_set:
>> self._cons_sock_pair = socket.socketpair()
>> +self._cons_sock_pair[0].setsockopt(socket.SOL_SOCKET, 
>> socket.SO_SNDBUF, 1024*1024);
>> +self._cons_sock_pair[0].setsockopt(socket.SOL_SOCKET, 
>> socket.SO_RCVBUF, 1024*1024);
>> +self._cons_sock_pair[1].setsockopt(socket.SOL_SOCKET, 
>> socket.SO_SNDBUF, 1024*1024);
>> +self._cons_sock_pair[1].setsockopt(socket.SOL_SOCKET, 
>> socket.SO_RCVBUF, 1024*1024);
>> os.set_inheritable(self._cons_sock_pair[0].fileno(), True)
>> 
>> # NOTE: Make sure any opened resources are *definitely* freed in
> 
> So perhaps ppc64 fails just because it prints more to the console in early
> boot than other targets?
> 
>> The Machine class doesn't know if anything will ever use the console,
>> so as is the change is unsafe.
>> 
>> The original goal of John's change was to guarantee we capture early
>> boot messages as some test need that.  
>> 
>> I think we need to be able to have a flag to say whether the caller needs
>> an "early console" facility, and only use the pre-opened FD passing for
>> that case. Tests we need early console will have to ask for that guarantee
>> explicitly.
> 
> The below patch makes this test work. Maybe as a quick fix it is
> better than disabling the test.
> 
> I guess we still have a problem if a test invokes vm.launch()
> directly without subsequently waiting for a console pattern or
> doing something with the console as you say. Your suggesstion is
> add something like vm.launch(console=True) ? 

I think what he is saying is to add a new property for QEMUMachine() with which 
the test can explicitly tell the machine init code that it is going to 

Re: [PATCH] tests/avocado/reverse_debugging: Disable the ppc64 tests by default

[Ani Sinha]

> On 15-Nov-2023, at 10:52 PM, Daniel P. Berrangé  wrote:
> 
> On Wed, Nov 15, 2023 at 01:14:53PM +, Daniel P. Berrangé wrote:
>> On Wed, Nov 15, 2023 at 07:23:01AM +0100, Thomas Huth wrote:
>>> On 15/11/2023 02.15, Nicholas Piggin wrote:
 On Wed Nov 15, 2023 at 4:29 AM AEST, Thomas Huth wrote:
> On 14/11/2023 17.37, Philippe Mathieu-Daudé wrote:
>> On 14/11/23 17:31, Thomas Huth wrote:
>>> The tests seem currently to be broken. Disable them by default
>>> until someone fixes them.
>>> 
>>> Signed-off-by: Thomas Huth 
>>> ---
>>>   tests/avocado/reverse_debugging.py | 7 ---
>>>   1 file changed, 4 insertions(+), 3 deletions(-)
>> 
>> Similarly, I suspect https://gitlab.com/qemu-project/qemu/-/issues/1961
>> which has a fix ready:
>> https://lore.kernel.org/qemu-devel/20231110170831.185001-1-richard.hender...@linaro.org/
>> 
>> Maybe wait the fix gets in first?
> 
> No, I applied Richard's patch, but the problem persists. Does this test
> still work for you?
 
 I bisected it to 1d4796cd008373 ("python/machine: use socketpair() for
 console connections"),
>>> 
>>> Maybe John (who wrote that commit) can help?
>> 
>> I find it hard to believe this commit is a direct root cause of the
>> problem since all it does is change the QEMU startup sequence so that
>> instead of QEMU listening for a monitor connection, it is given a
>> pre-opened monitor connection.
>> 
>> At the very most that should affect the startup timing a little.
>> 
>> I notice all the reverse debugging tests have a skip on gitlab
>> with a comment:
>> 
>># unidentified gitlab timeout problem
>> 
>> this makes be suspicious that John's patch has merely made this
>> (henceforth undiagnosed) timeout more likely to ocurr.
> 
> After an absolutely horrendous hours long debugging session I think
> I figured out the problem. The QEMU process is blocking in
> 
>qemu_chr_write_buffer
> 
> spinning in the loop on EAGAIN.
> 
> The Python  Machine() class has passed one of a pre-created socketpair
> FDs for the serial port chardev. The guest is trying to write to this
> and blocking.  Nothing in the Machine() class is reading from the
> other end of the serial port console.
> 
> 
> Before John's change, the serial port uses a chardev in server mode
> and crucially  'wait=off', and the Machine() class never opened the
> console socket unless the test case wanted to read from it.
> 
> IOW, QEMU had a background job setting there waiting for a connection
> that would never come.
> 
> As a result when QEMU started executing the guest, all the serial port
> writes get sent into to the void.
> 
> 
> So John's patch has had a semantic change in behaviour, because the
> console socket is permanently open, and thus socket buffers are liable
> to fill up.
> 
> As a demo I increased the socket buffers to 1MB and everything then
> succeeded.
> 
> @@ -357,6 +360,10 @@ def _pre_launch(self) -> None:
> 
> if self._console_set:
> self._cons_sock_pair = socket.socketpair()
> +self._cons_sock_pair[0].setsockopt(socket.SOL_SOCKET, 
> socket.SO_SNDBUF, 1024*1024);
> +self._cons_sock_pair[0].setsockopt(socket.SOL_SOCKET, 
> socket.SO_RCVBUF, 1024*1024);
> +self._cons_sock_pair[1].setsockopt(socket.SOL_SOCKET, 
> socket.SO_SNDBUF, 1024*1024);
> +self._cons_sock_pair[1].setsockopt(socket.SOL_SOCKET, 
> socket.SO_RCVBUF, 1024*1024);
> os.set_inheritable(self._cons_sock_pair[0].fileno(), True)
> 
> # NOTE: Make sure any opened resources are *definitely* freed in
> 
> 
> The Machine class doesn't know if anything will ever use the console,
> so as is the change is unsafe.
> 
> The original goal of John's change was to guarantee we capture early
> boot messages as some test need that.

As in 
https://gitlab.com/qemu-project/qemu/-/blob/master/tests/avocado/acpi-bits.py?ref_type=heads#L395
 ?
Some other tests do this too.

>  
> 
> I think we need to be able to have a flag to say whether the caller needs
> an "early console" facility, and only use the pre-opened FD passing for
> that case. Tests we need early console will have to ask for that guarantee
> explicitly.
> 
> With regards,
> Daniel
> -- 
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [PATCH v6] tests/avocado: add test to exercize processor address space memory bound checks

[Ani Sinha]

> On 09-Nov-2023, at 1:49 PM, Philippe Mathieu-Daudé  wrote:
> 
> On 9/11/23 05:56, Ani Sinha wrote:
>> QEMU has validations to make sure that a VM is not started with more memory
>> (static and hotpluggable memory) than what the guest processor can address
>> directly with its addressing bits. This change adds a test to make sure QEMU
>> fails to start with a specific error message when an attempt is made to
>> start a VM with more memory than what the processor can directly address.
>> The test also checks for passing cases when the address space of the 
>> processor
>> is capable of addressing all memory. Boundary cases are tested.
>> CC: imamm...@redhat.com
>> CC: David Hildenbrand 
>> Acked-by: David Hildenbrand 
>> Acked-by: Philippe Mathieu-Daudé 
>> Signed-off-by: Ani Sinha 
>> ---
>>  tests/avocado/mem-addr-space-check.py | 367 ++
>>  1 file changed, 367 insertions(+)
>>  create mode 100644 tests/avocado/mem-addr-space-check.py
>> Changelog:
>> v6: added phil's suggestions - added comment to explain why a sleep delay
>> is needed. Reduced delay to 1 sec. Added a one place definition for
>> the sleep duration so we can tweak it if needed later. Added phil's
>> tag. rebased.
>> v5:
>>   - made the negative test cases (ones that do not result in QEMU crash)
>> more robust by checking the non-existence of the "phys-bits too low"
>> log.
>>   - added a new test case for AMD HT window where QEMU starts fine.
>>   - rebased.
>>   - cosmetic typo/comment adjustments.
>> Tests all pass:
>> $ ./pyvenv/bin/avocado run tests/avocado/mem-addr-space-check.py --tap -
>> 1..15
>> ok 1 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pse36
>> ok 2 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pae
>> ok 3 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pse36
>> ok 4 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pae
>> ok 5 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium2
>> ok 6 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_nonpse36
>> ok 7 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_70_amd
>> ok 8 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd
>> ok 9 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_70_amd
>> ok 10 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd
>> ok 11 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_intel
>> ok 12 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd_41bits
>> ok 13 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd_41bits
>> ok 14 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_intel_cxl
>> ok 15 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_intel_cxl
>> v4: incorporated changes related to suggestions from David.
>> v3: added pae tests as well.
>> v2: added 64-bit tests. Added cxl tests.
>> diff --git a/tests/avocado/mem-addr-space-check.py 
>> b/tests/avocado/mem-addr-space-check.py
>> new file mode 100644
>> index 00..fae7d48598
>> --- /dev/null
>> +++ b/tests/avocado/mem-addr-space-check.py
>> @@ -0,0 +1,367 @@
>> +# Check for crash when using memory beyond the available guest processor
>> +# address space.
>> +#
>> +# Copyright (c) 2023 Red Hat, Inc.
>> +#
>> +# Author:
>> +#  Ani Sinha 
>> +#
> 
> [*]
> 
>> +# This program is free software; you can redistribute it and/or modify
>> +# it under the terms of the GNU General Public License as published by
>> +# the Free Software Foundation; either version 2 of the License, or
>> +# (at your option) any later version.
>> +#
>> +# This program is distributed in the hope that it will be useful,
>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +# GNU General Public License for more details.
>> +#
>> +# You should have received a copy of the GNU General Public License
>> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> +
>> +from avocado_qemu import QemuSystemTest
>> +import signal
>> +import time
>> +
>> +class MemAddrCheck(QemuSystemTest):
>> +# after launch, in order to generate the logs from QEMU we need to
>> +# wait for some time. Launching and then immediately shutting down
>> +# the VM generates empty logs. A delay of 1 second is added for
>> +# this reason.
>> +DELAY_Q35_BOOT_SEQUENCE = 1
> 
> Perfect, thank you!
> 
> Do you mind if I add in [*]:
> 
> # SPDX-License-Identifier: GPL-2.0-or-later
> 
> ? Optionally removing the boilerplate license comment if you offer to.

Sure, no worries.

> 
> Then I can queue this patch.
> 
> Thanks,
> 
> Phil.

[PATCH v6] tests/avocado: add test to exercize processor address space memory bound checks

[Ani Sinha]

QEMU has validations to make sure that a VM is not started with more memory
(static and hotpluggable memory) than what the guest processor can address
directly with its addressing bits. This change adds a test to make sure QEMU
fails to start with a specific error message when an attempt is made to
start a VM with more memory than what the processor can directly address.
The test also checks for passing cases when the address space of the processor
is capable of addressing all memory. Boundary cases are tested.

CC: imamm...@redhat.com
CC: David Hildenbrand 
Acked-by: David Hildenbrand 
Acked-by: Philippe Mathieu-Daudé 
Signed-off-by: Ani Sinha 
---
 tests/avocado/mem-addr-space-check.py | 367 ++
 1 file changed, 367 insertions(+)
 create mode 100644 tests/avocado/mem-addr-space-check.py

Changelog:
v6: added phil's suggestions - added comment to explain why a sleep delay
is needed. Reduced delay to 1 sec. Added a one place definition for
the sleep duration so we can tweak it if needed later. Added phil's
tag. rebased.
v5:
  - made the negative test cases (ones that do not result in QEMU crash)
more robust by checking the non-existence of the "phys-bits too low"
log.
  - added a new test case for AMD HT window where QEMU starts fine.
  - rebased.
  - cosmetic typo/comment adjustments.

Tests all pass:
$ ./pyvenv/bin/avocado run tests/avocado/mem-addr-space-check.py --tap -
1..15
ok 1 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pse36
ok 2 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pae
ok 3 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pse36
ok 4 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pae
ok 5 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium2
ok 6 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_nonpse36
ok 7 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_70_amd
ok 8 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd
ok 9 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_70_amd
ok 10 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd
ok 11 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_intel
ok 12 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd_41bits
ok 13 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd_41bits
ok 14 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_intel_cxl
ok 15 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_intel_cxl

v4: incorporated changes related to suggestions from David.
v3: added pae tests as well.
v2: added 64-bit tests. Added cxl tests.

diff --git a/tests/avocado/mem-addr-space-check.py 
b/tests/avocado/mem-addr-space-check.py
new file mode 100644
index 00..fae7d48598
--- /dev/null
+++ b/tests/avocado/mem-addr-space-check.py
@@ -0,0 +1,367 @@
+# Check for crash when using memory beyond the available guest processor
+# address space.
+#
+# Copyright (c) 2023 Red Hat, Inc.
+#
+# Author:
+#  Ani Sinha 
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+from avocado_qemu import QemuSystemTest
+import signal
+import time
+
+class MemAddrCheck(QemuSystemTest):
+# after launch, in order to generate the logs from QEMU we need to
+# wait for some time. Launching and then immediately shutting down
+# the VM generates empty logs. A delay of 1 second is added for
+# this reason.
+DELAY_Q35_BOOT_SEQUENCE = 1
+
+# first, lets test some 32-bit processors.
+# for all 32-bit cases, pci64_hole_size is 0.
+def test_phybits_low_pse36(self):
+"""
+:avocado: tags=machine:q35
+:avocado: tags=arch:x86_64
+
+With pse36 feature ON, a processor has 36 bits of addressing. So it can
+access up to a maximum of 64GiB of memory. Memory hotplug region begins
+at 4 GiB boundary when "above_4g_mem_size" is 0 (this would be true 
when
+we have 0.5 GiB of VM memory, see pc_q35_init()). This means total
+hotpluggable memory size is 60 GiB. Per slot, we reserve 1 GiB of 
memory
+for d

Re: [PATCH v5] tests/avocado: add test to exercize processor address space memory bound checks

[Ani Sinha]

> On 08-Nov-2023, at 8:33 PM, Philippe Mathieu-Daudé  wrote:
> 
> Hi Ani,
> 
> On 3/11/23 12:06, Ani Sinha wrote:
>> QEMU has validations to make sure that a VM is not started with more memory
>> (static and hotpluggable memory) than what the guest processor can address
>> directly with its addressing bits. This change adds a test to make sure QEMU
>> fails to start with a specific error message when an attempt is made to
>> start a VM with more memory than what the processor can directly address.
>> The test also checks for passing cases when the address space of the 
>> processor
>> is capable of addressing all memory. Boundary cases are tested.
>> CC: imamm...@redhat.com
>> CC: David Hildenbrand 
>> Acked-by: David Hildenbrand 
>> Signed-off-by: Ani Sinha 
>> ---
>>  tests/avocado/mem-addr-space-check.py | 361 ++
>>  1 file changed, 361 insertions(+)
>>  create mode 100644 tests/avocado/mem-addr-space-check.py
>> Changelog:
>> v5:
>>   - made the negative test cases (ones that do not result in QEMU crash)
>> more robust by checking the non-existence of the "phys-bits too low"
>> log.
>>   - added a new test case for AMD HT window where QEMU starts fine.
>>   - rebased.
>>   - cosmetic typo/comment adjustments.
>> Tests all pass:
>> $ ./pyvenv/bin/avocado run tests/avocado/mem-addr-space-check.py --tap -
>> 1..15
>> ok 1 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pse36
>> ok 2 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pae
>> ok 3 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pse36
>> ok 4 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pae
>> ok 5 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium2
>> ok 6 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_nonpse36
>> ok 7 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_70_amd
>> ok 8 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd
>> ok 9 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_70_amd
>> ok 10 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd
>> ok 11 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_intel
>> ok 12 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd_41bits
>> ok 13 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd_41bits
>> ok 14 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_intel_cxl
>> ok 15 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_intel_cxl
>> v4: incorporated changes related to suggestions from David.
>> v3: added pae tests as well.
>> v2: added 64-bit tests. Added cxl tests.
>> diff --git a/tests/avocado/mem-addr-space-check.py 
>> b/tests/avocado/mem-addr-space-check.py
>> new file mode 100644
>> index 00..6b4ada5857
>> --- /dev/null
>> +++ b/tests/avocado/mem-addr-space-check.py
>> @@ -0,0 +1,361 @@
>> +# Check for crash when using memory beyond the available guest processor
>> +# address space.
>> +#
>> +# Copyright (c) 2023 Red Hat, Inc.
>> +#
>> +# Author:
>> +#  Ani Sinha 
>> +#
>> +# This program is free software; you can redistribute it and/or modify
>> +# it under the terms of the GNU General Public License as published by
>> +# the Free Software Foundation; either version 2 of the License, or
>> +# (at your option) any later version.
>> +#
>> +# This program is distributed in the hope that it will be useful,
>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +# GNU General Public License for more details.
>> +#
>> +# You should have received a copy of the GNU General Public License
>> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> +
>> +from avocado_qemu import QemuSystemTest
>> +import signal
>> +import time
>> +
>> +class MemAddrCheck(QemuSystemTest):
>> +# first, lets test some 32-bit processors.
>> +# for all 32-bit cases, pci64_hole_size is 0.
>> +def test_phybits_low_pse36(self):
>> +"""
>> +:avocado: tags=machine:q35
>> +  

Re: [PATCH 0/2] Some biosbits avocado test fixes

[Ani Sinha]

> On 27-Oct-2023, at 8:51 AM, Ani Sinha  wrote:
> 
> Included are couple of bios bits test fixes.
> 32-bit SMBIOS entry point is enforced.
> Console logging is enabled.
> 
> I have tested these changes in the CI pipeline here and the test seems
> to pass:
> 
> https://gitlab.com/anisinha/qemu/-/jobs/5380627517

MST, are you going to queue this?

> Log:
> 
> https://cdn.artifacts.gitlab-static.net/8a/b0/8ab0aa629e9c43a80356e27a440985f41da9ad10b120a410d9f070bed092fea6/2023_10_26/5380627517/5862985776/job.log?response-content-type=text%2Fplain%3B%20charset%3Dutf-8=inline=1698376660=gprd-artifacts-cdn=ln7fYsTb8t6ch0Trsa7SHAN01QY=
> 
> CC: js...@redhat.com
> CC: jus...@redhat.com
> CC: imamm...@redhat.com
> CC: m...@redhat.com
> CC: qemu-devel@nongnu.org
> CC: cr...@redhat.com
> CC: phi...@linaro.org
> CC: Wainer dos Santos Moschetta 
> CC: Beraldo Leal 
> 
> Ani Sinha (2):
>  acpi/tests/avocado/bits: enforce 32-bit SMBIOS entry point
>  acpi/tests/avocado/bits: enable console logging from bits VM
> 
> tests/avocado/acpi-bits.py | 33 ++---
> 1 file changed, 22 insertions(+), 11 deletions(-)
> 
> -- 
> 2.42.0
> 

[PATCH v2] tests/acpi/bios-tables-test: do not write new blobs unless there are changes

[Ani Sinha]

When dumping table blobs using rebuild-expected-aml.sh, table blobs from all
test variants are dumped regardless of whether there are any actual changes to
the tables or not. This creates lot of new files for various test variants that
are not part of the git repository. This is because we do not check in all table
blobs for all test variants into the repository. Only those blobs for those
variants that are different from the generic test-variant agnostic blob are
checked in.

This change makes the test smarter by checking if at all there are any changes
in the tables from the checked-in gold master blobs and take actions
accordingly.

When there are no changes:
 - No new table blobs would be written.
 - Existing table blobs will be refreshed (git diff will show no changes).
When there are changes:
 - New table blob files will be dumped.
 - Existing table blobs will be refreshed (git diff will show that the files
   changed, asl diff will show the actual changes).
When new tables are introduced:
 - Zero byte empty file blobs for new tables as instructed in the header of
   bios-tables-test.c will be regenerated to actual table blobs.

This would make analyzing changes to tables less confusing and there would
be no need to clean useless untracked files when there are no table changes.

CC: peter.mayd...@linaro.org
Signed-off-by: Ani Sinha 
---
 tests/qtest/bios-tables-test.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

changelog:
v2: commit description updated to make things a little clearer.
No actual changes.

diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index 9f4bc15aab..743b509e93 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -109,6 +109,7 @@ static const char *iasl;
 #endif
 
 static int verbosity_level;
+static GArray *load_expected_aml(test_data *data);
 
 static bool compare_signature(const AcpiSdtTable *sdt, const char *signature)
 {
@@ -241,21 +242,32 @@ static void test_acpi_fadt_table(test_data *data)
 
 static void dump_aml_files(test_data *data, bool rebuild)
 {
-AcpiSdtTable *sdt;
+AcpiSdtTable *sdt, *exp_sdt;
 GError *error = NULL;
 gchar *aml_file = NULL;
+test_data exp_data = {};
 gint fd;
 ssize_t ret;
 int i;
 
+exp_data.tables = load_expected_aml(data);
 for (i = 0; i < data->tables->len; ++i) {
 const char *ext = data->variant ? data->variant : "";
 sdt = _array_index(data->tables, AcpiSdtTable, i);
+exp_sdt = _array_index(exp_data.tables, AcpiSdtTable, i);
 g_assert(sdt->aml);
+g_assert(exp_sdt->aml);
 
 if (rebuild) {
 aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, data->machine,
sdt->aml, ext);
+if (!g_file_test(aml_file, G_FILE_TEST_EXISTS) &&
+sdt->aml_len == exp_sdt->aml_len &&
+!memcmp(sdt->aml, exp_sdt->aml, sdt->aml_len)) {
+/* identical tables, no need to write new files */
+g_free(aml_file);
+continue;
+}
 fd = g_open(aml_file, O_WRONLY|O_TRUNC|O_CREAT,
 S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH);
 if (fd < 0) {
-- 
2.42.0

Re: [PATCH] tests/acpi/bios-tables-test: do not write new blobs unless there are changes

[Ani Sinha]

> On 06-Nov-2023, at 8:43 PM, Ani Sinha  wrote:
> 
> 
> 
>> On 06-Nov-2023, at 7:45 PM, Igor Mammedov  wrote:
>> 
>> On Thu,  2 Nov 2023 13:46:24 +0530
>> Ani Sinha  wrote:
>> 
>>> When dumping table blobs using rebuild-expected-aml.sh, table blobs from all
>>> test variants are dumped regardless of whether there are any actual changes 
>>> to
>>> the tables or not. This creates lot of new files for various test variants 
>>> that
>>> are not part of the git repository. This is because we do not check in all 
>>> table
>>> blobs for all test variants into the repository. Only those blobs for those
>>> variants that are different from the generic test-variant agnostic blob are
>>> checked in.
>>> 
>>> This change makes the test smarter by checking if at all there are any 
>>> changes
>>> in the tables from the checked-in gold master blobs.
>> 
>>> If there are no changes, no new files are written for test variants.
>>> However, existing files continue to be overwritten regardless of whether 
>>> there are changes.
>>> Hence, new files will be generated only when there are actual changes in 
>>> the tables.
>> 
>> You lost me in those 3 sentences. Perhaps rephrasing and adding examples
>> wold make it readable. (aka what's (not)writen and when)
> 
> OK I will try in v2.
> 
>> 
>> 
>>> This would make analyzing changes to tables less confusing and there would
>>> be no need to clean useless untracked files when there are no table changes.
>> 
>> what happens if an absolutely new table has been introduced which
>> is not mentioned in tests yet (will it be dumped or not)?
> 
> When a new table is introduced, there is no existing data to compare the 
> tables with. In this case, it will result in assertion in the following line:
> 
>>g_assert(exp_sdt.aml_file);
> 
> I am not sure what to do in this case except to unconditionally dump all 
> tables. Maybe introduce another flag? Not sure.

Oh wait, this patch works as is since we have said in bios-tables-test.c:

>  add empty files for new tables, if any, under tests/data/acpi  

So for new tables the lengths will not match and the table should be dumped. I 
need to test this case once. 

> 
>> 
>>> 
>>> CC: peter.mayd...@linaro.org
>>> Signed-off-by: Ani Sinha 
>>> ---
>>> tests/qtest/bios-tables-test.c | 14 +-
>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
>>> index 9f4bc15aab..743b509e93 100644
>>> --- a/tests/qtest/bios-tables-test.c
>>> +++ b/tests/qtest/bios-tables-test.c
>>> @@ -109,6 +109,7 @@ static const char *iasl;
>>> #endif
>>> 
>>> static int verbosity_level;
>>> +static GArray *load_expected_aml(test_data *data);
>>> 
>>> static bool compare_signature(const AcpiSdtTable *sdt, const char 
>>> *signature)
>>> {
>>> @@ -241,21 +242,32 @@ static void test_acpi_fadt_table(test_data *data)
>>> 
>>> static void dump_aml_files(test_data *data, bool rebuild)
>>> {
>>> -AcpiSdtTable *sdt;
>>> +AcpiSdtTable *sdt, *exp_sdt;
>>>GError *error = NULL;
>>>gchar *aml_file = NULL;
>>> +test_data exp_data = {};
>>>gint fd;
>>>ssize_t ret;
>>>int i;
>>> 
>>> +exp_data.tables = load_expected_aml(data);
>>>for (i = 0; i < data->tables->len; ++i) {
>>>const char *ext = data->variant ? data->variant : "";
>>>sdt = _array_index(data->tables, AcpiSdtTable, i);
>>> +exp_sdt = _array_index(exp_data.tables, AcpiSdtTable, i);
>>>g_assert(sdt->aml);
>>> +g_assert(exp_sdt->aml);
>>> 
>>>if (rebuild) {
>>>aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, 
>>> data->machine,
>>>   sdt->aml, ext);
>>> +if (!g_file_test(aml_file, G_FILE_TEST_EXISTS) &&
>>> +sdt->aml_len == exp_sdt->aml_len &&
>>> +!memcmp(sdt->aml, exp_sdt->aml, sdt->aml_len)) {
>>> +/* identical tables, no need to write new files */
>>> +g_free(aml_file);
>>> +continue;
>>> +}
>>>fd = g_open(aml_file, O_WRONLY|O_TRUNC|O_CREAT,
>>>S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH);
>>>if (fd < 0) {

Re: [PATCH] tests/acpi/bios-tables-test: do not write new blobs unless there are changes

[Ani Sinha]

> On 06-Nov-2023, at 7:45 PM, Igor Mammedov  wrote:
> 
> On Thu,  2 Nov 2023 13:46:24 +0530
> Ani Sinha  wrote:
> 
>> When dumping table blobs using rebuild-expected-aml.sh, table blobs from all
>> test variants are dumped regardless of whether there are any actual changes 
>> to
>> the tables or not. This creates lot of new files for various test variants 
>> that
>> are not part of the git repository. This is because we do not check in all 
>> table
>> blobs for all test variants into the repository. Only those blobs for those
>> variants that are different from the generic test-variant agnostic blob are
>> checked in.
>> 
>> This change makes the test smarter by checking if at all there are any 
>> changes
>> in the tables from the checked-in gold master blobs.
> 
>> If there are no changes, no new files are written for test variants.
>> However, existing files continue to be overwritten regardless of whether 
>> there are changes.
>> Hence, new files will be generated only when there are actual changes in the 
>> tables.
> 
> You lost me in those 3 sentences. Perhaps rephrasing and adding examples
> wold make it readable. (aka what's (not)writen and when)

OK I will try in v2.

> 
> 
>> This would make analyzing changes to tables less confusing and there would
>> be no need to clean useless untracked files when there are no table changes.
> 
> what happens if an absolutely new table has been introduced which
> is not mentioned in tests yet (will it be dumped or not)?

When a new table is introduced, there is no existing data to compare the tables 
with. In this case, it will result in assertion in the following line:

> g_assert(exp_sdt.aml_file);

I am not sure what to do in this case except to unconditionally dump all 
tables. Maybe introduce another flag? Not sure.

> 
>> 
>> CC: peter.mayd...@linaro.org
>> Signed-off-by: Ani Sinha 
>> ---
>> tests/qtest/bios-tables-test.c | 14 +-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>> 
>> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
>> index 9f4bc15aab..743b509e93 100644
>> --- a/tests/qtest/bios-tables-test.c
>> +++ b/tests/qtest/bios-tables-test.c
>> @@ -109,6 +109,7 @@ static const char *iasl;
>> #endif
>> 
>> static int verbosity_level;
>> +static GArray *load_expected_aml(test_data *data);
>> 
>> static bool compare_signature(const AcpiSdtTable *sdt, const char *signature)
>> {
>> @@ -241,21 +242,32 @@ static void test_acpi_fadt_table(test_data *data)
>> 
>> static void dump_aml_files(test_data *data, bool rebuild)
>> {
>> -AcpiSdtTable *sdt;
>> +AcpiSdtTable *sdt, *exp_sdt;
>> GError *error = NULL;
>> gchar *aml_file = NULL;
>> +test_data exp_data = {};
>> gint fd;
>> ssize_t ret;
>> int i;
>> 
>> +exp_data.tables = load_expected_aml(data);
>> for (i = 0; i < data->tables->len; ++i) {
>> const char *ext = data->variant ? data->variant : "";
>> sdt = _array_index(data->tables, AcpiSdtTable, i);
>> +exp_sdt = _array_index(exp_data.tables, AcpiSdtTable, i);
>> g_assert(sdt->aml);
>> +g_assert(exp_sdt->aml);
>> 
>> if (rebuild) {
>> aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, 
>> data->machine,
>>sdt->aml, ext);
>> +if (!g_file_test(aml_file, G_FILE_TEST_EXISTS) &&
>> +sdt->aml_len == exp_sdt->aml_len &&
>> +!memcmp(sdt->aml, exp_sdt->aml, sdt->aml_len)) {
>> +/* identical tables, no need to write new files */
>> +g_free(aml_file);
>> +continue;
>> +}
>> fd = g_open(aml_file, O_WRONLY|O_TRUNC|O_CREAT,
>> S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH);
>> if (fd < 0) {

Re: [PATCH v3] tests/avocado: add test to exercize processor address space memory bound checks

[Ani Sinha]

> On 02-Nov-2023, at 2:13 PM, David Hildenbrand  wrote:
> 
> On 01.11.23 02:29, Ani Sinha wrote:
>>> On 27-Oct-2023, at 4:12 PM, Ani Sinha  wrote:
>>> 
>>> QEMU has validations to make sure that a VM is not started with more memory
>>> (static and hotpluggable memory) than what the guest processor can address
>>> directly with its addressing bits. This change adds a test to make sure QEMU
>>> fails to start with a specific error message when an attempt is made to
>>> start a VM with more memory than what the processor can directly address.
>>> The test also checks for passing cases when the address space of the 
>>> processor
>>> is capable of addressing all memory. Boundary cases are tested.
>>> 
>>> CC: imamm...@redhat.com
>>> CC: David Hildenbrand 
>>> Signed-off-by: Ani Sinha 
>> Gentle ping on this. David does these tests look good and cover all cases 
>> more or less?
> 
> Hi,
> 
> sorry, for some reason the patches never made it to my inbox.
> 
>>> ---
>>> tests/avocado/mem-addr-space-check.py | 331 ++
>>> 1 file changed, 331 insertions(+)
>>> create mode 100644 tests/avocado/mem-addr-space-check.py
>>> 
>>> Changelog:
>>> v3: added pae tests as well.
>>> v2: added 64-bit tests. Added cxl tests.
>>> 
>>> Sample run:
>>> $ ./pyvenv/bin/avocado run tests/avocado/mem-addr-space-check.py --tap -
>>> 1..14
>>> ok 1 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pse36
>>> ok 2 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pae
>>> ok 3 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pse36
>>> ok 4 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pae
>>> ok 5 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium2
>>> ok 6 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_nonpse36
>>> ok 7 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_70_amd
>>> ok 8 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd
>>> ok 9 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_70_amd
>>> ok 10 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd
>>> ok 11 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_intel
>>> ok 12 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd_41bits
>>> ok 13 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_intel_cxl
>>> ok 14 
>>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_intel_cxl
>>> 
>>> diff --git a/tests/avocado/mem-addr-space-check.py 
>>> b/tests/avocado/mem-addr-space-check.py
>>> new file mode 100644
>>> index 00..6ded11d658
>>> --- /dev/null
>>> +++ b/tests/avocado/mem-addr-space-check.py
>>> @@ -0,0 +1,331 @@
>>> +# Check for crash when using memory beyond the available guest processor
>>> +# address space.
>>> +#
>>> +# Copyright (c) 2023 Red Hat, Inc.
>>> +#
>>> +# Author:
>>> +#  Ani Sinha 
>>> +#
>>> +# This program is free software; you can redistribute it and/or modify
>>> +# it under the terms of the GNU General Public License as published by
>>> +# the Free Software Foundation; either version 2 of the License, or
>>> +# (at your option) any later version.
>>> +#
>>> +# This program is distributed in the hope that it will be useful,
>>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> +# GNU General Public License for more details.
>>> +#
>>> +# You should have received a copy of the GNU General Public License
>>> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>> +
>>> +from avocado_qemu import QemuSystemTest
>>> +import signal
>>> +
>>> +class MemAddrCheck(QemuSystemTest):
>>> +# first, lets test some 32-bit processors.
>>> +# for all 32-bit cases, pci64_hole_size is 0.
>>> +def test_phybits_low_pse36(self):
>>> +"""
>>> +   

[PATCH v5] tests/avocado: add test to exercize processor address space memory bound checks

[Ani Sinha]

QEMU has validations to make sure that a VM is not started with more memory
(static and hotpluggable memory) than what the guest processor can address
directly with its addressing bits. This change adds a test to make sure QEMU
fails to start with a specific error message when an attempt is made to
start a VM with more memory than what the processor can directly address.
The test also checks for passing cases when the address space of the processor
is capable of addressing all memory. Boundary cases are tested.

CC: imamm...@redhat.com
CC: David Hildenbrand 
Acked-by: David Hildenbrand 
Signed-off-by: Ani Sinha 
---
 tests/avocado/mem-addr-space-check.py | 361 ++
 1 file changed, 361 insertions(+)
 create mode 100644 tests/avocado/mem-addr-space-check.py

Changelog:
v5:
  - made the negative test cases (ones that do not result in QEMU crash)
more robust by checking the non-existence of the "phys-bits too low"
log.
  - added a new test case for AMD HT window where QEMU starts fine.
  - rebased.
  - cosmetic typo/comment adjustments.

Tests all pass:
$ ./pyvenv/bin/avocado run tests/avocado/mem-addr-space-check.py --tap -
1..15
ok 1 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pse36
ok 2 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pae
ok 3 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pse36
ok 4 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pae
ok 5 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium2
ok 6 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_nonpse36
ok 7 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_70_amd
ok 8 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd
ok 9 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_70_amd
ok 10 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd
ok 11 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_intel
ok 12 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd_41bits
ok 13 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd_41bits
ok 14 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_intel_cxl
ok 15 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_intel_cxl

v4: incorporated changes related to suggestions from David.
v3: added pae tests as well.
v2: added 64-bit tests. Added cxl tests.

diff --git a/tests/avocado/mem-addr-space-check.py 
b/tests/avocado/mem-addr-space-check.py
new file mode 100644
index 00..6b4ada5857
--- /dev/null
+++ b/tests/avocado/mem-addr-space-check.py
@@ -0,0 +1,361 @@
+# Check for crash when using memory beyond the available guest processor
+# address space.
+#
+# Copyright (c) 2023 Red Hat, Inc.
+#
+# Author:
+#  Ani Sinha 
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+from avocado_qemu import QemuSystemTest
+import signal
+import time
+
+class MemAddrCheck(QemuSystemTest):
+# first, lets test some 32-bit processors.
+# for all 32-bit cases, pci64_hole_size is 0.
+def test_phybits_low_pse36(self):
+"""
+:avocado: tags=machine:q35
+:avocado: tags=arch:x86_64
+
+With pse36 feature ON, a processor has 36 bits of addressing. So it can
+access up to a maximum of 64GiB of memory. Memory hotplug region begins
+at 4 GiB boundary when "above_4g_mem_size" is 0 (this would be true 
when
+we have 0.5 GiB of VM memory, see pc_q35_init()). This means total
+hotpluggable memory size is 60 GiB. Per slot, we reserve 1 GiB of 
memory
+for dimm alignment for all newer machines (see enforce_aligned_dimm
+property for pc machines and pc_get_device_memory_range()). That leaves
+total hotpluggable actual memory size of 59 GiB. If the VM is started
+with 0.5 GiB of memory, maxmem should be set to a maximum value of
+59.5 GiB to ensure that the processor can address all memory directly.
+Note that 64-bit pci hole size is 0 in this case. If maxmem is set to
+59.6G, QEMU should fail to start with a message "phy-bits are too low".
+  

[PATCH v4] tests/avocado: add test to exercize processor address space memory bound checks

[Ani Sinha]

QEMU has validations to make sure that a VM is not started with more memory
(static and hotpluggable memory) than what the guest processor can address
directly with its addressing bits. This change adds a test to make sure QEMU
fails to start with a specific error message when an attempt is made to
start a VM with more memory than what the processor can directly address.
The test also checks for passing cases when the address space of the processor
is capable of addressing all memory. Boundary cases are tested.

CC: imamm...@redhat.com
CC: David Hildenbrand 
Signed-off-by: Ani Sinha 
---
 tests/avocado/mem-addr-space-check.py | 338 ++
 1 file changed, 338 insertions(+)
 create mode 100644 tests/avocado/mem-addr-space-check.py

Changelog:
v4: incorporated changes related to suggestions from David.
v3: added pae tests as well.
v2: added 64-bit tests. Added cxl tests.

diff --git a/tests/avocado/mem-addr-space-check.py 
b/tests/avocado/mem-addr-space-check.py
new file mode 100644
index 00..54d1a8adb1
--- /dev/null
+++ b/tests/avocado/mem-addr-space-check.py
@@ -0,0 +1,338 @@
+# Check for crash when using memory beyond the available guest processor
+# address space.
+#
+# Copyright (c) 2023 Red Hat, Inc.
+#
+# Author:
+#  Ani Sinha 
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+from avocado_qemu import QemuSystemTest
+import signal
+
+class MemAddrCheck(QemuSystemTest):
+# first, lets test some 32-bit processors.
+# for all 32-bit cases, pci64_hole_size is 0.
+def test_phybits_low_pse36(self):
+"""
+:avocado: tags=machine:q35
+:avocado: tags=arch:x86_64
+
+With pse36 feature ON, a processor has 36 bits of addressing. So it can
+access up to a maximum of 64GiB of memory. Memory hotplug region begins
+at 4 GiB boundary when "above_4g_mem_size" is 0 (this would be true 
when
+we have 0.5 GiB of VM memory, see pc_q35_init()). This means total
+hotpluggable memory size is 60 GiB. Per slot, we reserve 1 GiB of 
memory
+for dimm alignment for all newer machines (see enforce_aligned_dimm
+property for pc machines and pc_get_device_memory_range()). That leaves
+total hotpluggable actual memory size of 59 GiB. If the VM is started
+with 0.5 GiB of memory, maxmem should be set to a maximum value of
+59.5 GiB to ensure that the processor can address all memory directly.
+Note that 64-bit pci hole size is 0 in this case. If maxmem is set to
+59.6G, QEMU should fail to start with a message "phy-bits are too low".
+If maxmem is set to 59.5G with all other QEMU parameters identical, 
QEMU
+should start fine.
+"""
+self.vm.add_args('-S', '-machine', 'q35', '-m',
+ '512,slots=1,maxmem=59.6G',
+ '-cpu', 'pentium,pse36=on', '-display', 'none',
+ '-object', 'memory-backend-ram,id=mem1,size=1G',
+ '-device', 'pc-dimm,id=vm0,memdev=mem1')
+self.vm.set_qmp_monitor(enabled=False)
+self.vm.launch()
+self.vm.wait()
+self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 1")
+self.assertRegex(self.vm.get_log(), r'phys-bits too low')
+
+def test_phybits_low_pae(self):
+"""
+:avocado: tags=machine:q35
+:avocado: tags=arch:x86_64
+
+With pae feature ON, a processor has 36 bits of addressing. So it can
+access up to a maximum of 64GiB of memory. Rest is the same as the case
+with pse36 above.
+"""
+self.vm.add_args('-S', '-machine', 'q35', '-m',
+ '512,slots=1,maxmem=59.6G',
+ '-cpu', 'pentium,pae=on', '-display', 'none',
+ '-object', 'memory-backend-ram,id=mem1,size=1G',
+ '-device', 'pc-dimm,id=vm0,memdev=mem1')
+self.vm.set_qmp_monitor(enabled=False)
+self.vm.launch()
+self.vm.wait()
+self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 1")
+self.assertRegex(self.vm.get_log(), r'phys-bits too low')
+
+def test_phybits_ok_pentium_pse36(self):
+"""
+:avoca

[PATCH] tests/acpi/bios-tables-test: do not write new blobs unless there are changes

[Ani Sinha]

When dumping table blobs using rebuild-expected-aml.sh, table blobs from all
test variants are dumped regardless of whether there are any actual changes to
the tables or not. This creates lot of new files for various test variants that
are not part of the git repository. This is because we do not check in all table
blobs for all test variants into the repository. Only those blobs for those
variants that are different from the generic test-variant agnostic blob are
checked in.

This change makes the test smarter by checking if at all there are any changes
in the tables from the checked-in gold master blobs. If there are no changes,
no new files are written for test variants. However, existing files continue
to be overwritten regardless of whether there are changes. Hence, new files
will be generated only when there are actual changes in the tables.
This would make analyzing changes to tables less confusing and there would
be no need to clean useless untracked files when there are no table changes.

CC: peter.mayd...@linaro.org
Signed-off-by: Ani Sinha 
---
 tests/qtest/bios-tables-test.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index 9f4bc15aab..743b509e93 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -109,6 +109,7 @@ static const char *iasl;
 #endif
 
 static int verbosity_level;
+static GArray *load_expected_aml(test_data *data);
 
 static bool compare_signature(const AcpiSdtTable *sdt, const char *signature)
 {
@@ -241,21 +242,32 @@ static void test_acpi_fadt_table(test_data *data)
 
 static void dump_aml_files(test_data *data, bool rebuild)
 {
-AcpiSdtTable *sdt;
+AcpiSdtTable *sdt, *exp_sdt;
 GError *error = NULL;
 gchar *aml_file = NULL;
+test_data exp_data = {};
 gint fd;
 ssize_t ret;
 int i;
 
+exp_data.tables = load_expected_aml(data);
 for (i = 0; i < data->tables->len; ++i) {
 const char *ext = data->variant ? data->variant : "";
 sdt = _array_index(data->tables, AcpiSdtTable, i);
+exp_sdt = _array_index(exp_data.tables, AcpiSdtTable, i);
 g_assert(sdt->aml);
+g_assert(exp_sdt->aml);
 
 if (rebuild) {
 aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, data->machine,
sdt->aml, ext);
+if (!g_file_test(aml_file, G_FILE_TEST_EXISTS) &&
+sdt->aml_len == exp_sdt->aml_len &&
+!memcmp(sdt->aml, exp_sdt->aml, sdt->aml_len)) {
+/* identical tables, no need to write new files */
+g_free(aml_file);
+continue;
+}
 fd = g_open(aml_file, O_WRONLY|O_TRUNC|O_CREAT,
 S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH);
 if (fd < 0) {
-- 
2.42.0