Thanks for the confirmation KY. And sorry for the HTML email, fixed.
Best regards, Alex Ionescu On Tue, Sep 19, 2023 at 1:10 PM KY Srinivasan <[email protected]> wrote: > > Linux support for Hyper-V has been completely upstreamed and our goal is to > upstream all new development we do in this space. We welcome contributions to > extend/improve what we currently have and will be happy to review > contributions. > > > > Regards, > > > > K. Y > > > > Sent from Outlook > > From: Alex Ionescu <[email protected]> > Sent: Tuesday, September 19, 2023 9:59 AM > To: [email protected] > Cc: KY Srinivasan <[email protected]>; Dexuan Cui <[email protected]>; > Haiyang Zhang <[email protected]>; Michael Kelley (LINUX) > <[email protected]>; Saurabh Sengar <[email protected]> > Subject: [EXTERNAL] Question regarding patches/discussions > > > > You don't often get email from [email protected]. Learn why this is important > > Dear linux-hyperv Maintainers, > > > > I understand that the main goal of this submodule/project is to provide a > first-class top-tier experience to delight both developers and users when > running Linux hypervisor on Windows systems by Hyper-V (both in traditional > VM scenarios, as well as in Docker and WSL2 scenarios), as well as to provide > a number of strategic capabilities for Azure-related workloads, both internal > to Microsoft and external (including VTL2/HCL, TDX/SNP Isolation, > Linux-as-Root-Partition, etc) -- some of which are not expected to be used > outside of specific Azure scenarios within Microsoft. > > > > That being said, there are some potential additional ideas and projects that > could help improve the experience, stability, security, etc., of > Linux-under-HyperV, which are not in Microsoft's current or future plans. Are > you able and willing to review patches (not necessarily promise to approve) > for linux-hyperv as other linux kernel maintainers normally would, or do you > consider this a "closed" project for Microsoft purposes only? > > > > For example, as part of a project at UC Berkeley, I would have some small > extensibility patches that I would like to try upstreaming, and some small > refactoring (for example, new definitions in the GDK headers were not made > available in the TLFS headers -- even stable ones, or some new hypercall > support code was added, but only to the mshv driver/module, and not in the > kernel itself, etc...). As you've pushed more new code into the new mshv > module for VTL2/launching VMs, this prevents (or requires code duplication) > lighting up some of those features for other kernel-level functionality that > I'd like to leverage for hardening/etc. I would also potentially like to > investigate access to hypercalls/hyperv earlier than today (closer to > Windows' model at UEFI boot). > > > > But before going too deep into those discussions/proposals, I wanted to see > if such room exists to begin with (and of course assuming it doesn't > conflict/harm Microsoft's goals/plans). > > > > Thank you! > > > > > > Best regards, > Alex Ionescu
