From: Tao Cui <cui.tao@linux.dev>
To: Bibo Mao <maobibo@loongson.cn>, qemu-devel@nongnu.org
Cc: cui.tao@linux.dev, "Song Gao" <gaosong@loongson.cn>,
"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@mailo.com>,
"Tao Cui" <cuitao@kylinos.cn>
Subject: Re: [PATCH v2 2/3] target/loongarch: migrate pv_features in the vCPU VMState
Date: Fri, 10 Jul 2026 16:22:46 +0800 [thread overview]
Message-ID: <eb2d84d8-95bb-49ce-9671-153160fc529e@linux.dev> (raw)
In-Reply-To: <d68d39b3-e197-af10-f926-ba76c481c7eb@loongson.cn>
在 2026/7/10 11:15, Bibo Mao 写道:
>
>
> On 2026/7/10 上午11:02, Bibo Mao wrote:
>>
>>
>> On 2026/7/10 上午8:50, Tao Cui wrote:
>>> From: Tao Cui <cuitao@kylinos.cn>
>>>
>>> pv_features holds the value of pseudo-register CPUCFG_KVM_FEATURE and is now
>>> pushed per vCPU. Add it to the vCPU VMState as a subsection (sent when
>>> non-zero) so it travels with the vCPU across migration between host kernel
>>> versions.
>>>
>>> Signed-off-by: Tao Cui <cuitao@kylinos.cn>
>>> ---
>>> target/loongarch/machine.c | 19 +++++++++++++++++++
>>> 1 file changed, 19 insertions(+)
>>>
>>> diff --git a/target/loongarch/machine.c b/target/loongarch/machine.c
>>> index 931a5ca5ba..b8819bd44d 100644
>>> --- a/target/loongarch/machine.c
>>> +++ b/target/loongarch/machine.c
>>> @@ -65,6 +65,24 @@ static const VMStateDescription vmstate_msgint = {
>>> },
>>> };
>>> +static bool pv_features_needed(void *opaque)
>>> +{
>>> + LoongArchCPU *cpu = opaque;
>>> +
>>> + return cpu->env.pv_features != 0;
>> I think cpu->no_pv_feature should be check here. For QEMU 11.1 pv_feature is not supported for migration, for later version it supports, something like this:
>> return !cpu->no_pv_feature;
> For successful migration, env.pv_features from source host should be subset of destination host, there should be such checking also.
>
Agreed on both points.
1. I'll change .needed to `return !cpu->no_pv_feature` so the subsection
is gated by machine version. Since it references no_pv_feature (added
in the compat patch), I'll reorder so compat comes before vmstate.
2. For the subset check, I'll add a .post_load that calls
kvm_feature_supported() for each PV feature to build the destination's
supported mask, and rejects migration if the migrated pv_features has
bits outside it. Does this look right?
Thanks,
Tao
>>
>> Regards
>> Bibo Mao
>>> +}
>>> +
>>> +static const VMStateDescription vmstate_pv_features = {
>>> + .name = "cpu/pv_features",
>>> + .version_id = 1,
>>> + .minimum_version_id = 1,
>>> + .needed = pv_features_needed,
>>> + .fields = (const VMStateField[]) {
>>> + VMSTATE_UINT32(env.pv_features, LoongArchCPU),
>>> + VMSTATE_END_OF_LIST()
>>> + },
>>> +};
>>> +
>>> static const VMStateDescription vmstate_lsxh_reg = {
>>> .name = "lsxh_reg",
>>> .version_id = 1,
>>> @@ -289,6 +307,7 @@ const VMStateDescription vmstate_loongarch_cpu = {
>>> &vmstate_lbt,
>>> &vmstate_msgint,
>>> &vmstate_pmu,
>>> + &vmstate_pv_features,
>>> NULL
>>> }
>>> };
>>>
>>
>
next prev parent reply other threads:[~2026-07-10 8:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 0:50 [PATCH v2 0/3] target/loongarch: advertise pv features per vCPU Tao Cui
2026-07-10 0:50 ` [PATCH v2 1/3] target/loongarch/kvm: " Tao Cui
2026-07-10 2:58 ` Bibo Mao
2026-07-10 8:09 ` Tao Cui
2026-07-10 8:44 ` Bibo Mao
2026-07-10 12:46 ` Tao Cui
2026-07-13 1:00 ` Bibo Mao
2026-07-10 0:50 ` [PATCH v2 2/3] target/loongarch: migrate pv_features in the vCPU VMState Tao Cui
2026-07-10 3:02 ` Bibo Mao
2026-07-10 3:15 ` Bibo Mao
2026-07-10 8:22 ` Tao Cui [this message]
2026-07-10 0:50 ` [PATCH v2 3/3] target/loongarch: add no_pv_feature compat flag Tao Cui
2026-07-10 3:09 ` Bibo Mao
2026-07-10 8:28 ` Tao Cui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eb2d84d8-95bb-49ce-9671-153160fc529e@linux.dev \
--to=cui.tao@linux.dev \
--cc=cuitao@kylinos.cn \
--cc=gaosong@loongson.cn \
--cc=jiaxun.yang@flygoat.com \
--cc=maobibo@loongson.cn \
--cc=pbonzini@redhat.com \
--cc=philmd@mailo.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.