public inbox for linux-hyperv@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: Fri, 23 May 2025 14:55:32 +0530	[thread overview]
Message-ID: <e7763e8c-5f3a-4a37-a696-1b8492d92662@linux.microsoft.com> (raw)
In-Reply-To: <aC9oeJPFynyYg9pU@skinsburskii.>



On 5/22/2025 11:40 PM, Stanislav Kinsburskii wrote:
> On Wed, May 21, 2025 at 11:33:29AM +0530, 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?
>>>
>>
> 
> Let me rephrase: can this driver work without transparent huge pages?
> If yes, then it shouldn't depend on the option and rather select it.
> If not, then it should be either fixed to be able to or have an
> expalanation why this dependecy was introduced.

No, it won't work. Reason being - we are adding support to map VTL0 
address space to a user-mode process in VTL2. VTL2 for OpenHCL makes use 
of Huge pages to improve performance on VMs having large memory 
requirements. Thus, we need TRANSPARENT_HUGEPAGE.

I will add this as a comment in Kconfig.

> 
>>>> +
>>>> +/* 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
>>
> 
> As these ioctls share the same "namespace" (MSHV_IOCTL), removal os the
> VTL suffix looks a better optio to me.
> 
> Thanks,
> Stanislav.


Will make the changes in next patch. Thanks.

Regards,
Naman


  reply	other threads:[~2025-05-23  9:25 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
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 [this message]
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=e7763e8c-5f3a-4a37-a696-1b8492d92662@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