From: Peter Maydell <peter.maydell@linaro.org>
To: Andrew Jones <drjones@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Marc Zyngier <maz@kernel.org>,
xu910121@sina.com, "Dave.Martin" <dave.martin@arm.com>,
kvmarm <kvmarm@lists.cs.columbia.edu>
Subject: Re: Kernel patch cases qemu live migration failed.
Date: Thu, 15 Oct 2020 15:57:02 +0100 [thread overview]
Message-ID: <CAFEAcA-LBmbjp-Teb35f=O-1QtMLd8bAuq5XaCz9URdQZ1jxow@mail.gmail.com> (raw)
In-Reply-To: <20201015144104.ytwzpxjlsgyun3ob@kamzik.brq.redhat.com>
On Thu, 15 Oct 2020 at 15:41, Andrew Jones <drjones@redhat.com> wrote:
> The reporter states neither the source nor destination hardware supports
> SVE. My guess is that what's happening is the reserved ID register
> ID_UNALLOCATED(4,4) was showing up in the KVM_GET_REG_LIST count on
> the old kernel, but the new kernel filters it out. Maybe it is a
> bug to filter it out of the count, as it's a reserved ID register and
> I suppose the other reserved ID registers are still showing up?
Yeah, RES0 ID registers should show up in the list, because otherwise
userspace has to annoyingly special case them when the architecture
eventually defines behaviour for them.
Dave's comment in the kernel commit message
# ID_AA64ZFR0_EL1 is RO-RAZ for MRS/MSR when SVE is disabled for the
# guest, but for compatibility with non-SVE aware KVM implementations
# the register should not be enumerated at all for KVM_GET_REG_LIST
# in this case.
seems wrong to me -- for compatibility the register should remain
present and behave as RAZ/WI if SVE is disabled in the guest,
the same way it was before the kernel/KVM knew about SVE at all.
thanks
-- PMM
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2020-10-15 14:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 4:06 Kernel patch cases qemu live migration failed 张东旭
2020-10-15 11:26 ` Marc Zyngier
2020-10-15 13:35 ` Andrew Jones
2020-10-15 13:52 ` Marc Zyngier
2020-10-15 14:41 ` Andrew Jones
2020-10-15 14:57 ` Peter Maydell [this message]
2020-10-19 9:25 ` Andrew Jones
2020-10-19 11:32 ` Dave Martin
2020-10-19 11:43 ` Peter Maydell
2020-10-19 13:40 ` Andrew Jones
2020-10-19 14:18 ` Peter Maydell
2020-10-19 14:58 ` Dave Martin
2020-10-19 15:23 ` Andrew Jones
2020-10-19 16:36 ` Dave Martin
2020-10-15 13:26 ` Andrew Jones
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='CAFEAcA-LBmbjp-Teb35f=O-1QtMLd8bAuq5XaCz9URdQZ1jxow@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=dave.martin@arm.com \
--cc=drjones@redhat.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=maz@kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=xu910121@sina.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).