From: Roman Kisel <romank@linux.microsoft.com>
To: Michael Kelley <mhklinux@outlook.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"kys@microsoft.com" <kys@microsoft.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"decui@microsoft.com" <decui@microsoft.com>,
"eahariha@linux.microsoft.com" <eahariha@linux.microsoft.com>,
"haiyangz@microsoft.com" <haiyangz@microsoft.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"nunodasneves@linux.microsoft.com"
<nunodasneves@linux.microsoft.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"tiala@microsoft.com" <tiala@microsoft.com>,
"wei.liu@kernel.org" <wei.liu@kernel.org>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>
Cc: "apais@microsoft.com" <apais@microsoft.com>,
"benhill@microsoft.com" <benhill@microsoft.com>,
"ssengar@microsoft.com" <ssengar@microsoft.com>,
"sunilmut@microsoft.com" <sunilmut@microsoft.com>,
"vdso@hexbites.dev" <vdso@hexbites.dev>
Subject: Re: [PATCH v4 1/5] hyperv: Define struct hv_output_get_vp_registers
Date: Mon, 30 Dec 2024 08:49:07 -0800 [thread overview]
Message-ID: <69ef42c1-c4de-4d50-a3fd-ece18bd5a8f3@linux.microsoft.com> (raw)
In-Reply-To: <SN6PR02MB4157B61822D138A0E0401C1AD4082@SN6PR02MB4157.namprd02.prod.outlook.com>
On 12/29/2024 9:46 AM, Michael Kelley wrote:
> From: Roman Kisel <romank@linux.microsoft.com> Sent: Friday, December 27, 2024 10:32 AM
[...]
>>From a thread [1] with Nuno, my understanding is that the
> include/hyperv/* files should *not* use #ifdef <arch> unless
> strictly necessary because a structure or symbol is used in
> arch neutral code and has a different definition for each arch.
>
> When the structure or symbol definition name contains "x64"
> or "arm64", such conflicts won't occur, and the #ifdef isn't
> needed. This does means that when compiling for either
> x86 or arm64, the symbols from both architectures will be
> visible in the symbol namespace, but that shouldn't cause any
> problems.
>
> So it looks to me like none of the #ifdef's in this patch are
> needed. Nuno -- please jump in if I have misunderstood.
>
Understood, thank you, Michael! From the thread you linked,
it appears that there were other approaches with other trade-offs
to be had, and this route was considered to be the most beneficial
one.
Let me spin up another version with these guards removed.
Thanks you all for bearing with me so far!
> Michael
>
> [1] https://lore.kernel.org/linux-hyperv/SN6PR02MB4157AA30A9F27ECCAE202BC2D4582@SN6PR02MB4157.namprd02.prod.outlook.com/
>
>> struct hv_x64_segment_register {
>> u64 base;
>> u32 limit;
>> @@ -807,6 +809,8 @@ struct hv_x64_table_register {
>> u64 base;
>> } __packed;
>>
>> +#endif
>> +
>> union hv_input_vtl {
>> u8 as_uint8;
>> struct {
>> @@ -1068,6 +1072,41 @@ union hv_dispatch_suspend_register {
>> } __packed;
>> };
>>
>> +#if defined(CONFIG_ARM64)
>> +
>> +union hv_arm64_pending_interruption_register {
>> + u64 as_uint64;
>> + struct {
>> + u64 interruption_pending : 1;
>> + u64 interruption_type : 1;
>> + u64 reserved : 30;
>> + u32 error_code;
>> + } __packed;
>> +};
>> +
>> +union hv_arm64_interrupt_state_register {
>> + u64 as_uint64;
>> + struct {
>> + u64 interrupt_shadow : 1;
>> + u64 reserved : 63;
>> + } __packed;
>> +};
>> +
>> +union hv_arm64_pending_synthetic_exception_event {
>> + u64 as_uint64[2];
>> + struct {
>> + u32 event_pending : 1;
>> + u32 event_type : 3;
>> + u32 reserved : 4;
>> + u32 exception_type;
>> + u64 context;
>> + } __packed;
>> +};
>> +
>> +#endif
>> +
>> +#if defined(CONFIG_X86)
>> +
>> union hv_x64_interrupt_state_register {
>> u64 as_uint64;
>> struct {
>> @@ -1091,6 +1130,8 @@ union hv_x64_pending_interruption_register {
>> } __packed;
>> };
>>
>> +#endif
>> +
>> union hv_register_value {
>> struct hv_u128 reg128;
>> u64 reg64;
>> @@ -1098,13 +1139,33 @@ union hv_register_value {
>> u16 reg16;
>> u8 reg8;
>>
>> - struct hv_x64_segment_register segment;
>> - struct hv_x64_table_register table;
>> union hv_explicit_suspend_register explicit_suspend;
>> union hv_intercept_suspend_register intercept_suspend;
>> union hv_dispatch_suspend_register dispatch_suspend;
>> +#if defined(CONFIG_X86)
>> + struct hv_x64_segment_register segment;
>> + struct hv_x64_table_register table;
>> union hv_x64_interrupt_state_register interrupt_state;
>> union hv_x64_pending_interruption_register pending_interruption;
>> +#endif
>> +#if defined(CONFIG_ARM64)
>> + union hv_arm64_pending_interruption_register pending_interruption;
>> + union hv_arm64_interrupt_state_register interrupt_state;
>> + union hv_arm64_pending_synthetic_exception_event
>> pending_synthetic_exception_event;
>> +#endif
>> +};
>> +
>> +/*
>> + * NOTE: Linux helper struct - NOT from Hyper-V code.
>> + * DECLARE_FLEX_ARRAY() needs to be wrapped into
>> + * a structure and have at least one more member besides
>> + * DECLARE_FLEX_ARRAY.
>> + */
>> +struct hv_output_get_vp_registers {
>> + struct {
>> + DECLARE_FLEX_ARRAY(union hv_register_value, values);
>> + struct {} values_end;
>> + };
>> };
>>
>> #if defined(CONFIG_ARM64)
>> --
>> 2.34.1
--
Thank you,
Roman
next prev parent reply other threads:[~2024-12-30 16:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-27 18:31 [PATCH v4 0/5] hyperv: Fixes for get_vtl(), hv_vtl_apicid_to_vp_id() Roman Kisel
2024-12-27 18:31 ` [PATCH v4 1/5] hyperv: Define struct hv_output_get_vp_registers Roman Kisel
2024-12-27 18:37 ` Easwar Hariharan
2024-12-27 22:52 ` kernel test robot
2024-12-29 17:46 ` Michael Kelley
2024-12-30 16:49 ` Roman Kisel [this message]
2024-12-27 18:31 ` [PATCH v4 2/5] hyperv: Fix pointer type in get_vtl(void) Roman Kisel
2024-12-27 18:31 ` [PATCH v4 3/5] hyperv: Enable the hypercall output page for the VTL mode Roman Kisel
2024-12-27 18:31 ` [PATCH v4 4/5] hyperv: Do not overlap the hvcall IO areas in get_vtl() Roman Kisel
2024-12-27 18:31 ` [PATCH v4 5/5] hyperv: Do not overlap the hvcall IO areas in hv_vtl_apicid_to_vp_id() Roman Kisel
2024-12-27 18:42 ` [PATCH v4 0/5] hyperv: Fixes for get_vtl(), hv_vtl_apicid_to_vp_id() Easwar Hariharan
2024-12-27 19:12 ` Roman Kisel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69ef42c1-c4de-4d50-a3fd-ece18bd5a8f3@linux.microsoft.com \
--to=romank@linux.microsoft.com \
--cc=apais@microsoft.com \
--cc=benhill@microsoft.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=eahariha@linux.microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhklinux@outlook.com \
--cc=mingo@redhat.com \
--cc=nunodasneves@linux.microsoft.com \
--cc=ssengar@microsoft.com \
--cc=sunilmut@microsoft.com \
--cc=tglx@linutronix.de \
--cc=tiala@microsoft.com \
--cc=vdso@hexbites.dev \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).