linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Zhou Wang <wangzhou1@hisilicon.com>
Cc: <kvmarm@lists.linux.dev>, <linux-arm-kernel@lists.infradead.org>
Subject: Re: Question about heterogeneous VM live migration
Date: Fri, 17 Oct 2025 14:12:07 +0100	[thread overview]
Message-ID: <86wm4twu3c.wl-maz@kernel.org> (raw)
In-Reply-To: <866aca63-1f6b-2109-fa76-6d68cb7c547a@hisilicon.com>

On Thu, 16 Oct 2025 03:00:07 +0100,
Zhou Wang <wangzhou1@hisilicon.com> wrote:
> 
> Hi,
> 
> We are now trying to do heterogeneous VM live migration among HiSilicon ARM
> servers, seems there are problems about disabling a feature in guest.
> 
> For a feature, if we disable it in VM by configure related ID register field,
> we should make it actually been disabled, e.g. configure related control
> register in EL2 or trap EL0/EL1 access to EL2.

This is in general not possible.

> Possible problems:
> 
> 1. Some features can not be disabled actually in EL0/EL1, e.g. FEAT_AFP,
>    FEAT_RPRES, FEAT_CSSC, FEAT_LRCPC3...
> 
>    Disabling it by ID can not avoid a stupid user to directly use it without ID
>    checking, which may bring subtle problem in heterogeneous VM live migration.

Yes. There is no solution to that.

> 2. For some features, it can be trapped, but KVM does not support yet. Not sure
>    if we should support them in future.
> 
>    E.g. If we disable ID of FEAT_HAFT for guest, we need configure
>         HCRX_EL2.TCR2En to 0, so access to TCR2_EL1.HAFT will be trapped.

That's wrong. If you force TCR2EN to 0, none of the TCR2_EL1 controls
will work. For example, you'd lose the POE/PIE controls.

>         For FEAT_PAN3, it instroduces EPAN to SCTLR_EL1,if we disable ID of
> 	FEAT_PAN3, we need make SCTLR_EL1 to trap by setting HFGRTR_EL2.SCTLR_EL1.
> 
>    Seems there are no trap setting in above cases. Just a quick look, maybe I
>    miss something.
> 
> I am not sure if we already consider above problems, any help will be appreciated.

we know about most of these things already. In general, you cannot
hide features that the host has, other than indicating to the guest
that they may not exist. The underlying HW is still there and will act
as expected.

I think you're simply expecting too much from the architecture.

	M.

-- 
Without deviation from the norm, progress is not possible.


  reply	other threads:[~2025-10-17 13:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-16  2:00 Question about heterogeneous VM live migration Zhou Wang
2025-10-17 13:12 ` Marc Zyngier [this message]
2025-10-18  3:17   ` Zhou Wang

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=86wm4twu3c.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=wangzhou1@hisilicon.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).