linux-kernel - Re: [PATCH v5 18/22] KVM: arm64: Support SDEI ioctl commands on VM

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: <Yj1wsIy2rsVczmCJ@google.com>
Date:   Fri, 25 Mar 2022 07:35:12 +0000
From:   Oliver Upton <oupton@...gle.com>
To:     Gavin Shan <gshan@...hat.com>
Cc:     kvmarm@...ts.cs.columbia.edu, maz@...nel.org,
        linux-kernel@...r.kernel.org, eauger@...hat.com,
        shan.gavin@...il.com, Jonathan.Cameron@...wei.com,
        pbonzini@...hat.com, vkuznets@...hat.com, will@...nel.org
Subject: Re: [PATCH v5 18/22] KVM: arm64: Support SDEI ioctl commands on VM

On Fri, Mar 25, 2022 at 02:59:52PM +0800, Gavin Shan wrote:
> > The PSCI implementation is a great example of how KVM has grown its
> > implementation in line with a specification, all the while preserving
> > backwards compatibility.
> > 
> 
> The only information feed by VMM is the exposed events. The events
> can't be registered from guest kernel, and raised from host to guest
> kernel until it's exposed by VMM.

I would suggest assuming that all SDEI events are exposed by default in
KVM. We will not require a VMM change to enable events individually.

> Besides, the exposed events will
> be defined staticly in host/KVM as we discussed on PATCH[02/22]. We
> also discussed to eliminate those ioctl commands. So I think we needn't
> to add KVM_SDEI_CMD_SET_VERSION. Further more, the version is only a
> concern to host itself if the migration can be done through the
> firmware pseudo system registers since the migration compatibility
> is the only concern to VMM (QEMU).

This all needs to work just like the KVM_REG_ARM_PSCI_VERSION version,
I'd recommend taking a look at how we handle that register in KVM.

> Yes, Currently, 0.1/0.2/1.0 versions are supported by PSCI. 0.1 is
> picked until VMM asks for 0.2 and 1.0 explicitly. However, it seems
> QEMU isn't using 1.0 PSCI yet and maybe more patch is needed to enable
> it.

As far as how it interacts with KVM, QEMU looks fine. The name of the
KVM_ARM_VCPU_PSCI_0_2 bit is quite frustrating. It actually implies that
KVM will enable it highest supported PSCI version. If the feature bit is
cleared then you only get PSCIv0.1

However, the DT node that QEMU sets up looks a bit crusty. The
properties for conveying PSCI function IDs were only ever necessary for
PSCIv0.1. The only property of interest any more is 'method', to convey
the SMCCC conduit instruction.

--
Thanks,
Oliver