All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Wei-Lin Chang <r09922117@csie.ntu.edu.tw>
Cc: oliver.upton@linux.dev, james.morse@arm.com,
	suzuki.poulose@arm.com, yuzenghui@huawei.com,
	catalin.marinas@arm.com, will@kernel.org,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org, sauravsc@amazon.com,
	eric.auger@redhat.com
Subject: Re: [PATCH 1/1] KVM: arm64: Affinity level 3 support
Date: Tue, 27 Feb 2024 08:10:48 +0000	[thread overview]
Message-ID: <874jdu9vjr.wl-maz@kernel.org> (raw)
In-Reply-To: <20240227022708.795214-1-r09922117@csie.ntu.edu.tw>

On Tue, 27 Feb 2024 02:27:08 +0000,
Wei-Lin Chang <r09922117@csie.ntu.edu.tw> wrote:
> 
> On Sun, 25 Feb 2024 11:19:05 +0000,
> Marc Zyngier <maz@kernel.org> wrote:

[...]

> > I can see multiple problems with this:
> > 
> > - this is the host state, which shouldn't necessarily represent the
> >   guest state. It should be possible to restore a VM that have a
> >   different A3V value and still have the same guarantees.  There is
> >   however a small nit around ICV_CTLR_EL1.A3V, which would require
> >   trapping to emulate the A3V bit.
> > 
> > - this assumes GICv3, which is definitely not universal (we support
> >   GICv2, for which no such restriction actually exists).
> > 
> > Finally, I don't see VM save/restore being addressed here, and I
> > suspect it hasn't been looked at.
> > 
> > Overall, this patch does too many things, and it should be split in
> > discrete changes. I also want to see an actual justification for Aff3
> > support. And if we introduce it, it must be fully virtualised
> > (independent of the A3V support on the host).
> 
> Hi Marc,
> 
> Really appreciate for the feedback. I think I understand most of your
> comments and agree with them. It appears that I don't fully understand
> the changes that I am doing with this. Thanks for explaining.

I hope this doesn't deter you from working on this feature. I'll
happily answer questions and discuss the above points.

Thanks,

	M.

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

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Wei-Lin Chang <r09922117@csie.ntu.edu.tw>
Cc: oliver.upton@linux.dev, james.morse@arm.com,
	suzuki.poulose@arm.com, yuzenghui@huawei.com,
	catalin.marinas@arm.com, will@kernel.org,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org, sauravsc@amazon.com,
	eric.auger@redhat.com
Subject: Re: [PATCH 1/1] KVM: arm64: Affinity level 3 support
Date: Tue, 27 Feb 2024 08:10:48 +0000	[thread overview]
Message-ID: <874jdu9vjr.wl-maz@kernel.org> (raw)
In-Reply-To: <20240227022708.795214-1-r09922117@csie.ntu.edu.tw>

On Tue, 27 Feb 2024 02:27:08 +0000,
Wei-Lin Chang <r09922117@csie.ntu.edu.tw> wrote:
> 
> On Sun, 25 Feb 2024 11:19:05 +0000,
> Marc Zyngier <maz@kernel.org> wrote:

[...]

> > I can see multiple problems with this:
> > 
> > - this is the host state, which shouldn't necessarily represent the
> >   guest state. It should be possible to restore a VM that have a
> >   different A3V value and still have the same guarantees.  There is
> >   however a small nit around ICV_CTLR_EL1.A3V, which would require
> >   trapping to emulate the A3V bit.
> > 
> > - this assumes GICv3, which is definitely not universal (we support
> >   GICv2, for which no such restriction actually exists).
> > 
> > Finally, I don't see VM save/restore being addressed here, and I
> > suspect it hasn't been looked at.
> > 
> > Overall, this patch does too many things, and it should be split in
> > discrete changes. I also want to see an actual justification for Aff3
> > support. And if we introduce it, it must be fully virtualised
> > (independent of the A3V support on the host).
> 
> Hi Marc,
> 
> Really appreciate for the feedback. I think I understand most of your
> comments and agree with them. It appears that I don't fully understand
> the changes that I am doing with this. Thanks for explaining.

I hope this doesn't deter you from working on this feature. I'll
happily answer questions and discuss the above points.

Thanks,

	M.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-02-27  8:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-25  9:02 [PATCH 0/1] KVM: arm64: Affinity level 3 support Wei-Lin Chang
2024-02-25  9:02 ` Wei-Lin Chang
2024-02-25  9:02 ` [PATCH 1/1] " Wei-Lin Chang
2024-02-25  9:02   ` Wei-Lin Chang
2024-02-25 11:19   ` Marc Zyngier
2024-02-25 11:19     ` Marc Zyngier
2024-02-27  2:27     ` Wei-Lin Chang
2024-02-27  2:27       ` Wei-Lin Chang
2024-02-27  8:10       ` Marc Zyngier [this message]
2024-02-27  8:10         ` Marc Zyngier

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=874jdu9vjr.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=eric.auger@redhat.com \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=r09922117@csie.ntu.edu.tw \
    --cc=sauravsc@amazon.com \
    --cc=suzuki.poulose@arm.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 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.