On Fri, Mar 03, 2023 at 02:06:07PM +0100, Cornelia Huck wrote: > On Fri, Mar 03 2023, Suzuki K Poulose <suzuki.poulose@xxxxxxx> wrote: > > > On 03/03/2023 12:08, Andrew Jones wrote: > >> On Fri, Mar 03, 2023 at 11:39:05AM +0000, Jean-Philippe Brucker wrote: > >>> On Fri, Mar 03, 2023 at 09:54:47AM +0000, Suzuki K Poulose wrote: > >>>> On 03/03/2023 09:46, Jean-Philippe Brucker wrote: > >>>>> On Thu, Mar 02, 2023 at 07:12:24AM +0900, Itaru Kitayama wrote: > >>>>>>>> I've tried your series in Real on CCA Host, but the KVM arch init > >>>>>>>> emits an Invalid argument error and terminates. > >>>>> > >>>>> This was the KVM_SET_ONE_REG for the SVE vector size. During my tests I > >>>>> didn't enable SVE in the host but shrinkwrap enables more options. > >>>> > >>>> Does the Qemu check for SVE capability on /dev/kvm ? For kvmtool, we > >>>> changed to using the VM instance and that would prevent using SVE, > >>>> until the RMM supports it. > >>> > >>> Yes, QEMU does check the SVE cap on /dev/kvm. I can propose changing it or > >>> complementing it with a VM check in my next version, it seems to work > >>> (though I need to double-check the VM fd lifetime). Same goes for > >>> KVM_CAP_STEAL_TIME, which I need to disable explicitly at the moment. > >> > >> I'm probably missing something since I haven't looked at this, but I'm > >> wondering what the "VM instance" check is and why it should be necessary. > > > > Userspace can check for a KVM_CAP_ on KVM fd (/dev/kvm) or a VM fd > > (returned via KVM_CREATE_VM). > > > >> Shouldn't KVM only expose capabilities which it can provide? I.e. the > > > > Correct, given now that we have different "types" of VMs possible on > > Arm64, (Normal vs Realm vs pVM), the capabilities of each of these > > could be different and thus we should use the KVM_CAP_ on the VM fd ( > > referred to VM instance above) and not the generic KVM fd. > > Using the vm ioctl is even encouraged in the doc for > KVM_CHECK_EXTENSION: > > "Based on their initialization different VMs may have different capabilities. > It is thus encouraged to use the vm ioctl to query for capabilities" > > It would probably make sense to convert QEMU to use the vm ioctl > everywhere (the wrapper falls back to the global version on failure > anyway.) Indeed, I'll see if I can come up with something generic, thanks for the pointer Thanks, Jean
