On 2/10/25 15:22, Peter Maydell wrote:
On Mon, 10 Feb 2025 at 14:14, Peter Xu <pet...@redhat.com> wrote:
On Fri, Feb 07, 2025 at 06:18:50PM +0000, Peter Maydell wrote:
On Fri, 7 Feb 2025 at 17:48, Peter Xu <pet...@redhat.com> wrote:
On Fri, Feb 07, 2025 at 04:58:39PM +0000, Peter Maydell wrote:
(I wonder if we ought to suggest quiescing outstanding
DMA in the enter phase? But it's probably easier to fix
the iommus like this series does than try to get every
dma-capable pci device to do something different.)
I wonder if we should provide some generic helper to register vIOMMU reset
callbacks, so that we'll be sure any vIOMMU model impl that will register
at exit() phase only, and do nothing during the initial two phases. Then
we can put some rich comment on that helper on why.
Looks like it means the qemu reset model in the future can be a combination
of device tree (which resets depth-first) and the three phases model. We
will start to use different approach to solve different problems.
The tree of QOM devices (i.e. the one based on the qbus buses
and rooted at the sysbus) resets depth-first, but it does so in
three phases: first we traverse everything doing 'enter'; then
we traverse everything doing 'hold'; then we traverse everything
doing 'exit'. There *used* to be an awkward mix of some things
being three-phase and some not, but we have now got rid of all
of those so a system reset does a single three-phase reset run
which resets everything.
Right. Sorry I wasn't very clear before indeed on what I wanted to
express.
My understanding is the 3 phases reset, even if existed, was not designed
to order things like vIOMMU and devices that is already described by system
topology. That's, IMHO, exactly what QOM topology wanted to achieve right
now on ordering device resets and the whole depth-first reset method would
make sense with it.
So from that specific POV, it's a mixture use of both methods on ordering
of devices to reset now (rather than the order of reset process within a
same device, provided into 3 phases). It may not be very intuitive when
someone reads about the two reset mechanisms, as one would naturally take
vIOMMU as a root object of any other PCIe devices under root complex, and
thinking the order should be guaranteed by QOM on reset already. In
reality it's not. So that's the part I wonder if we want to document.
Yeah, I see what you mean. The issue here is that the iommu isn't
actually a parent of the devices that access through it. This is
true both in the "qbus/qdev bus tree" sense (where it is the PCI
controller device that owns the PCI bus that the devices are on)
and also in the QOM tree sense[*] (where usually the iommu and the
PCI controller are both created by the machine or the SoC, I guess?).
Instead iommus are separate devices that control data flow but
aren't in a parent-child relationship with the devices on either
side of that flow. There is a guarantee about reset ordering between
bus parent/child (so the PCI controller resets before it resets
the PCI bus that resets the PCI devices on the bus), but that doesn't
help the iommu.
[*] I have a vague idea that ideally we might want reset to be
QOM-tree based rather than qbus-tree based. But getting there from
here is non-trivial. And maybe what we really want is "objects,
especially SoCs, that create children can define what their reset
tree is, with the default being to reset all the QOM children".
yes. When I quickly thought about it, I had the idea that we could
reparent the vIOMMU device(s) to a default or a specific PHB and
order the reset calls from the PHB reset routine.
Lots of non-thought-through complexity here ;-)
same ...
C.
