QEMU-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Konstantin Shkolnyy <kshk@linux.ibm.com>
Cc: alifm@linux.ibm.com, farman@linux.ibm.com,
	richard.henderson@linaro.org, iii@linux.ibm.com,
	david@kernel.org, cohuck@redhat.com, pasic@linux.ibm.com,
	borntraeger@linux.ibm.com, qemu-s390x@nongnu.org,
	qemu-devel@nongnu.org
Subject: Re: [PATCH v7 03/15] s390x/pci: Move iommu_mr from S390PCIIOMMU to S390PCIBusDevice
Date: Mon, 24 Aug 2026 16:50:03 -0400	[thread overview]
Message-ID: <a29c2ca3-842c-47b2-9b87-421ffe4d77d5@linux.ibm.com> (raw)
In-Reply-To: <20260818172521.223460-4-kshk@linux.ibm.com>

On 8/18/26 1:25 PM, Konstantin Shkolnyy wrote:
> This field is only used when S390PCIBusDevice exists, so it can be moved
> there to simplify S390PCIIOMMU which purpose is just to store the "root"
> AddressSpace.

I would argue that this is not the purpose of S390PCIIOMMU until the end
of this series.  Maybe just re-word this to '... to simplify
S390PCIIOMMU towards a structure that contains only the IOMMU container
information needed by the PCI layer for a given slot.'

And propagate the re-wording through patch 12.

> 
> Reviewed-by: Farhan Ali<alifm@linux.ibm.com>
> Signed-off-by: Konstantin Shkolnyy <kshk@linux.ibm.com>

I'm not sure if it was on-list or off-list, but I had asked previously
about re-visiting when the IOMMU is created as it relates to the
S390PCIBusDevice vs the PCIDevice; the existing lifecycle seems a bit
odd to me in that the IOMMU is a property of the S390PCIBusDevice but
rather than being created when the S390PCIBusDevice is created or
plugged, it's creation is deferred until a point where the PCIDevice is
plugged and associated with the S390PCIBusDevice.

I wonder if really it should be created earlier e.g. as soon as the
S390PCIBusDevice is created but only wired up (e.g. referenced in
table->iommu[]) once the PCIDevice<->S390PCIBusDevice association is made.

I think your approach here of moving many of the fields out of the
S390PCIIOMMU is kind of working around that lifecycle oddity to ensure
migration behaves as expected rather than addressing it outright.

At this point, I'll accept it since I don't think re-arranging the
fields makes the oddity any worse and it gets us useful new
functionality -- but I would really like you to look into this lifecycle
as a follow-on after this series.

So with that said and the commit message change:

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>





  reply	other threads:[~2026-08-24 20:50 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18 17:25 [PATCH v7 00/15] s390x/pci: Implement migration for emulated devices Konstantin Shkolnyy
2026-08-18 17:25 ` [PATCH v7 01/15] s390x/pci: implement IOMMU replay Konstantin Shkolnyy
2026-08-18 17:25 ` [PATCH v7 02/15] s390x/pci: Create function to contain translation status check Konstantin Shkolnyy
2026-08-24 21:27   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 03/15] s390x/pci: Move iommu_mr from S390PCIIOMMU to S390PCIBusDevice Konstantin Shkolnyy
2026-08-24 20:50   ` Matthew Rosato [this message]
2026-08-18 17:25 ` [PATCH v7 04/15] s390x/pci: Move dm_mr " Konstantin Shkolnyy
2026-08-24 20:55   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 05/15] s390x/pci: Move iotlb " Konstantin Shkolnyy
2026-08-24 21:12   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 06/15] s390x/pci: Remove a ptr to S390PCIBusDevice from S390PCIIOMMU Konstantin Shkolnyy
2026-08-24 21:15   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 07/15] s390x/pci: Move/rename enabled from S390PCIIOMMU to S390PCIBusDevice Konstantin Shkolnyy
2026-08-24 21:18   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 08/15] s390x/pci: Move dma_limit " Konstantin Shkolnyy
2026-08-24 21:28   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 09/15] s390x/pci: Move g_iota " Konstantin Shkolnyy
2026-08-24 21:32   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 10/15] s390x/pci: Move pba " Konstantin Shkolnyy
2026-08-24 21:36   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 11/15] s390x/pci: Move pal " Konstantin Shkolnyy
2026-08-24 21:42   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 12/15] s390x/pci: Move max_dma_limit " Konstantin Shkolnyy
2026-08-24 21:58   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 13/15] s390x/pci: Add a comment explaining S390PCIIOMMU purpose Konstantin Shkolnyy
2026-08-24 22:00   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 14/15] s390x/pci: Implement migration for emulated devices Konstantin Shkolnyy
2026-08-24 22:35   ` Matthew Rosato
2026-08-18 17:25 ` [PATCH v7 15/15] s390x/pci: Create function to contain fmb_timer start Konstantin Shkolnyy

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=a29c2ca3-842c-47b2-9b87-421ffe4d77d5@linux.ibm.com \
    --to=mjrosato@linux.ibm.com \
    --cc=alifm@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@kernel.org \
    --cc=farman@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=kshk@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.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