On 2/26/2025 3:51 PM, Stanislav Kinsburskii wrote:
> On Wed, Feb 26, 2025 at 03:08:03PM -0800, Nuno Das Neves wrote:
>> A few additional definitions are required for the mshv driver code
>> (to follow). Introduce those here and clean up a little bit while
>> at it.
>>
>> Signed-off-by: Nuno Das Neves <nunodasne...@linux.microsoft.com>
>> ---
>>  include/hyperv/hvgdk_mini.h |  64 ++++++++++++++++-
>>  include/hyperv/hvhdk.h      | 132 ++++++++++++++++++++++++++++++++++--
>>  include/hyperv/hvhdk_mini.h |  91 +++++++++++++++++++++++++
>>  3 files changed, 280 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
>> index 58895883f636..e4a3cca0cbce 100644
>> --- a/include/hyperv/hvgdk_mini.h
>> +++ b/include/hyperv/hvgdk_mini.h
>  @@ -1325,6 +1344,49 @@ struct hv_retarget_device_interrupt {  /* 
> HV_INPUT_RETARGET_DEVICE_INTERRUPT */
>>      struct hv_device_interrupt_target int_target;
>>  } __packed __aligned(8);
>>  
>> +enum hv_intercept_type {
>> +#if defined(CONFIG_X86_64)
> 
> Prehaps it would be nice to have per-arch headers for such structures
> instead.
> 
The goal with these files is to reflect the Hyper-V code closely, in order
to make porting the definitions to Linux as easy as possible. Splitting
these into per-arch headers is not my preferred approach because it is
counter to that goal.

>> +    HV_INTERCEPT_TYPE_X64_IO_PORT                   = 0x00000000,
>> +    HV_INTERCEPT_TYPE_X64_MSR                       = 0x00000001,
>> +    HV_INTERCEPT_TYPE_X64_CPUID                     = 0x00000002,
>> +#endif
>> +    HV_INTERCEPT_TYPE_EXCEPTION                     = 0x00000003,
>> +    /* Used to be HV_INTERCEPT_TYPE_REGISTER */
>> +    HV_INTERCEPT_TYPE_RESERVED0                     = 0x00000004,
>> +    HV_INTERCEPT_TYPE_MMIO                          = 0x00000005,
>> +#if defined(CONFIG_X86_64)
>> +    HV_INTERCEPT_TYPE_X64_GLOBAL_CPUID              = 0x00000006,
>> +    HV_INTERCEPT_TYPE_X64_APIC_SMI                  = 0x00000007,
>> +#endif
>> +    HV_INTERCEPT_TYPE_HYPERCALL                     = 0x00000008,
>> +#if defined(CONFIG_X86_64)
>> +    HV_INTERCEPT_TYPE_X64_APIC_INIT_SIPI            = 0x00000009,
>> +    HV_INTERCEPT_MC_UPDATE_PATCH_LEVEL_MSR_READ     = 0x0000000A,
>> +    HV_INTERCEPT_TYPE_X64_APIC_WRITE                = 0x0000000B,
>> +    HV_INTERCEPT_TYPE_X64_MSR_INDEX                 = 0x0000000C,
>> +#endif
>> +    HV_INTERCEPT_TYPE_MAX,
>> +    HV_INTERCEPT_TYPE_INVALID                       = 0xFFFFFFFF,
>> +};
>> +
>> +union hv_intercept_parameters {
>> +    /*  HV_INTERCEPT_PARAMETERS is defined to be an 8-byte field. */
>> +    __u64 as_uint64;
> 
> Should this one be "u64" instead of "__u64" (here and below) ?
> 
Yes, it looks like a few of the uapi types are still lingering, oops!

>> +#if defined(CONFIG_X86_64)
>> +    /* HV_INTERCEPT_TYPE_X64_IO_PORT */
>> +    __u16 io_port;
>> +    /* HV_INTERCEPT_TYPE_X64_CPUID */
>> +    __u32 cpuid_index;
>> +    /* HV_INTERCEPT_TYPE_X64_APIC_WRITE */
>> +    __u32 apic_write_mask;
>> +    /* HV_INTERCEPT_TYPE_EXCEPTION */
>> +    __u16 exception_vector;
>> +    /* HV_INTERCEPT_TYPE_X64_MSR_INDEX */
>> +    __u32 msr_index;
>> +#endif
>> +    /* N.B. Other intercept types do not have any parameters. */
>> +};
>> +
>>  /* Data structures for HVCALL_MMIO_READ and HVCALL_MMIO_WRITE */
>>  #define HV_HYPERCALL_MMIO_MAX_DATA_LENGTH 64
>>  
>> diff --git a/include/hyperv/hvhdk.h b/include/hyperv/hvhdk.h
>> index 64407c2a3809..1b447155c338 100644
>> --- a/include/hyperv/hvhdk.h
>> +++ b/include/hyperv/hvhdk.h
>> @@ -19,11 +19,24 @@
>>  
>>  #define HV_VP_REGISTER_PAGE_VERSION_1       1u
>>  
>> +#define HV_VP_REGISTER_PAGE_MAX_VECTOR_COUNT                7
>> +
>> +union hv_vp_register_page_interrupt_vectors {
>> +    u64 as_uint64;
>> +    struct {
>> +            u8 vector_count;
>> +            u8 vector[HV_VP_REGISTER_PAGE_MAX_VECTOR_COUNT];
>> +    } __packed;
>> +} __packed;
> 
> Packed attribute for the union looks redundant.
> 
Good point, I can remove it in the next version

> Reviewed-by: Stanislav Kinsburskii <skinsburs...@linux.microsoft.com>


Reply via email to