> On 9. Mar 2026, at 07:55, Mohamed Mediouni <[email protected]> wrote:
>
>
>
>> On 9. Mar 2026, at 07:33, Khushit Shah <[email protected]> wrote:
>>
>>
>>
>>> On 9 Mar 2026, at 11:27 AM, Mohamed Mediouni <[email protected]>
>>> wrote:
>>>
>>> Hi,
>>>
>>> Ugh about this one, but am still convinced that a machine model version
>>> is _the_ right way to deal with this. Will this be backported to Linux
>>> LTSes on the KVM side?
>>>
>>> Or alternatively, what are the odds of having it fit as a CPU flag?
>>> For example -cpu host,x2apic-suppress-eoi-broadcast=on.
>>
>>
>> Hi,
>>
>> Thanks for the review.
>>
>> Regarding the -cpu flag: This doesn't feel right because SEOIB is an
>> accelerator-specific (KVM)
>> value. Tying it to the CPU suggests an architectural feature that wouldn't
>> apply to TCG. What
>> specifically feels off about keeping it as a KVM/Machine property?
> Hello,
>
> The reason why I considered this is that QEMU CPU models are versioned
> separately from the machine
> model, with an understanding that an older CPU model might not work on an
> older KVM.
>
> And with a common CPU model being also a requirement for live migration too.
>
> This has historically been generally leveraged for security mitigations but
> it could be a good fit here.
>
> That could provide a path towards it becoming the default when -cpu host on a
> supported kernel (which doesn’t entail having LM support), while keeping LM
> working and having it stepped in with newer CPU model versions, which people
> will update to more often than new kernels. Maybe the best shape could be a
> no_seoib flag for older predefined CPU models…
s/new kernels/new machine models/g and no_seoib -> no_seoib_fix
>
> My concern is primarily somebody installing a new QEMU, running
> qemu-system-x86_64 -M q35,kernel-irqchip=split [whatever], which would pick
> the latest machine model version and fail straight away if this is rolled as
> part of a new machine model if running on a kernel without the KVM side
> merged in.
>
> And having a custom flag not turned on by default for a long time for this
> comes with the risk that almost nobody will enable it instead of it being
> eventually phased in as the default configuration… Or maybe it matters a lot
> less because kernel-irqchip=split is not the default today anyway?
Which is why I think that an accelerator property isn’t the ideal choice here -
as there’s no -accel kvm-10.2 for example :/ And machine type-gating is more
tied to the QEMU version than CPU model versions which have less of a tie.
But I might be wrong on this one, with machine type being potentially better in
practice - although it’s way too late to define this as part of q35-10.2
baseline as that has been long released, so it could be a slower rollout with
the default tied to a new QEMU release. And an error message to use a newer
kernel in that case if using the newer machine model explicitly or implicitly.
> Thank you,
> -Mohamed
>>
>> Regarding the backports: The KVM kernel side is currently in 6.18 and 6.19.
>> I haven’t yet came
>> around to manually backported it to the older stable releases yet.
>>
>> Thanks,
>> Khushit.
