All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>, Mark Brown <broonie@kernel.org>,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	will@kernel.org, qperret@google.com, seanjc@google.com,
	alexandru.elisei@arm.com, catalin.marinas@arm.com,
	philmd@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com,
	mark.rutland@arm.com, joey.gouly@arm.com, rananta@google.com,
	yuzenghui@huawei.com
Subject: Re: [PATCH v1 0/7] KVM: arm64: Fix handling of host fpsimd/sve state in protected mode
Date: Mon, 20 May 2024 13:53:20 -0700	[thread overview]
Message-ID: <Zku4QF1VtKJqhnGg@linux.dev> (raw)
In-Reply-To: <CA+EHjTyvRU13+LL=vyRTOykj5pbycVPce7dstXK1rpTF98jKFA@mail.gmail.com>

Hey Fuad,

On Mon, May 20, 2024 at 06:57:36PM +0100, Fuad Tabba wrote:
> Hi Oliver,
> 
> On Mon, May 20, 2024 at 6:37 PM Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > On Mon, May 20, 2024 at 09:11:13AM +0100, Marc Zyngier wrote:
> > > On Mon, 20 May 2024 08:35:47 +0100, Fuad Tabba <tabba@google.com> wrote:
> > > > The reason for that is that in pKVM we want to avoid leaking any
> > > > information about protected VM activity to the host, including whether
> > > > the VM might have performed fpsimd/sve operations. Therefore, we need
> > > > to ensure that the host SVE state looks the same after a protected
> > > > guest has run as it did before a protected guest has run.
> >
> > Wouldn't it be equally valid to just zero the state that will not be
> > preserved regardless of whether or not the guest used fpsimd/sve?
> 
> Yes it would. I think I did mention that as an option.

Apologies, I probably missed it earlier on then.

> However, that would need to be done at every protected guest exit, whereas
> restoring the host SVE state only needs to be done if the guest has used
> fpsimd/sve.

Indeed, what I was _hoping_ is that implementations do a decent job of
handling a zeroing idiom for SVE and avoid needing to fetch a bunch of
state out of memory.

> I think the code for the latter (i.e., zeroing out), would be simpler.
> I'm happy to do it that way if you and the others think it's better.

Right, I have no fundamental objections to fully managing the host SVE
state in EL2. Strong preference for something simple + correct in the
interim. Anyway, thanks for suffering through my whining and hopefully
we can land a fix soon :)

-- 
Best,
Oliver

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>, Mark Brown <broonie@kernel.org>,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	will@kernel.org, qperret@google.com, seanjc@google.com,
	alexandru.elisei@arm.com, catalin.marinas@arm.com,
	philmd@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com,
	mark.rutland@arm.com, joey.gouly@arm.com, rananta@google.com,
	yuzenghui@huawei.com
Subject: Re: [PATCH v1 0/7] KVM: arm64: Fix handling of host fpsimd/sve state in protected mode
Date: Mon, 20 May 2024 13:53:20 -0700	[thread overview]
Message-ID: <Zku4QF1VtKJqhnGg@linux.dev> (raw)
In-Reply-To: <CA+EHjTyvRU13+LL=vyRTOykj5pbycVPce7dstXK1rpTF98jKFA@mail.gmail.com>

Hey Fuad,

On Mon, May 20, 2024 at 06:57:36PM +0100, Fuad Tabba wrote:
> Hi Oliver,
> 
> On Mon, May 20, 2024 at 6:37 PM Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > On Mon, May 20, 2024 at 09:11:13AM +0100, Marc Zyngier wrote:
> > > On Mon, 20 May 2024 08:35:47 +0100, Fuad Tabba <tabba@google.com> wrote:
> > > > The reason for that is that in pKVM we want to avoid leaking any
> > > > information about protected VM activity to the host, including whether
> > > > the VM might have performed fpsimd/sve operations. Therefore, we need
> > > > to ensure that the host SVE state looks the same after a protected
> > > > guest has run as it did before a protected guest has run.
> >
> > Wouldn't it be equally valid to just zero the state that will not be
> > preserved regardless of whether or not the guest used fpsimd/sve?
> 
> Yes it would. I think I did mention that as an option.

