Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Mukesh R <mrathor@linux.microsoft.com>
To: Jacob Pan <jacob.pan@linux.microsoft.com>
Cc: hpa@zytor.com, robin.murphy@arm.com, robh@kernel.org,
	wei.liu@kernel.org, mhklinux@outlook.com, muislam@microsoft.com,
	namjain@linux.microsoft.com, magnuskulke@linux.microsoft.com,
	anbelski@linux.microsoft.com, linux-kernel@vger.kernel.org,
	linux-hyperv@vger.kernel.org, iommu@lists.linux.dev,
	linux-pci@vger.kernel.org, linux-arch@vger.kernel.org,
	kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com,
	longli@microsoft.com, tglx@kernel.org, mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
	joro@8bytes.org, will@kernel.org, lpieralisi@kernel.org,
	kwilczynski@kernel.org, bhelgaas@google.com, arnd@arndb.de
Subject: Re: [PATCH V4 1/9] mshv: Provide a way to get partition ID if running in a VMM process
Date: Fri, 24 Jul 2026 12:14:08 -0700	[thread overview]
Message-ID: <95a1bed4-dd5a-654b-9e7a-7d5a453e3966@linux.microsoft.com> (raw)
In-Reply-To: <20260723152132.000033d0@linux.microsoft.com>

On 7/23/26 15:21, Jacob Pan wrote:
> Hi Mukesh,

Hey Jacob, pl see inline..

> On Fri, 17 Jul 2026 19:19:41 -0700
> Mukesh R <mrathor@linux.microsoft.com> wrote:

   ... snip...

>>   static int
>>   add_partition(struct mshv_partition *partition)
>>   {
>> @@ -2073,6 +2094,7 @@ mshv_ioctl_create_partition(void __user
>> *user_arg, struct device *module_dev) goto cleanup_irq_srcu;
>>   
>>   	partition->pt_id = pt_id;
>> +	partition->pt_vmm_tgid = current->tgid;
> I wonder how robust this mechanism is to identify target partition via
> tgid.
> 1) what prevents a VMM process create more than one partition? in that
> case each partition would have the same tgid.

Currently, none of the VMMs we support do that, and doesn't look like
there is much of a demand for it.

> 2) IIUC, the lifetime of the partition is tied to FD, which is
> different than the lifetime of a PID. The partition FD can be
> inherited or passed to another process. The VMM tg can exit while
> the FDs can be alive. Then the tgid can be reused by another unrelated
> process, right?

yeah, AI keeps telling me that, but not super accurate imo.

we are using tgid and not pid. tgid is process group id, and that will
stay around as long as there is at least one process in it. if we used
pid, then that would be the case.

> Would it be more robust to based this on the partition FD instead of
> tgid?
  
it might be, but problem with that is we need pt-id in other cases
where that is not available: for example in hv_iommu_domain_alloc_paging
and in irq remapping paths for direct attached devices. if we can sort
that out somehow, then we can do that. but i suspect, it would take
some time to figure that out, so i hope we can make that a future
enhancement.

For now, i've been thinking of just putting a check and returning
ENOTSUPP if a vmm tries to create another partition.

Thanks,
-Mukesh

>>   	ret = add_partition(partition);
>>   	if (ret)
>> diff --git a/include/asm-generic/mshyperv.h
>> b/include/asm-generic/mshyperv.h index bf601d67cecb..e8cbc4e3f7ad
>> 100644 --- a/include/asm-generic/mshyperv.h
>> +++ b/include/asm-generic/mshyperv.h
>> @@ -350,6 +350,7 @@ int hv_call_add_logical_proc(int node, u32
>> lp_index, u32 acpi_id); int
>> hv_call_notify_all_processors_started(void); bool hv_lp_exists(u32
>> lp_index); int hv_call_create_vp(int node, u64 partition_id, u32
>> vp_index, u32 flags); +u64 mshv_current_partid(void);
>>   
>>   #else /* CONFIG_MSHV_ROOT */
>>   static inline bool hv_root_partition(void) { return false; }
>> @@ -380,6 +381,10 @@ static inline int hv_call_create_vp(int node,
>> u64 partition_id, u32 vp_index, u3 {
>>   	return -EOPNOTSUPP;
>>   }
>> +static inline u64 mshv_current_partid(void)
>> +{
>> +	return HV_PARTITION_ID_INVALID;
>> +}
>>   #endif /* CONFIG_MSHV_ROOT */
>>   
>>   static inline int hv_deposit_memory(u64 partition_id, u64 status)


  reply	other threads:[~2026-07-24 19:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-18  2:19 [PATCH V4 0/9] PCI passthru on Hyper-V Mukesh R
2026-07-18  2:19 ` [PATCH V4 1/9] mshv: Provide a way to get partition ID if running in a VMM process Mukesh R
2026-07-18  2:32   ` sashiko-bot
2026-07-23 22:21   ` Jacob Pan
2026-07-24 19:14     ` Mukesh R [this message]
2026-07-24 22:08       ` Jacob Pan
2026-07-25  1:48         ` Mukesh R
2026-07-18  2:19 ` [PATCH V4 2/9] mshv: Add declarations and definitions for VFIO-MSHV bridge device Mukesh R
2026-07-18  2:31   ` sashiko-bot
2026-07-18  2:19 ` [PATCH V4 3/9] mshv: Introduce basic mshv bridge device for VFIO to build upon Mukesh R
2026-07-18  2:36   ` sashiko-bot
2026-07-18  2:19 ` [PATCH V4 4/9] mshv: Add ioctl support for MSHV-VFIO bridge device Mukesh R
2026-07-18  2:34   ` sashiko-bot
2026-07-24 17:20   ` Jacob Pan
2026-07-24 21:27     ` Mukesh R
2026-07-18  2:19 ` [PATCH V4 5/9] mshv: Import data structs around device passthru from hyperv headers Mukesh R
2026-07-18  2:30   ` sashiko-bot
2026-07-18  2:19 ` [PATCH V4 6/9] PCI: hv: Export hv_build_devid_type_pci() and change return type Mukesh R
2026-07-18  2:32   ` sashiko-bot
2026-07-18  2:19 ` [PATCH V4 7/9] x86/hyperv: Implement Hyper-V virtual IOMMU Mukesh R
2026-07-18  2:34   ` sashiko-bot
2026-07-18  2:19 ` [PATCH V4 8/9] mshv: Populate mmio mappings for PCI passthru Mukesh R
2026-07-18  2:33   ` sashiko-bot
2026-07-24 21:41     ` Mukesh R
2026-07-18  2:19 ` [PATCH V4 9/9] mshv: Disable movable regions upfront if device passthru Mukesh R
2026-07-18  2:40   ` sashiko-bot

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=95a1bed4-dd5a-654b-9e7a-7d5a453e3966@linux.microsoft.com \
    --to=mrathor@linux.microsoft.com \
    --cc=anbelski@linux.microsoft.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux.dev \
    --cc=jacob.pan@linux.microsoft.com \
    --cc=joro@8bytes.org \
    --cc=kwilczynski@kernel.org \
    --cc=kys@microsoft.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=longli@microsoft.com \
    --cc=lpieralisi@kernel.org \
    --cc=magnuskulke@linux.microsoft.com \
    --cc=mhklinux@outlook.com \
    --cc=mingo@redhat.com \
    --cc=muislam@microsoft.com \
    --cc=namjain@linux.microsoft.com \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=tglx@kernel.org \
    --cc=wei.liu@kernel.org \
    --cc=will@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