public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Naman Jain <namjain@linux.microsoft.com>
To: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Cc: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
	Roman Kisel <romank@linux.microsoft.com>,
	Anirudh Rayabharam <anrayabh@linux.microsoft.com>,
	Saurabh Sengar <ssengar@linux.microsoft.com>,
	Nuno Das Neves <nunodasneves@linux.microsoft.com>,
	ALOK TIWARI <alok.a.tiwari@oracle.com>,
	linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org
Subject: Re: [PATCH v3 2/2] Drivers: hv: Introduce mshv_vtl driver
Date: Wed, 21 May 2025 15:02:59 +0530	[thread overview]
Message-ID: <3ab2597b-3a64-497c-888e-dd5d0c0e5076@linux.microsoft.com> (raw)
In-Reply-To: <80853cdb-fd34-4a5e-99a0-1a71b8ce8226@linux.microsoft.com>



On 5/21/2025 11:33 AM, Naman Jain wrote:
> 
> 
> On 5/21/2025 12:25 AM, Stanislav Kinsburskii wrote:
>> On Mon, May 19, 2025 at 10:26:42AM +0530, Naman Jain wrote:
>>> Provide an interface for Virtual Machine Monitor like OpenVMM and its
>>> use as OpenHCL paravisor to control VTL0 (Virtual trust Level).
>>> Expose devices and support IOCTLs for features like VTL creation,
>>> VTL0 memory management, context switch, making hypercalls,
>>> mapping VTL0 address space to VTL2 userspace, getting new VMBus
>>> messages and channel events in VTL2 etc.
>>>
>>> Co-developed-by: Roman Kisel <romank@linux.microsoft.com>
>>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
>>> Co-developed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
>>> Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
>>> Reviewed-by: Roman Kisel <romank@linux.microsoft.com>
>>> Reviewed-by: Alok Tiwari <alok.a.tiwari@oracle.com>
>>> Message-ID: <20250512140432.2387503-3-namjain@linux.microsoft.com>
>>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>>> ---
>>>   drivers/hv/Kconfig          |   20 +
>>>   drivers/hv/Makefile         |    7 +-
>>>   drivers/hv/mshv_vtl.h       |   52 +
>>>   drivers/hv/mshv_vtl_main.c  | 1783 +++++++++++++++++++++++++++++++++++
>>>   include/hyperv/hvgdk_mini.h |   81 ++
>>>   include/hyperv/hvhdk.h      |    1 +
>>>   include/uapi/linux/mshv.h   |   82 ++
>>>   7 files changed, 2025 insertions(+), 1 deletion(-)
>>>   create mode 100644 drivers/hv/mshv_vtl.h
>>>   create mode 100644 drivers/hv/mshv_vtl_main.c
>>>
>>> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
>>> index eefa0b559b73..21cee5564d70 100644
>>> --- a/drivers/hv/Kconfig
>>> +++ b/drivers/hv/Kconfig
>>> @@ -72,4 +72,24 @@ config MSHV_ROOT
>>>         If unsure, say N.
>>> +config MSHV_VTL
>>> +    tristate "Microsoft Hyper-V VTL driver"
>>> +    depends on HYPERV && X86_64
>>> +    depends on TRANSPARENT_HUGEPAGE
>>
>> Why does it depend on TRANSPARENT_HUGEPAGE?
>>
> 
> Thanks for reviewing. This config is required for below functions which
> are used for mshv_vtl_low device.
> 
> vm_fault_t mshv_vtl_low_huge_fault ->
> * vmf_insert_pfn_pmd
> * vmf_insert_pfn_pud
> 
> 
>> <snip>
>>
>>> diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
>>> index 1be7f6a02304..cc11000e39f4 100644
>>> --- a/include/hyperv/hvgdk_mini.h
>>> +++ b/include/hyperv/hvgdk_mini.h
>>> @@ -882,6 +882,23 @@ struct hv_get_vp_from_apic_id_in {
>>>       u32 apic_ids[];
>>>   } __packed;
>>> +union hv_register_vsm_partition_config {
>>> +    __u64 as_u64;
>>
>> Please, follow the file pattern: as_u64 -> as_uint64
>>
>>> +    struct {
>>> +        __u64 enable_vtl_protection : 1;
>>
>> Ditto: __u64 -> u64
>>
>>> +        __u64 default_vtl_protection_mask : 4;
>>> +        __u64 zero_memory_on_reset : 1;
>>> +        __u64 deny_lower_vtl_startup : 1;
>>> +        __u64 intercept_acceptance : 1;
>>> +        __u64 intercept_enable_vtl_protection : 1;
>>> +        __u64 intercept_vp_startup : 1;
>>> +        __u64 intercept_cpuid_unimplemented : 1;
>>> +        __u64 intercept_unrecoverable_exception : 1;
>>> +        __u64 intercept_page : 1;
>>> +        __u64 mbz : 51;
>>> +    };
>>> +};
>>> +
>>>   /*
>>> diff --git a/include/hyperv/hvhdk.h b/include/hyperv/hvhdk.h
>>> index b4067ada02cf..9b890126e8e8 100644
>>> --- a/include/hyperv/hvhdk.h
>>> +++ b/include/hyperv/hvhdk.h
>>> @@ -479,6 +479,7 @@ struct hv_connection_info {
>>>   #define HV_EVENT_FLAGS_COUNT        (256 * 8)
>>>   #define HV_EVENT_FLAGS_BYTE_COUNT    (256)
>>>   #define HV_EVENT_FLAGS32_COUNT        (256 / sizeof(u32))
>>> +#define HV_EVENT_FLAGS_LONG_COUNT    (HV_EVENT_FLAGS_BYTE_COUNT / 
>>> sizeof(__u64))
>>
>> Ditto
>>
>>>   /* linux side we create long version of flags to use long bit ops 
>>> on flags */
>>>   #define HV_EVENT_FLAGS_UL_COUNT        (256 / sizeof(ulong))
>>> diff --git a/include/uapi/linux/mshv.h b/include/uapi/linux/mshv.h
>>> index 876bfe4e4227..a8c39b08b39a 100644
>>> --- a/include/uapi/linux/mshv.h
>>> +++ b/include/uapi/linux/mshv.h
>>> @@ -288,4 +288,86 @@ struct mshv_get_set_vp_state {
>>>    * #define MSHV_ROOT_HVCALL            _IOWR(MSHV_IOCTL, 0x07, 
>>> struct mshv_root_hvcall)
>>>    */
>>> +/* Structure definitions, macros and IOCTLs for mshv_vtl */
>>> +
>>> +#define MSHV_CAP_CORE_API_STABLE        0x0
>>> +#define MSHV_CAP_REGISTER_PAGE          0x1
>>> +#define MSHV_CAP_VTL_RETURN_ACTION      0x2
>>> +#define MSHV_CAP_DR6_SHARED             0x3
>>> +#define MSHV_MAX_RUN_MSG_SIZE                256
>>> +
>>> +#define MSHV_VP_MAX_REGISTERS   128
>>> +
>>> +struct mshv_vp_registers {
>>> +    __u32 count;    /* at most MSHV_VP_MAX_REGISTERS */
>>
>> Same here: __u{32,64} -> u{32,64}.
>>
>> Please, address everywhere.
>>
> 
> I'll take care of all of these in my next patch.
> 


One concern about this change in include/uapi/linux/mshv.h.
I see the convention of using '__' family of data types in this file.
Whatever we do here, will be applicable to existing code as well.
Do you suggest we should change it to u{32,64} variants or keep
it in current form?

Regards,
Naman

>> <snip>
>>
>>> +
>>> +/* vtl device */
>>> +#define MSHV_CREATE_VTL            _IOR(MSHV_IOCTL, 0x1D, char)
>>> +#define MSHV_VTL_ADD_VTL0_MEMORY    _IOW(MSHV_IOCTL, 0x21, struct 
>>> mshv_vtl_ram_disposition)
>>> +#define MSHV_VTL_SET_POLL_FILE        _IOW(MSHV_IOCTL, 0x25, struct 
>>> mshv_vtl_set_poll_file)
>>> +#define MSHV_VTL_RETURN_TO_LOWER_VTL    _IO(MSHV_IOCTL, 0x27)
>>> +#define MSHV_GET_VP_REGISTERS        _IOWR(MSHV_IOCTL, 0x05, struct 
>>> mshv_vp_registers)
>>> +#define MSHV_SET_VP_REGISTERS        _IOW(MSHV_IOCTL, 0x06, struct 
>>> mshv_vp_registers)
>>> +
>>> +/* VMBus device IOCTLs */
>>> +#define MSHV_SINT_SIGNAL_EVENT    _IOW(MSHV_IOCTL, 0x22, struct 
>>> mshv_vtl_signal_event)
>>> +#define MSHV_SINT_POST_MESSAGE    _IOW(MSHV_IOCTL, 0x23, struct 
>>> mshv_vtl_sint_post_msg)
>>> +#define MSHV_SINT_SET_EVENTFD     _IOW(MSHV_IOCTL, 0x24, struct 
>>> mshv_vtl_set_eventfd)
>>> +#define MSHV_SINT_PAUSE_MESSAGE_STREAM     _IOW(MSHV_IOCTL, 0x25, 
>>> struct mshv_sint_mask)
>>> +
>>> +/* hv_hvcall device */
>>> +#define MSHV_HVCALL_SETUP        _IOW(MSHV_IOCTL, 0x1E, struct 
>>> mshv_vtl_hvcall_setup)
>>> +#define MSHV_HVCALL              _IOWR(MSHV_IOCTL, 0x1F, struct 
>>> mshv_vtl_hvcall)
>>
>> How many of these ioctls are actually used by the mshv root driver?
>> Should those which are VTl-specific be named as such (like 
>> MSHV_VTL_SET_POLL_FILE)?
>> Another option would be to keep all the names generic.
>>
>> Thanks,
>> Stanislav
> 
> None of the IOCTLs in mshv_vtl section, introduced in this patch is used
> by mshv_root driver. Since IOCTLs of mshv_root does not have MSHV_ROOT
> prefix, I am OK with removing MSHV_VTL_* prefix from these IOCTL names.
> You can let me know if you want me to prefix them with MSHV_VTL.
> 
> Thanks again for reviewing.
> 
> Regards,
> Naman
> 
>>
>>>   #endif
>>> -- 
>>> 2.34.1
>>>
> 


  reply	other threads:[~2025-05-21  9:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-19  4:56 [PATCH v3 0/2] Drivers: hv: Introduce new driver - mshv_vtl Naman Jain
2025-05-19  4:56 ` [PATCH v3 1/2] Drivers: hv: Export some symbols for mshv_vtl Naman Jain
2025-05-19  4:56 ` [PATCH v3 2/2] Drivers: hv: Introduce mshv_vtl driver Naman Jain
2025-05-20 18:55   ` Stanislav Kinsburskii
2025-05-21  6:03     ` Naman Jain
2025-05-21  9:32       ` Naman Jain [this message]
2025-05-22 19:15         ` Nuno Das Neves
2025-05-23  8:16           ` Naman Jain
2025-05-22 18:10       ` Stanislav Kinsburskii
2025-05-23  9:25         ` Naman Jain
2025-05-29 16:21           ` Stanislav Kinsburskii
2025-05-19 18:22 ` [PATCH v3 0/2] Drivers: hv: Introduce new driver - mshv_vtl Saurabh Singh Sengar

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=3ab2597b-3a64-497c-888e-dd5d0c0e5076@linux.microsoft.com \
    --to=namjain@linux.microsoft.com \
    --cc=alok.a.tiwari@oracle.com \
    --cc=anrayabh@linux.microsoft.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nunodasneves@linux.microsoft.com \
    --cc=romank@linux.microsoft.com \
    --cc=skinsburskii@linux.microsoft.com \
    --cc=ssengar@linux.microsoft.com \
    --cc=wei.liu@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