> I think it would work out fine for the Linux case. We do not use storage keys. > And if a guest uses them they will be slower if the host uses large pages. Tough. Yes, slower but handled correctly. (e.g. old SLES if I'm not mistaking) > >>>> >>>> My only concern here is: >>>> Can this coexist with the cpumodels in a coordinated way? >>>> >>> >>> We already have to fake away the CMMA facility in user space. So that >>> shouldn't be a problem. The other instructions >>> - PFMF >>> - ISKE, SSKE ... >>> >>> Will simply always be interpreted. Should not affect the CPU model. >> >> Bear with me, it was a long day: >> >> Would it make sense to force user space to configure HPAGE before asking >> for model data, so that we can remove these model bits already from >> kernel side and wouldn't need extensive handling on two points? > Looks like that we do not claim CMMA and storage key interpretion anyway > via the CPU model. > > In the kernel we should then modify try_handle_skey to not believe in > sclp.has_skey (but a new flag instead). For VSIE we already disable > storage key interpretion (and do it manually). We could then also make > the HPAGE stuff XOR KVM_S390_VM_MEM_ENABLE_CMMA. Whatever comes first will > trigger an -EINVAL for the 2nd. > > Something like this. > Exactly what I had in mind. -- Thanks, David / dhildenb -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
