mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mukesh R <mrathor@linux.microsoft.com>
To: "Jörg Rödel" <joro@8bytes.org>
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,
	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 15:33:25 -0700	[thread overview]
Message-ID: <27f49fd8-a95e-9812-c996-53d9eb27a148@linux.microsoft.com> (raw)
In-Reply-To: <arYcFJYOvKf-A6xt@8bytes.org>

On 9/25/26 00:13, J?rg R?del wrote:
> On Thu, Sep 24, 2026 at 05:14:12PM -0700, Mukesh R wrote:
>> So, I'm at a bit of loss. I could go back to V0 which did what what you
>> suggested above, but it can also leave stale mappings when map hypercall
>> succeeds partially and we delete the entire tree node in cleanup (but
>> we could add to the tree back whatever succeeded, but that could fail
>> also, but then we could unmap whatever was mapped, but that could fail
>> also.. see :)...).
>>
> 
> The root-problem seems to be that every operation in the step can fail,
> inluding the unmap operation. This makes it really hard to maintain a
> consistent state. Are there any guarantees Hyper-V gives on the unmap
> operation, e.g under which circumstances it can fail? It would really help if
> the code could assume that it will never fail, or treat a failure as a hard
> error.

I talked to the hyp dev, and unmap is guaranteed to succeed unless
the input is bad, even suggesting i could put a bug there. But i know
there is aversion to putting lot of BUG()s, so i'll just leave the WARN
there.

> If there are no guarantees HV can give, a solution might be to add a
> mapping-resize operation to the internal tree (which can not fail) to correctly
> update the tree structure on partially successful unmaps.

Yeah, perhaps we could do that in future to benefit all drivers.

> I still believe that the internal tree structure should be updated before the
> HV map operation takes place.

Yes, i'll move that before map.

Thanks again,
-Mukesh

>>>> +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;
>>>> +
>>>
>>> The capabilities returned need more checking. I think at least it needs a check
>>> for HV_IOMMU_CAP_PRESENT and that PAGE_SIZE is set in the pgsize_bitmap.
>>
>> In general this caps hypercall is not available to root partitions,
>> our only agreement is for hyp to provide max_iova_width. But, we check
>> HV_DEVICE_DOMAIN_AVAILABLE in hv_iommu_detect() which sorta supersedes
>> HV_IOMMU_CAP_PRESENT. As for page size, hyp owns the iommu and can chose
>> the page size, meaning it can automatically use larger page size when
>> possible. But the hypercall HVCALL_MAP_DEVICE_GPA_PAGES will only take
>> 4k pfns as input, hence:
>>
>> #define HV_IOMMU_PGSIZES SZ_4K        /* for now, to be enhanced */
> 
> Okay, so this deserves a comment in the code to make it clear why there is no
> additional checking and what the hyper-v to guest contract for feature
> detection is.
> 
>> Ok, I can change it back to DMA_BIT_MASK. (I removed after comment
>> on V0 that this is not dma address).
> 
> An IOVA is a DMA address by definition :)
> 
> -Joerg


  reply	other threads:[~2026-09-28 22: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 [this message]
2026-09-28 13:38   ` Jason Gunthorpe
2026-09-28 16:35     ` Easwar Hariharan
2026-09-28 23:33     ` Mukesh R
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=27f49fd8-a95e-9812-c996-53d9eb27a148@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®