On Fri, May 30, 2025 at 07:35:38 -0400, Michael S. Tsirkin via Devel wrote:

On Tue, May 13, 2025 at 01:23:38PM +0200, Igor Mammedov wrote:

...

On Thu, 8 May 2025 15:35:23 +0200 Philippe Mathieu-Daudé <philmd@linaro.org> wrote:

...

Since v3: - Addressed Thomas and Zhao review comments - Rename fw_cfg_init_mem_[no]dma() helpers - Remove unused CPU properties - Remove {multi,linux}boot.bin - Added R-b tags

Since v2: - Addressed Mark review comments and added his R-b tags

The versioned 'pc' and 'q35' machines up to 2.12 been marked as deprecated two releases ago, and are older than 6 years, so according to our support policy we can remove them.

This series only includes the 2.6 and 2.7 machines removal, as it is a big enough number of LoC removed. Rest will follow.

CCing libvirt folks

series removes some properties that has been used as compat knobs with 2.6/2.7 machine types that are being removed.

However libvirt might still use them, please check if being removed properties are safe to remove as is | should be deprecated 1st | should be left alone from an immediate user perspective.

Anyone on libvirt side can confirm please?

Sorry, it was a bit of a chore to go through the patches. IIUC the following list is to be reviewed: DEFINE_PROP_BOOL("x-buggy-eim", IntelIOMMUState, buggy_eim, false) DEFINE_PROP_BOOL("x-ignore-backend-features", VirtIOPCIProxy, DEFINE_PROP_BOOL("migrate", PCSpkState, migrate, true), DEFINE_PROP_UINT8("version", IOAPICCommonState, version, IOAPIC_VER_DEF) DEFINE_PROP_BIT64("emergency-write", VirtIOSerial, host_features DEFINE_PROP_BOOL("format_transport_address", VirtIOMMIOProxy, DEFINE_PROP_BOOL("legacy-instance-id", APICCommonState, legacy_instance_id, None of the above are exposed by libvirt to the user nor used by libvirt internally. DEFINE_PROP_BIT("page-per-vq", VirtIOPCIProxy, flags This property is exposed to users for all virtio devices as 'page_per_vq' property:a https://www.libvirt.org/formatdomain.html#virtio-related-options It is an optional property and not formatted to qemu unless explicitly requested by the user. Removing it thus should be fine without the need to change anything in libvirt The rest are CPU properties DEFINE_PROP_BOOL("cpuid-0xb", X86CPU, enable_cpuid_0xb, true), DEFINE_PROP_BOOL("fill-mtrr-mask", X86CPU, fill_mtrr_mask, true), DEFINE_PROP_BOOL("full-cpuid-auto-level", X86CPU, full_cpuid_auto_level, true), which appear in our cpu test data but I'm not 100% sure how they are used. Jirka, can you please comment? Finally there's DEFINE_PROP_BOOL("l3-cache", X86CPU, enable_l3_cache, true), which is exposed to the users via cache mode setting of cpu: https://www.libvirt.org/formatdomain.html#cpu-model-and-topology look for 'cache'. Thus from libvirt's side 'page-per-vq' and 'l3-cache' will likely require deprecation period. The rest except for CPU is fine to remove without anything at least from our PoV. Jirka will hopefully clarify the Cpu property side.

Hi Peter,

Finally there's

DEFINE_PROP_BOOL("l3-cache", X86CPU, enable_l3_cache, true),

which is exposed to the users via cache mode setting of cpu:

https://www.libvirt.org/formatdomain.html#cpu-model-and-topology

look for 'cache'.

I found this link doesn't mention "l3-cache", but it appears in libvirt's src/qemu/qemu_command.c.

Thus from libvirt's side 'page-per-vq' and 'l3-cache' will likely require deprecation period. The rest except for CPU is fine to remove without anything at least from our PoV.

So I understand that the file qemu_command.c contains all the QEMU commands/properties/options used by libvirt, thereby in the future if one wants to remove other properties, he can just check that file, right? Thanks, Zhao