[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <340d35c2-46ed-35ea-43fa-e5cb64c27230@arm.com>
Date: Thu, 29 Apr 2021 17:06:07 +0100
From: Steven Price <steven.price@....com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
James Morse <james.morse@....com>,
Julien Thierry <julien.thierry.kdev@...il.com>,
Suzuki K Poulose <suzuki.poulose@....com>,
kvmarm@...ts.cs.columbia.edu, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, Dave Martin <Dave.Martin@....com>,
Mark Rutland <mark.rutland@....com>,
Thomas Gleixner <tglx@...utronix.de>, qemu-devel@...gnu.org,
Juan Quintela <quintela@...hat.com>,
"Dr. David Alan Gilbert" <dgilbert@...hat.com>,
Richard Henderson <richard.henderson@...aro.org>,
Peter Maydell <peter.maydell@...aro.org>,
Haibo Xu <Haibo.Xu@....com>, Andrew Jones <drjones@...hat.com>
Subject: Re: [PATCH v11 5/6] KVM: arm64: ioctl to fetch/store tags in a guest
On 27/04/2021 18:58, Catalin Marinas wrote:
> On Fri, Apr 16, 2021 at 04:43:08PM +0100, Steven Price wrote:
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 24223adae150..2b85a047c37d 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -184,6 +184,20 @@ struct kvm_vcpu_events {
>> __u32 reserved[12];
>> };
>>
>> +struct kvm_arm_copy_mte_tags {
>> + __u64 guest_ipa;
>> + __u64 length;
>> + union {
>> + void __user *addr;
>> + __u64 padding;
>> + };
>> + __u64 flags;
>> + __u64 reserved[2];
>> +};
>
> I know Marc asked for some reserved space in here but I'm not sure it's
> the right place. And what's with the union of a 64-bit pointer and
> 64-bit padding, it doesn't change any layout?
Yes it's unnecessary here - habits die hard. This would ensure that the
layout is the same for 32 bit and 64 bit. But it's irrelevant here as
(a) we don't support 32 bit, and (b) flags has 64 bit alignment anyway.
I'll drop the union (and 'padding').
> Maybe add the two reserved
> values to the union in case we want to store something else in the
> future.
I'm not sure what you mean here. What would the reserved fields be
unioned with? And surely they are no longer reserved in that case?
> Or maybe I'm missing something, I haven't checked how other KVM ioctls
> work.
KVM ioctls seem to (sometimes) have some reserved space at the end of
the structure for expansion without the ioctl number changing (since the
structure size is encoded into the ioctl).
Steve
Powered by blists - more mailing lists