Apologies, I probably missed it earlier on then.

> However, that would need to be done at every protected guest exit, whereas
> restoring the host SVE state only needs to be done if the guest has used
> fpsimd/sve.

Indeed, what I was _hoping_ is that implementations do a decent job of
handling a zeroing idiom for SVE and avoid needing to fetch a bunch of
state out of memory.

> I think the code for the latter (i.e., zeroing out), would be simpler.
> I'm happy to do it that way if you and the others think it's better.

Right, I have no fundamental objections to fully managing the host SVE
state in EL2. Strong preference for something simple + correct in the
interim. Anyway, thanks for suffering through my whining and hopefully
we can land a fix soon :)

-- 
Best,
Oliver

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

  reply	other threads:[~2024-05-20 20:53 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-17 13:18 [PATCH v1 0/7] KVM: arm64: Fix handling of host fpsimd/sve state in protected mode Fuad Tabba
2024-05-17 13:18 ` Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 1/7] KVM: arm64: Reintroduce __sve_save_state Fuad Tabba
2024-05-17 13:18   ` Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 2/7] KVM: arm64: Specialize deactivate fpsimd/sve traps on guest trap Fuad Tabba
2024-05-17 13:18   ` Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 3/7] KVM: arm64: Specialize handling of host fpsimd state on trap Fuad Tabba
2024-05-17 13:18   ` Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 4/7] KVM: arm64: Store the maximum sve vector length at hyp Fuad Tabba
2024-05-17 13:18   ` Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 5/7] KVM: arm64: Allocate memory at hyp for host sve state in pKVM Fuad Tabba
2024-05-17 13:18   ` Fuad Tabba
2024-05-17 13:18 ` [PATCH v1 6/7] KVM: arm64: Eagerly restore host fpsimd/sve " Fuad Tabba
2024-05-17 13:18   ` Fuad Tabba
2024-05-17 17:09   ` Oliver Upton
2024-05-17 17:09     ` Oliver Upton
2024-05-20  7:37     ` Fuad Tabba
2024-05-20  7:37       ` Fuad Tabba
2024-05-20  8:05       ` Marc Zyngier
2024-05-20  8:05         ` Marc Zyngier
2024-05-20  8:53         ` Fuad Tabba
2024-05-20  8:53           ` Fuad Tabba
2024-05-20 17:08         ` Oliver Upton
2024-05-20 17:08           ` Oliver Upton
2024-05-17 13:18 ` [PATCH v1 7/7] KVM: arm64: Consolidate initializing the host data's fpsimd_state/sve " Fuad Tabba
2024-05-17 13:18   ` Fuad Tabba
2024-05-17 17:30 ` [PATCH v1 0/7] KVM: arm64: Fix handling of host fpsimd/sve state in protected mode Oliver Upton
2024-05-17 17:30   ` Oliver Upton
2024-05-17 18:19   ` Mark Brown
2024-05-17 18:19     ` Mark Brown
2024-05-20  7:35     ` Fuad Tabba
2024-05-20  7:35       ` Fuad Tabba
2024-05-20  8:11       ` Marc Zyngier
2024-05-20  8:11         ` Marc Zyngier
2024-05-20 17:37         ` Oliver Upton
2024-05-20 17:37           ` Oliver Upton
2024-05-20 17:53           ` Mark Brown
2024-05-20 17:53             ` Mark Brown
2024-05-20 17:59             ` Fuad Tabba
2024-05-20 17:59               ` Fuad Tabba
2024-05-20 17:57           ` Fuad Tabba
2024-05-20 17:57             ` Fuad Tabba
2024-05-20 20:53             ` Oliver Upton [this message]
2024-05-20 20:53               ` Oliver Upton
2024-05-21 12:27               ` Fuad Tabba
2024-05-21 12:27                 ` Fuad Tabba

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=Zku4QF1VtKJqhnGg@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=alexandru.elisei@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=philmd@linaro.org \
    --cc=qperret@google.com \
    --cc=rananta@google.com \
    --cc=seanjc@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.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.