mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mukesh R <mrathor@linux.microsoft.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux.dev, linux-arch@vger.kernel.org,
	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 V1 3/3] x86/hyperv: Implement root VM IOMMU kernel only driver
Date: Mon, 28 Sep 2026 16:33:35 -0700	[thread overview]
Message-ID: <28ef0634-24ed-2cc7-89c8-48c8615a9691@linux.microsoft.com> (raw)
In-Reply-To: <179060271395.122959.9162511491972155683.b4-review@b4>

On 9/28/26 06:38, Jason Gunthorpe wrote:
>> [ ... 103 lines skipped ... ]
>> +/*
>> + * We will not claim these PCI devices. Eg hypervisor debugger is using it
>> + * for a dynamic debug session. They cannot be enumerated under static ACPI
>> + * device scope.
>> + */
>> +static char *hv_skip_pci_devs;
>> +static int __init hv_iommu_setup_skip(char *str)
>> +{
>> +	hv_skip_pci_devs = str;
>> +	return 1;
>> +}
>> +/* Eg: hv_iommu_skip=(SSSS:BB:DD.F)(SSSS:BB:DD.F) */
>> +__setup("hv_iommu_skip=", hv_iommu_setup_skip);
> 
> I don't like this in a driver. This isn't really skipping anything, it
> is just leaving some devices in an identity mode.

Ok. I talked to the original author of that and i can just remove
it. It's mostly for running hyp debugger and we can just carry
the patch internally, at least for now.


> If you have a use case for this as a general command line policy then
> come with a core code enhacmenet so everyone can choose per-device
> their boot time mode.
> 
>> [ ... 7 lines skipped ... ]
>> +struct hv_domain {
>> +	struct iommu_domain iommu_dom;
>> +	u32 domid_num;			      /* as opposed to domain_id.type */
>> +	spinlock_t mappings_lock;	      /* protects mappings_tree */
>> +	struct rb_root_cached mappings_tree;  /* iova to pa lookup tree */
> 
> This seems basically identical to what virtio-iommu is doing, can you
> consider sharing its code?

yeah, the tree part is somewhat identical, but virtio-iommu has extra
fields that we don't need. overall, i don't think there is enough here
to refactor, just few lines of code around add/remove calling kernel
interval tree apis. moreover, if hyp can provide the lookup in future,
i'd like to just remove it from here.

>> [ ... 26 lines skipped ... ]
>> +static bool hv_special_domain(struct hv_domain *hvdom)
>> +{
>> +	return hvdom == &hv_def_identity_dom || hvdom == &hv_def_blocked_dom;
>> +}
> 
> This is only called by hv_iommu_domain_free() which is only linked to
> hv_paging_domain_ops(), so it should be dead code
> 
>> [ ... 204 lines skipped ... ]
>> +static int hv_iommu_attach_dev(struct iommu_domain *immdom, struct device *dev,
>> +			       struct iommu_domain *old)
>> +{
>> +	struct pci_dev *pdev;
>> +	int rc;
>> +	struct hv_domain *hvdom_new = to_hv_domain(immdom);
> 
> 'new' is an odd variable name here

'current' is passed as 'old', so we are moving from old to new i
thought. please tell me what would you like it called, thx.

>> [ ... 246 lines skipped ... ]
>> +static struct iommu_group *hv_iommu_device_group(struct device *dev)
>> +{
>> +	return pci_device_group(dev);
>> +}
> 
> No need for a wrapper, use the function directly in the ops

it helps with quick debug... just set breakpoint in hv_iommu_device_group
or add a printk here at the cost of one jmp instruction. but whatever..
i can remove it if it helps move this forward.

>> +
>> +static void hv_iommu_get_resv_regions(struct device *dev,
>> +				      struct list_head *head)
>> +{
>> +	struct iommu_resv_region *reg;
>> +
>> +	/* reserve the entire LAPIC region */
>> +	reg = iommu_alloc_resv_region(0xfee00000, SZ_1M, 0, IOMMU_RESV_MSI,
>> +				      GFP_KERNEL);
> 
> There was some discussion to make a helper for this, I don't see it
> merged yet..

we are both waiting on each other, whoever goes first will leave
the follower to address it i guess. i cannot test without this and
i am not sure if that series will merge first or this.

>> [ ... 65 lines skipped ... ]
>> +static int __init hv_iommu_init(void)
>> +{
>> +	int rc;
>> +	struct iommu_device *iommup = &hv_virt_iommu;
>> +	struct hv_output_get_iommu_capabilities caps;
>> +
>> +	if (!hv_is_hyperv_initialized())
>> +		return -ENODEV;
>> +
>> +	rc = hv_iommu_get_caps(&caps);
>> +	if (rc)
>> +		return rc;
>> +
>> +	hv_iommu_max_iova = ((ulong)1 << caps.max_iova_width) - 1;
>> +
>> +	rc = iommu_device_sysfs_add(iommup, NULL, NULL, "%s", "hyperv-iommu");
>> +	if (rc) {
>> +		pr_err("Hyper-V: iommu_device_sysfs_add failed: %d\n", rc);
>> +		return rc;
>> +	}
>> +
>> +	/* This must come before iommu_device_register() because the latter
>> +	 * calls into the hooks.
>> +	 */
>> +	hv_initialize_special_domains();
> 
> This probably should be before doing anything with sysfs.

ok.

Thanks,
-Mukesh



  parent reply	other threads:[~2026-09-28 23:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24  2:02 [PATCH V1 0/3] Hyper-V: root VM iommu " Mukesh R
2026-09-24  2:02 ` [PATCH V1 1/3] PCI: hv: Export hv_build_devid_type_pci() and change return type Mukesh R
2026-09-24  2:02 ` [PATCH V1 2/3] mshv: Import data structs around device domains from hyperv headers Mukesh R
2026-09-24 17:48   ` Easwar Hariharan
2026-09-24  2:02 ` [PATCH V1 3/3] x86/hyperv: Implement root VM IOMMU kernel only driver Mukesh R
2026-09-24 13:35   ` Jörg Rödel
2026-09-25  0:14     ` Mukesh R
2026-09-25  7:13       ` Jörg Rödel
2026-09-28 22:33         ` Mukesh R
2026-09-28 13:38   ` Jason Gunthorpe
2026-09-28 16:35     ` Easwar Hariharan
2026-09-28 23:33     ` Mukesh R [this message]
2026-09-28 23:36       ` Jason Gunthorpe

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=28ef0634-24ed-2cc7-89c8-48c8615a9691@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=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®