From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 57FC318DB1A; Tue, 14 Jul 2026 03:34:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784000065; cv=none; b=iQgpuwSEqnLftCV8h+wIQOoM8MXVh3eURzWkrmwSKuz5YPf2ND0Q4ER20WvFlQT9ABNMVUgTdhEHLetK+F7Df3f3vSrA6eAMAJHJ52BoyFEIAyf07odPOSuAALvSEiF7M12gmrS/nWIUiXmcCdZRouLvFBjAinxahDpyq64008k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784000065; c=relaxed/simple; bh=B6QjqsTCceglXTjrdbHmu3Fd6hA0gffWs3PjsBDdmhI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KP8lhThu65SIpBwAzbAsBC840VjOxCI3amkdIcC/K3C2bOywZPsvc0AvY56CSwhAOI2KPoMf2zbXqBRUJ5PO9osUzUoG0TD61UWISmBjG/5YFf3noF6QZTrOw+tSwdEhzhL37xiJ+qo9CwvapoK9HVnWDFUq2Rr/H+Flayv700g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=TEQ4mSyc; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="TEQ4mSyc" Received: from localhost (unknown [167.220.233.38]) by linux.microsoft.com (Postfix) with ESMTPSA id 57B3D20B7166; Mon, 13 Jul 2026 20:34:15 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 57B3D20B7166 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1784000055; bh=KAZQv62H0azYxiU1DuGKBqf//wlcUoJu/KF5uIUpZhI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TEQ4mSycKUDcvlPTFdFVgJOwUO52dEvB5haGH+yL3kfCTyhw2CV0/cGTmkH25mNW9 NPg3Th2kOLW0HTUfobsvEIptk3eR4uUi93bOkQgPGgKIafD5dRPYUsE0qyWVN8jB4s cJS0DeK2mHrYyaMpEzppezoGVATrnK1mC4UF+3Ag= Date: Tue, 14 Jul 2026 11:34:21 +0800 From: Yu Zhang To: Michael Kelley Cc: "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "iommu@lists.linux.dev" , "linux-pci@vger.kernel.org" , "linux-arch@vger.kernel.org" , "wei.liu@kernel.org" , "kys@microsoft.com" , "haiyangz@microsoft.com" , "decui@microsoft.com" , "longli@microsoft.com" , "joro@8bytes.org" , "will@kernel.org" , "robin.murphy@arm.com" , "bhelgaas@google.com" , "kwilczynski@kernel.org" , "lpieralisi@kernel.org" , "mani@kernel.org" , "robh@kernel.org" , "arnd@arndb.de" , "jgg@ziepe.ca" , "jacob.pan@linux.microsoft.com" , "tgopinath@linux.microsoft.com" , "easwar.hariharan@linux.microsoft.com" , "mrathor@linux.microsoft.com" Subject: Re: [PATCH v2 3/4] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest Message-ID: References: <20260702160518.311234-1-zhangyu1@linux.microsoft.com> <20260702160518.311234-4-zhangyu1@linux.microsoft.com> <3ty6yq6oftsvq52skrngjv5xpyixhsyfo3dndhoujt7emxsb2o@y6ischifpmfn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jul 13, 2026 at 05:37:51PM +0000, Michael Kelley wrote: > From: Yu Zhang Sent: Monday, July 13, 2026 9:46 AM > > > > On Sat, Jul 11, 2026 at 06:31:15PM +0000, Michael Kelley wrote: > > > From: Yu Zhang Sent: Friday, July 10, 2026 12:34 AM > > [snip] > > > > > > > One new thought: Have you considered the hibernate/resume > > > cycle? Does anything need to be done with the pvIOMMU to > > > make it functional again after resume? I see that the Intel and > > > AMD IOMMU drivers have suspend and resume functions. I > > > don't know enough about the Hyper-V pvIOMMU to know if it > > > might also need suspend and resume functions. > > > > > > > Thanks for raising this, Michael. We have not considered such support. > > > > My understanding is that the Intel and AMD drivers only disable the > > IOMMU translation, flush the IOTLB during the suspend and re-enable/ > > reload the preserved root tables and other HW state during in the > > resueme. > > > > But for pvIOMMU, I guess such job shall be done by the hypervisor? > > For a device resumed on the same VM, its logical device ID should > > also remain unchanged? And the corresponding Hyper-V domain objects, > > configuration, and device attachments shall be preserved and restored > > by hypervisor? I don't think the current Hyper-V ABI explicitly defines > > this. But maybe if we want such feature, it could be done by the > > hypervisor transparently? > > > > I agree with your and Jacob's comments that the guest doesn't have > any responsibility for saving/restoring IOMMU hardware state, as the > Intel and AMD IOMMU drivers do. > > But yes, I'm wondering about the Hyper-V domain objects and device > attachments. I doubt Hyper-V can do anything to save and restore > them. Hibernation is a Linux concept that the Hyper-V host doesn't > know anything about. > > Hibernation is already complicated, and in a VM it is even worse. :-( > As a start, see Documentation/virt/hyperv/hibernation.rst, which I > wrote about 18 months ago. It provides some basics as well as outlines > the additional complexity in a Hyper-V guest VM. I'll also try to spend > some time thinking through the implications for a pvIOMMU, and let > you know if I have any more thoughts. > Thank you, Michael, and thanks for pointing us to the documentation. I need some time to better understand the Linux guest hibernation and resume flow and its implications for pvIOMMU. Meanwhile, do you think this limitation should be documented in the commit message or the cover letter? B.R. Yu > Michael