Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [PATCH 1/2] KVM: s390: selftests: Refactor memop test
To:     Janis Schoetterl-Glausch <scgl@linux.ibm.com>,
        Christian Borntraeger <borntraeger@linux.ibm.com>,
        Janosch Frank <frankja@linux.ibm.com>,
        Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc:     Thomas Huth <thuth@redhat.com>,
        David Hildenbrand <david@redhat.com>, kvm@vger.kernel.org,
        linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
        Shuah Khan <skhan@linuxfoundation.org>
References: <20220211182215.2730017-11-scgl@linux.ibm.com>
 <20220217145336.1794778-1-scgl@linux.ibm.com>
 <20220217145336.1794778-2-scgl@linux.ibm.com>
 <ce27dcb4-c2a3-fad6-8277-f5b86e184892@linuxfoundation.org>
 <a1c0e067-cc6a-8edb-1fe9-4aa368aa6518@linux.ibm.com>
From:   Shuah Khan <skhan@linuxfoundation.org>
Message-ID: <f184f1a4-be76-0fd2-bbd7-010d1fb0ef7e@linuxfoundation.org>
Date:   Fri, 18 Feb 2022 15:14:17 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <a1c0e067-cc6a-8edb-1fe9-4aa368aa6518@linux.ibm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2/18/22 5:09 AM, Janis Schoetterl-Glausch wrote:
> On 2/17/22 18:36, Shuah Khan wrote:
>> On 2/17/22 7:53 AM, Janis Schoetterl-Glausch wrote:
>>> Introduce macro for performing MEM_OP ioctls in a concise way.
>>
>> How does this help? What is the value in re-writing existing
>> code and turning it into a macro?
> 
> I want invocations of the ioctl to be independent of each other, so the reader does not
> have to keep track of the state of the struct kvm_s390_mem_op.
> 
> So you have to specify all arguments manually like so, which is rather noisy and makes it
> hard to see what the relevant parameter is:
> 
> ksmo.gaddr = guest_mem1;
> ksmo.flags = 0;
> ksmo.size = maxsize;
> ksmo.op = KVM_S390_MEMOP_LOGICAL_WRITE;
> ksmo.buf = (uintptr_t)mem1;
> ksmo.ar = 17;
> rv = _vcpu_ioctl(vm, VCPU_ID, KVM_S390_MEM_OP, &ksmo);
> 
> Or you introduce an abstraction.
> Previously I used lots of functions with repeated code which got chaotic.
> I decided on the macro because it's more flexible, e.g. you don't have to pass default args.
> For example, there is only one test that passes the access register arg, so you would want
> to default it to 0 for all other test.
> For the access key argument you need to pass both a flag and the key itself, so you'd probably
> get rid of this redundancy also.
> There also might be future extensions of the ioctl that work the same way
> (not 100% but not purely theoretical either).
> 
> With the macro all that is orthogonal, you just pass the argument you need or you don't.
> With functions you'd maybe add a memop_key() variant and a _ar() variant and a _key_ar()
> variant if you need it (currently not necessary), doubling the number of functions with
> each additional argument. Another example is GADDR_V and GADDR, the first takes care of
> translating the address to an physical one, but sometimes you need to pass it untranslated,
> and we need to combine that with passing a key or not.
> 
> A big improvement was making the target of the ioctl (vm/vcpu) and the operation arguments
> instead of baking it into the function. Since they're mandatory arguments this is independent
> of the macro vs functions question.
> 
> In the end there are multiple independent but interacting improvements and it is kinda
> hard to make the call on how far to go along one dimension, e.g. I was unsure if I
> wanted to introduce the DEFAULT_READ macro, but decided for it, since, as a reviewer,
> you can see that it executes the same code with different arguments, instead of trying
> to identify the difference between 5 copy-pasted and modified lines of code. On the other
> hand you have the cost of introducing an indirection.
>>
>>

Sounds good. I am not fan of macros, however, in this case macro
helps. Please split the patches so that restructuring work is
done first and then the new code - as per my suggestion on the
second patch.

thanks,
-- Shuah