From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: eric.auger@redhat.com, Cornelia Huck <cohuck@redhat.com>,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
"kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"will@kernel.org" <will@kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
yuzenghui <yuzenghui@huawei.com>,
"Wangzhou (B)" <wangzhou1@hisilicon.com>,
jiangkunkun <jiangkunkun@huawei.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Anthony Jebson <anthony.jebson@huawei.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Linuxarm <linuxarm@huawei.com>
Subject: Re: [RFC PATCH 0/6] KVM: arm64: Errata management for VM Live migration
Date: Fri, 18 Oct 2024 11:52:37 -0700 [thread overview]
Message-ID: <ZxKudSBRKfM1OkMK@linux.dev> (raw)
In-Reply-To: <86frot4kki.wl-maz@kernel.org>
On Fri, Oct 18, 2024 at 02:17:17PM +0100, Marc Zyngier wrote:
> On Thu, 17 Oct 2024 18:16:04 +0100,
> Eric Auger <eric.auger@redhat.com> wrote:
> >
> > Hi Shameer,
> >
> > On 10/17/24 17:49, Cornelia Huck wrote:
>
> > > Speaking of QEMU: Do you maybe already have some prototype code that
> > > tries to do something with the setup here? (I don't think QEMU currently
> > > mucks around with MIDR and friends when running with KVM; I wonder what
> > > it should provide to the guest and if it should care to set something as
> > > a base level that gives guests not using the hypercall a chance to work
> > > properly.)
> > >
> > As discussed during the KVM forum we are working on a qemu integration
> > for writable ID regs. The first goal is to be able to specialize the
> > host passthrough model (custom host model). Maybe this will trigger more
> > discussions on named models too. This is complementary to the
> > MIDR/REVIDR problematic and I hope we will be able to consolidate our
> > works at some point.
>
> Complementary to the MIDR/REVIDR work, I would also like to make
> MIDR/REVIDR writable when this scheme is available. Ideally reporting
> a synthetic CPU description (with MIDR_EL1.Implementer returning 0,
> and the rest being VMM-specific, but with a clear definition for the
> IMPDEF fields so that we can version the ABI).
When the VMM is using the hypercall mechanism to describe
implementations, 100% agree.
> Thoughts?
I think we should go a step further and allow userspace full control of
known fields in these registers, even for a nonzero Implementer code.
We're already affording userspace full control of what implementation(s)
the guest sees anyway via hypercalls, so there isn't much left for KVM
to enforce.
Ignoring errata, it'd let folks spoof an old implementation on newer
hardware for testing, especially when dealing w/ older software.
--
Thanks,
Oliver
next prev parent reply other threads:[~2024-10-18 18:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-11 7:50 [RFC PATCH 0/6] KVM: arm64: Errata management for VM Live migration Shameer Kolothum
2024-10-11 7:50 ` [RFC PATCH 1/6] arm64: Modify callback matches() fn to take a target info Shameer Kolothum
2024-10-11 7:50 ` [RFC PATCH 2/6] KVM: arm64: Add support for VMM to set migration target Shameer Kolothum
2024-10-11 7:50 ` [RFC PATCH 3/6] KVM: arm64: Introduce a helper to retrieve errata Shameer Kolothum
2024-10-11 7:50 ` [RFC PATCH 4/6] KVM: arm64: Add hypercall support for retrieving migration errata bitmap Shameer Kolothum
2024-10-11 7:50 ` [RFC PATCH 5/6] arm64: Use hypercall to check for any migration related errata Shameer Kolothum
2024-10-11 7:50 ` [RFC PATCH 6/6] arm64: errata: Set migration_safe_cap for MIDR based errata Shameer Kolothum
2024-10-11 10:37 ` [RFC PATCH 0/6] KVM: arm64: Errata management for VM Live migration Marc Zyngier
2024-10-11 10:57 ` Shameerali Kolothum Thodi
2024-10-11 11:43 ` Marc Zyngier
2024-10-11 15:11 ` Oliver Upton
2024-10-11 15:51 ` Shameerali Kolothum Thodi
2024-10-17 15:49 ` Cornelia Huck
2024-10-17 17:16 ` Eric Auger
2024-10-18 8:33 ` Shameerali Kolothum Thodi
2024-10-18 12:28 ` Cornelia Huck
2024-10-18 13:17 ` Marc Zyngier
2024-10-18 18:52 ` Oliver Upton [this message]
2024-10-22 10:58 ` Cornelia Huck
2024-10-22 12:52 ` Marc Zyngier
2024-10-11 13:17 ` Cornelia Huck
2024-10-11 13:24 ` Shameerali Kolothum Thodi
2024-10-11 14:14 ` Cornelia Huck
2024-10-11 17:07 ` Oliver Upton
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=ZxKudSBRKfM1OkMK@linux.dev \
--to=oliver.upton@linux.dev \
--cc=anthony.jebson@huawei.com \
--cc=catalin.marinas@arm.com \
--cc=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=jiangkunkun@huawei.com \
--cc=jonathan.cameron@huawei.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linuxarm@huawei.com \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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).