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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
