linux-kernel - Re: [PATCH v2 0/2] KVM: arm64: Support for Arm v8.8 memcpy instructions in KVM guests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <86sf6tnk9h.wl-maz@kernel.org>
Date:   Mon, 02 Oct 2023 15:58:50 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Kristina Martsenko <kristina.martsenko@....com>
Cc:     Oliver Upton <oliver.upton@...ux.dev>, kvmarm@...ts.linux.dev,
        linux-arm-kernel@...ts.infradead.org,
        James Morse <james.morse@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Zenghui Yu <yuzenghui@...wei.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Vladimir Murzin <vladimir.murzin@....com>,
        Colton Lewis <coltonlewis@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/2] KVM: arm64: Support for Arm v8.8 memcpy instructions in KVM guests

On Fri, 29 Sep 2023 15:51:32 +0100,
Kristina Martsenko <kristina.martsenko@....com> wrote:
> 
> On 29/09/2023 10:29, Marc Zyngier wrote:
> > On Thu, 28 Sep 2023 17:55:39 +0100,
> > Kristina Martsenko <kristina.martsenko@....com> wrote:
> >>
> >> On 27/09/2023 07:00, Oliver Upton wrote:
> >>>
> >>> On Fri, Sep 22, 2023 at 12:25:06PM +0100, Kristina Martsenko wrote:
> >>>> Hi,
> >>>>
> >>>> This is v2 of the series to allow using the new Arm memory copy instructions
> >>>> in KVM guests. See v1 for more information [1].
> >>>
> >>>
> >>> Thanks for sending out the series. I've been thinking about what the
> >>> architecture says for MOPS, and I wonder if what's currently in the
> >>> Arm ARM is clear enough for EL1 software to be written robustly.
> >>>
> >>> While HCRX_EL2.MCE2 allows the hypervisor to intervene on MOPS
> >>> exceptions from EL1, there's no such control for EL0. So when vCPU
> >>> migration occurs EL1 could get an unexpected MOPS exception, even for a
> >>> process that was pinned to a single (virtual) CPU implementation.
> >>>
> >>> Additionally, the wording of I_NXHPS seems to suggest that EL2 handling
> >>> of MOPS exceptions is only expected in certain circumstances where EL1 is
> >>> incapable of handling an exception. Is the unwritten expectation then
> >>> that EL1 software should tolerate 'unexpected' MOPS exceptions from EL1
> >>> and EL0, even if EL1 did not migrate the PE context?
> >>>
> >>> Perhaps I'm being pedantic, but I'd really like for there to be some
> >>> documentation that suggests MOPS exceptions can happen due to context
> >>> migration done by a higher EL as that is the only option in the context
> >>> of virtualization.
> >>
> >> That's a good point. This shouldn't affect Linux guests as Linux is
> >> always able to handle a MOPS exception coming from EL0. But it would
> >> affect any non-Linux guest that pins all its EL0 tasks and doesn't
> >> implement a handler. It's not clear to me what the expectation for
> >> guests is, I'll ask the architects to clarify and get back to you.
> > 
> > My understanding is that MCE2 should always be set if the hypervisor
> > can migrate vcpus across implementations behind EL1's back, and that
> > in this context, EL1 never sees such an exception.
> 
> Notice that MCE2 only traps exceptions from EL1, not from EL0.
> Exceptions from EL0 always go to EL1. Even if MCE2 is always set, EL1
> will see the exception when the hypervisor migrates the vcpu while the
> vcpu is executing a MOPS instruction in EL0.

Ah, good point. I stand corrected.

	M.

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