On Thu, 27 Jan 2022 17:29:44 +0100
Janis Schoetterl-Glausch <scgl@xxxxxxxxxxxxx> wrote:
> On 1/25/22 13:00, Thomas Huth wrote:
> > On 20/01/2022 13.23, Janis Schoetterl-Glausch wrote:
> >> On 1/20/22 11:38, Thomas Huth wrote:
> >>> On 18/01/2022 10.52, Janis Schoetterl-Glausch wrote:
> >>>> Channel I/O honors storage keys and is performed on absolute memory.
> >>>> For I/O emulation user space therefore needs to be able to do key
> >>>> checked accesses.
> >>>> The vm IOCTL supports read/write accesses, as well as checking
> >>>> if an access would succeed.
> >>> ...
> >>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> >>>> index e3f450b2f346..dd04170287fd 100644
> >>>> --- a/include/uapi/linux/kvm.h
> >>>> +++ b/include/uapi/linux/kvm.h
> >>>> @@ -572,6 +572,8 @@ struct kvm_s390_mem_op {
> >>>> #define KVM_S390_MEMOP_LOGICAL_WRITE 1
> >>>> #define KVM_S390_MEMOP_SIDA_READ 2
> >>>> #define KVM_S390_MEMOP_SIDA_WRITE 3
> >>>> +#define KVM_S390_MEMOP_ABSOLUTE_READ 4
> >>>> +#define KVM_S390_MEMOP_ABSOLUTE_WRITE 5
> >>>
> >>> Not quite sure about this - maybe it is, but at least I'd like to see this discussed: Do we really want to re-use the same ioctl layout for both, the VM and the VCPU file handles? Where the userspace developer has to know that the *_ABSOLUTE_* ops only work with VM handles, and the others only work with the VCPU handles? A CPU can also address absolute memory, so why not adding the *_ABSOLUTE_* ops there, too? And if we'd do that, wouldn't it be sufficient to have the VCPU ioctls only - or do you want to call these ioctls from spots in QEMU where you do not have a VCPU handle available? (I/O instructions are triggered from a CPU, so I'd assume that you should have a VCPU handle around?)
> >>
> >> There are some differences between the vm and the vcpu memops.
> >> No storage or fetch protection overrides apply to IO/vm memops, after all there is no control register to enable them.
> >> Additionally, quiescing is not required for IO, tho in practice we use the same code path for the vcpu and the vm here.
> >> Allowing absolute accesses with a vcpu is doable, but I'm not sure what the use case for it would be, I'm not aware of
> >> a precedence in the architecture. Of course the vcpu memop already supports logical=real accesses.
> >
> > Ok. Maybe it then would be better to call new ioctl and the new op defines differently, to avoid confusion? E.g. call it "vmmemop" and use:
> >
> > #define KVM_S390_VMMEMOP_ABSOLUTE_READ 1
> > #define KVM_S390_VMMEMOP_ABSOLUTE_WRITE 2
> >
> > ?
> >
> > Thomas
> >
>
> Thanks for the suggestion, I had to think about it for a while :). Here are my thoughts:
> The ioctl type (vm/vcpu) and the operations cannot be completely orthogonal (vm + logical cannot work),
> but with regards to the absolute operations they could be. We don't have a use case for that
> right now and the semantics are a bit unclear, so I think we should choose a design now that
> leaves us space for future extension. If we need to, we can add a NON_QUIESCING flag backwards compatibly
> (tho it seems a rather unlikely requirement to me), that would behave the same for vm/vcpu memops.
> We could also have a NO_PROT_OVERRIDE flag, which the vm memop would ignore.
> Whether override is possible is dependent on the vcpu state, so user space leaves the exact behavior to KVM anyway.
> If you wanted to enforce that protection override occurs, you would have to adjust
> the vcpu state and therefore there should be no confusion about whether to use a vcpu or vm ioctl.
>
> So I'm inclined to have one ioctl code and keep the operations as they are.
> I moved the key to the union. One question that remains is whether to enforce that reserved bytes must be 0.
> In general I think that it is a good idea, since it leaves a bigger design space for future extensions.
> However the vcpu memop has not done that. I think it should be enforced for new functionality (operations, flags),
I agree with enforcing that unused bits should be 0
> any objections?
>
> I'll try to be thorough in documenting the currently supported behavior.
this is also a good idea :)
