From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3453335979 for ; Thu, 5 Mar 2026 18:36:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772735811; cv=none; b=FWeY38dYVzepA9jxjS8q/is91++u37EPFT7FxDzOKjhOEDur1VBr112UvjJCaRB+oBHNeG1XBj4ssfOAUo/u65y1ThvK4MSyUMIyPI5SFb+FpuPtnornElpUdwpuy8OeF4RUYBL0wXQlxIz++eTezRiBP/gx8jOnnNndv2ZGe9Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772735811; c=relaxed/simple; bh=/nCQbIM9WF/udWJhsd5kHZLLjcm5NPQ7KZuVjgfTAQk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=P9cRNrUbNPv9fPx5zt5bmX80Vh0ezbzwQObERyXvPQ/g0F/Bd8/0bw0Dv8yrqQD0WaeGUSmb8zfFs4V8KVj+wA2GpLJpXrVf+dRbhBi0gLZh4U30BdF+MHdOmKrBN++K3q/8tbz28mgY0P0BQWuKtoaMpUaXOc54Y1V1UOKXhN8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=X59brTXW; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="X59brTXW" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2ae6dd98043so18778755ad.3 for ; Thu, 05 Mar 2026 10:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772735808; x=1773340608; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=8SIBi7LZpDXEzALEhfUg4rA5WlAeQaGU2tPtYlr/3VA=; b=X59brTXWvkeP9yGA5NDRQwh8Ho2KBhhdtJHwTbnzc7iTs/Fv+M6CplU9BlK5K8/Ezz cvqfxDttg57fiLahuA93ZrpD79L90Hh9hPid59JRwHkCim19pWIw3eZsM9+6O3ywxc7D mnUuZNn37UKNL7SmO931MAKh9wUDm1Ika8/+OGvPoJ6UuAu9fn2XoeKuzcrPMFfSOEIp 4obyHzwJQfXNDMuQ7f0K48JLhZ0/u6X9QCa4qCESKrsJkRETLqVTLEdbnOjDu8Hn6aT+ Rp5XR+o59EmkVsFE76eIJJhXWxkqMrAJkxxVjOg/XAzgHpMo4HxATt/NrO/hjQrnH+UJ x5oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772735808; x=1773340608; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=8SIBi7LZpDXEzALEhfUg4rA5WlAeQaGU2tPtYlr/3VA=; b=E54wiCdcWyGhnGpLWoyhrUguqar/pKULZw6IbDgXXk/FwXZqNgXDcmZFK5no6LO1nm VUtLavgcQNxg6vS9vZh9DJieol7x/la1eGD4Qq7zicTFg2vqirDN6flwdq8SVEe8lDRb 0rh2+7S/se+BBAXfMc6uM464Vyb3KpsCz8rZXXjURWLlxSmdhOlC/tcQv/HOwZ+jiasl SpdnL6GapmH6Ddw2pl8xdo3hwNb4liY3vPS6QetS3t5tsEcibX82F35nTTfar39D01OH 34TEg/z1P9Dx+qbJW9e9Us9xOQnAZ0CsM4eizP84iQN81/mQ5rPhHqDMCrqmGurKEFUh BGzA== X-Forwarded-Encrypted: i=1; AJvYcCUcy6dPD2FODrjI9lC/2az8my5DLwADPKEICf66EfPqlA97zFwOYMPrsXeO1gHs2mKJqB2WMk37NlaMg3w=@vger.kernel.org X-Gm-Message-State: AOJu0YxMxscz0wbpE6EoXsWntt8GMjnhdoA15k91DgbM6b0iRpn+shkB MifITVQ1xMN/ebvoe2+D+3v+Vj5h+fiGhyEa+kQYfi2OLKjWXhASKA+GkuXoWprCJfnKL/f5jXK asc3gOQ== X-Received: from pldq21.prod.google.com ([2002:a17:902:c9d5:b0:2ae:635f:4b2b]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:2443:b0:2ae:7f28:124b with SMTP id d9443c01a7336-2ae7f281273mr9581445ad.22.1772735808319; Thu, 05 Mar 2026 10:36:48 -0800 (PST) Date: Thu, 5 Mar 2026 10:36:47 -0800 In-Reply-To: <97d40dd0e6abaf28f43d4d8ccf9c547a16c52e33.camel@infradead.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <97d40dd0e6abaf28f43d4d8ccf9c547a16c52e33.camel@infradead.org> Message-ID: Subject: Re: [PATCH] KVM: x86: Fix C++ user API for structures with variable length arrays From: Sean Christopherson To: David Woodhouse Cc: "Gustavo A. R. Silva" , keescook@chromium.org, daniel@iogearbox.net, gustavoars@kernel.org, jgg@ziepe.ca, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 26, 2026, David Woodhouse wrote: > From: David Woodhouse >=20 > Commit 94dfc73e7cf4 ("treewide: uapi: Replace zero-length arrays with > flexible-array members") broke the userspace API for C++. Not just in > the sense of 'userspace needs to be updated, but UAPI is supposed to be > stable", but broken in the sense that I can't actually see *how* the > structures can be used from C++ in the same way that they were usable > before. >=20 > These structures ending in VLAs are typically a *header*, which can be > followed by an arbitrary number of entries. Userspace typically creates > a larger structure with some non-zero number of entries, for example in > QEMU's kvm_arch_get_supported_msr_feature(): >=20 > struct { > struct kvm_msrs info; > struct kvm_msr_entry entries[1]; > } msr_data =3D {}; >=20 > While that works in C, it fails in C++ with an error like: > flexible array member =E2=80=98kvm_msrs::entries=E2=80=99 not at end of = =E2=80=98struct msr_data=E2=80=99 >=20 > Fix this by using __DECLARE_FLEX_ARRAY() for the VLA, which is a helper > provided by that already uses [0] for C++ compilation. >=20 > Also put the header fields into a struct_group() to provide (in C) a > separate struct (e.g 'struct kvm_msrs_hdr') without the trailing VLA. Unless I'm missing something, this is an entirely optional change that need= s to be done separately, especialy since I want to tag this for: Cc: stable@vger.kernel.org I definitely don't hate the __struct_group definitions, but I don't know th= at I love them either as they make the code a bit harder to read, and more impor= tantly there's a non-zero chance that defining the new structurs could break users= pace builds and force an update, e.g. if userspace already concocts its own head= er overlay, which would be very unpleasant for a stable@ patch. If we do define headers, I think I'd want a wrapper around __struct_group()= to prettify the common case and force consistent naming, e.g. #define kvm_struct_header(NAME, MEMBERS...) \ __struct_group(NAME ##_header, h, /* no attrs */, MEMBERS) struct kvm_msrs { kvm_struct_header(kvm_msrs, __u32 nmsrs; /* number of msrs in entries */ __u32 pad; ); __DECLARE_FLEX_ARRAY(struct kvm_msr_entry, entries); }; But that's likely going to lead to some amount of bikeshedding, e.g. arguab= ly kvm_header() would be sufficient and easier on the eyes. Which is all the = more reason to handle it separately. > Fixes: 94dfc73e7cf4 ("treewide: uapi: Replace zero-length arrays with fle= xible-array members") > Signed-off-by: David Woodhouse > --- > arch/x86/include/uapi/asm/kvm.h | 29 ++++++++++++++++++----------- > include/uapi/linux/kvm.h | 9 ++++++--- > /* for KVM_GET_PIT and KVM_SET_PIT */ > @@ -397,8 +402,10 @@ struct kvm_xsave { > * The offsets of the state save areas in struct kvm_xsave follow > * the contents of CPUID leaf 0xD on the host. > */ > - __u32 region[1024]; > - __u32 extra[]; > + __struct_group(kvm_xsave_hdr, hdr, /* no attrs */, > + __u32 region[1024]; > + ); This is *very* misleading, as XSTATE itself has a header, but this is somet= hing else entirely (just the always-allocated region). > + __DECLARE_FLEX_ARRAY(__u32, extra); > }; There are several structs that got missed: kvm_pmu_event_filter kvm_reg_list kvm_signal_mask kvm_coalesced_mmio_ring kvm_cpuid kvm_stats_desc