All of lore.kernel.org
 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: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24  2:02 [PATCH V1 0/3] Hyper-V: root VM iommu kernel only driver 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  2:13   ` sashiko-bot
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  2:16   ` sashiko-bot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.