From: Mukesh R <mrathor@linux.microsoft.com>
To: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux.dev, linux-arch@vger.kernel.org,
jgg@nvidia.com, jacob.pan@linux.microsoft.com, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
arnd@arndb.de
Subject: Re: [PATCH V0 2/3] mshv: Import data structs around device domains from hyperv headers
Date: Tue, 22 Sep 2026 14:10:58 -0700 [thread overview]
Message-ID: <c75bbe43-d6cc-25d2-d45e-6b85bebd6562@linux.microsoft.com> (raw)
In-Reply-To: <5b292db7-1d55-4aef-9053-be2156c6e886@linux.microsoft.com>
On 9/22/26 10:48, Easwar Hariharan wrote:
> On 9/21/2026 15:50, Mukesh R wrote:
>> Copy/import from Hyper-V public headers, definitions and declarations that
>> are related to creating iommu domains in the hypervisor, attaching devices
>> to them, doing the reverse, etc.
>>
>> Signed-off-by: Mukesh R <mrathor@linux.microsoft.com>
>> ---
>> include/hyperv/hvgdk_mini.h | 9 ++++
>> include/hyperv/hvhdk_mini.h | 90 +++++++++++++++++++++++++++++++++++++
>> 2 files changed, 99 insertions(+)
>>
>> diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
>> index 6a4e8b9d570f..3b74f3c0229d 100644
>> --- a/include/hyperv/hvgdk_mini.h
>> +++ b/include/hyperv/hvgdk_mini.h
>> @@ -326,6 +326,8 @@ union hv_hypervisor_version_info {
>> /* stimer Direct Mode is available */
>> #define HV_STIMER_DIRECT_MODE_AVAILABLE BIT(19)
>>
>> +#define HV_DEVICE_DOMAIN_AVAILABLE BIT(24)
>> +
>
> For my understanding, how is ms_hyperv.misc_features.HV_DEVICE_DOMAIN_AVAILABLE = 1
> different from HV_IOMMU_CAP_PRESENT = 1 combined with HV_IOMMU_CAP_S2 = 1?
> It seems like there is room to combine forces with the guest driver and just go with
> the latter.
It's different. we want to make sure the version of the hypervisor
supports creating device domains. see: HVCALL_CREATE_DEVICE_DOMAIN
Thanks,
-Mukesh
>> /*
>> * Implementation recommendations. Indicates which behaviors the hypervisor
>> * recommends the OS implement for optimal performance.
>> @@ -486,9 +488,15 @@ union hv_vp_assist_msr_contents { /* HV_REGISTER_VP_ASSIST_PAGE */
>> #define HVCALL_GET_VP_INDEX_FROM_APIC_ID 0x009a
>> #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af
>> #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0
>> +#define HVCALL_CREATE_DEVICE_DOMAIN 0x00b1
>> +#define HVCALL_ATTACH_DEVICE_DOMAIN 0x00b2
>> +#define HVCALL_MAP_DEVICE_GPA_PAGES 0x00b3
>> +#define HVCALL_UNMAP_DEVICE_GPA_PAGES 0x00b4
>> #define HVCALL_SIGNAL_EVENT_DIRECT 0x00c0
>> #define HVCALL_POST_MESSAGE_DIRECT 0x00c1
>> #define HVCALL_DISPATCH_VP 0x00c2
>> +#define HVCALL_DETACH_DEVICE_DOMAIN 0x00c4
>> +#define HVCALL_DELETE_DEVICE_DOMAIN 0x00c5
>> #define HVCALL_GET_GPA_PAGES_ACCESS_STATES 0x00c9
>> #define HVCALL_ACQUIRE_SPARSE_SPA_PAGE_HOST_ACCESS 0x00d7
>> #define HVCALL_RELEASE_SPARSE_SPA_PAGE_HOST_ACCESS 0x00d8
>> @@ -502,6 +510,7 @@ union hv_vp_assist_msr_contents { /* HV_REGISTER_VP_ASSIST_PAGE */
>> #define HVCALL_MMIO_READ 0x0106
>> #define HVCALL_MMIO_WRITE 0x0107
>> #define HVCALL_DISABLE_HYP_EX 0x010f
>> +#define HVCALL_GET_IOMMU_CAPABILITIES 0x0125
>> #define HVCALL_MAP_STATS_PAGE2 0x0131
>>
>> /* HV_HYPERCALL_INPUT */
>> diff --git a/include/hyperv/hvhdk_mini.h b/include/hyperv/hvhdk_mini.h
>> index 035ba20870f7..3bb052fd6e06 100644
>> --- a/include/hyperv/hvhdk_mini.h
>> +++ b/include/hyperv/hvhdk_mini.h
>> @@ -548,4 +548,94 @@ union hv_device_id { /* HV_DEVICE_ID */
>> } acpi;
>> } __packed;
>>
>> +/* 3 domain types: stage 1, stage 2, and SOC */
>> +#define HV_DEVICE_DOMAIN_TYPE_S2 0 /* HV_DEVICE_DOMAIN_ID_TYPE_S2 */
>> +#define HV_DEVICE_DOMAIN_TYPE_S1 1 /* HV_DEVICE_DOMAIN_ID_TYPE_S1 */
>
>
>> +#define HV_DEVICE_DOMAIN_TYPE_SOC 2 /* HV_DEVICE_DOMAIN_ID_TYPE_SOC */
>
> I don't think this domain type is used in patch 3, perhaps we bring it in when needed?
>
>> +
>> +/* ID for stage 2 default domain and NULL domain */
>
> I think this comment would be more useful if it related the MSHV default and NULL domains to
> the Linux equivalents of identity and blocking respectively. As it stands, it just repeats the
> names of the defines it is a comment for.
>
>> +#define HV_DEVICE_DOMAIN_ID_S2_DEFAULT 0
>> +#define HV_DEVICE_DOMAIN_ID_S2_NULL 0xFFFFFFFFULL
>> +
>> +union hv_device_domain_id {
>> + u64 as_uint64;
>> + struct {
>> + u32 type : 4;
>> + u32 reserved : 28;
>> + u32 id;
>> + };
>> +} __packed;
>> +
>> +struct hv_input_device_domain { /* HV_INPUT_DEVICE_DOMAIN */
>> + u64 partition_id;
>> + union hv_input_vtl owner_vtl;
>> + u8 padding[7];
>> + union hv_device_domain_id domain_id;
>> +} __packed;
>> +
>> +union hv_create_device_domain_flags { /* HV_CREATE_DEVICE_DOMAIN_FLAGS */
>> + u32 as_uint32;
>> + struct {
>> + u32 forward_progress_required : 1;
>> + u32 inherit_owning_vtl : 1;
>> + u32 reserved : 30;
>> + } __packed;
>> +} __packed;
>> +
>> +struct hv_input_create_device_domain { /* HV_INPUT_CREATE_DEVICE_DOMAIN */
>> + struct hv_input_device_domain device_domain;
>> + union hv_create_device_domain_flags create_device_domain_flags;
>> +} __packed;
>> +
>> +struct hv_input_delete_device_domain { /* HV_INPUT_DELETE_DEVICE_DOMAIN */
>> + struct hv_input_device_domain device_domain;
>> +} __packed;
>> +
>> +struct hv_input_attach_device_domain { /* HV_INPUT_ATTACH_DEVICE_DOMAIN */
>> + struct hv_input_device_domain device_domain;
>> + union hv_device_id device_id;
>> +} __packed;
>> +
>> +struct hv_input_detach_device_domain { /* HV_INPUT_DETACH_DEVICE_DOMAIN */
>> + u64 partition_id;
>> + union hv_device_id device_id;
>> +} __packed;
>> +
>> +/* HV_INPUT_GET_IOMMU_CAPABILITIES */
>> +struct hv_input_get_iommu_capabilities {
>> + u64 partition_id;
>> + u64 reserved;
>> +} __packed;
>> +
>> +#define HV_IOMMU_CAP_PRESENT BIT_ULL(0)
>> +#define HV_IOMMU_CAP_S2 BIT_ULL(1)
>> +#define HV_IOMMU_CAP_S1 BIT_ULL(2)
>> +#define HV_IOMMU_CAP_S1_5LVL BIT_ULL(3)
>> +#define HV_IOMMU_CAP_PASID BIT_ULL(4)
>> +#define HV_IOMMU_CAP_ATS BIT_ULL(5)
>> +#define HV_IOMMU_CAP_PRI BIT_ULL(6)
>> +
>> +struct hv_output_get_iommu_capabilities { /* HV_OUTPUT_GET_IOMMU_CAPABILITIES */
>> + u32 size;
>> + u16 reserved;
>> + u8 max_iova_width;
>> + u8 max_pasid_width;
>> + u64 iommu_cap; /* HV_IOMMU_CAP_* above */
>> + u64 pgsize_bitmap;
>> +} __packed;
>> +
>> +struct hv_input_map_device_gpa_pages { /* HV_INPUT_MAP_DEVICE_GPA_PAGES */
>> + struct hv_input_device_domain device_domain;
>> + union hv_input_vtl target_vtl;
>> + u8 padding[3];
>> + u32 map_flags;
>> + u64 target_device_va_base;
>> + u64 gpa_page_list[];
>> +} __packed;
>> +
>> +struct hv_input_unmap_device_gpa_pages { /* HV_INPUT_UNMAP_DEVICE_GPA_PAGES */
>> + struct hv_input_device_domain device_domain;
>> + u64 target_device_va_base;
>> +} __packed;
>> +
>> #endif /* _HV_HVHDK_MINI_H */
next prev parent reply other threads:[~2026-09-22 21:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 22:50 [PATCH V0 0/3] Hyper-V: root VM iommu kernel only driver Mukesh R
2026-09-21 22:50 ` [PATCH V0 1/3] PCI: hv: Export hv_build_devid_type_pci() and change return type Mukesh R
2026-09-22 17:48 ` Easwar Hariharan
2026-09-21 22:50 ` [PATCH V0 2/3] mshv: Import data structs around device domains from hyperv headers Mukesh R
2026-09-22 17:48 ` Easwar Hariharan
2026-09-22 21:10 ` Mukesh R [this message]
2026-09-22 21:34 ` Easwar Hariharan
2026-09-21 22:50 ` [PATCH V0 3/3] x86/hyperv: Implement root VM IOMMU kernel only driver Mukesh R
2026-09-22 17:49 ` Easwar Hariharan
2026-09-22 21:42 ` Mukesh R
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=c75bbe43-d6cc-25d2-d45e-6b85bebd6562@linux.microsoft.com \
--to=mrathor@linux.microsoft.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=easwar.hariharan@linux.microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux.dev \
--cc=jacob.pan@linux.microsoft.com \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kys@microsoft.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--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
all inboxes | Powered by JetHome®