On 12/18/24 05:51, Peter Maydell wrote:
On Tue, 17 Dec 2024 at 21:08, Pierrick Bouvier
<pierrick.bouvier@linaro.org> wrote:
On 12/17/24 02:38, Peter Maydell wrote:
On Tue, 17 Dec 2024 at 07:40, Alex Bennée <alex.bennee@linaro.org> wrote:
Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:
I think this is still a change worth to do, because people can get a
100% speedup with this simple change, and it's a better default than
the previous value.
In more, in case of this migration scenario, QEMU will immediately
abort upon accessing memory through a pointer.
I'm not sure about what would be the best way to make this change as
smooth as possible for QEMU users.
Surely we can only honour and apply the new default to -cpu max?
With all my respect, I think the current default is wrong, and it would
be sad to keep it when people don't precise cpu max, or for other cpus
enabling pointer authentication.
In all our conversations, there seems to be a focus on choosing the
"fastest" emulation solution that satisfies the guest (behaviour wise).
And, for a reason I ignore, pointer authentication escaped this rule.
I think the reason is just that we didn't understand how much
of a performance hit the architected algorithm for pointer auth
is in emulation. So we took our default approach of "implement
what the architecture says". Then later when we realised how
bad the effect was we added in a faster impdef authentication
algorithm, but we put it in as not-the-default because of our
usual bias towards "don't change existing behaviour".
I understand the reason behind the current choice.
For my personal knowledge, is there a QEMU policy for "breaking changes"?
I understand the concern regarding retro compatibility, but it would be
better to ask politely (with an error message) to people to restart
their virtual machines when they try to migrate, instead of being stuck
with a slow default forever.
In more, we are talking of a tcg scenario, for which I'm not sure people
use migration feature (save/restore) heavily, but I may be wrong on this.
Between the risk of breaking migration (with a polite error message),
and having a default that is 100% faster, I think it would be better to
favor the second one. If it would be a 5% speedup, I would not argue,
but slowing down execution with a factor of 2 is really a lot.
The point here about "breaking migration" is that we have a strong
set of rules:
* if you say "-machine virt-8.2" you get "exactly the behaviour
that the 'virt' machine type had in QEMU 8.2, and it is
migration compatible
* we can make changes that are not migration compatible only if we
ensure that they are not applied to older versioned machine types
(or if they're to devices that are only used in machines which
do not have versioned machine types at all)
* TCG '-cpu max' is a special case: it is not a fixed thing, and so
it may acquire new non-migration-compatible changes between versions
(and so if you care about VM migration compat you don't use it);
but this is not true of the named CPU types that match real
hardware implementations
This patch as it stands will not preserve the migration
guarantees that we make. So we need to fix it by either:
* only making the default change on -cpu max
* making the default change be bound to versioned types
I'm not sure to follow you on this second approach. The cpu is not versioned,
and if
someone use -machine virt (non versioned), is there a guarantee it should stay
possible to
migrate?
In other words, can we break the migration with "-machine virt -cpu model"?