RE: [PATCH V2 6/6] virtio-pci: implement dirty page tracking

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Sunday, November 5, 2023 9:42 PM
> 
> On Fri, Nov 03, 2023 at 03:47:34PM +0000, Parav Pandit wrote:
> > > > [1]
> > > > https://lists.oasis-open.org/archives/virtio-comment/202310/msg004
> > > > 75.h
> > > > tml
> > > you still need to explain why this does not work for pass-through.
> > It does not work for following reasons.
> > 1. Because all the fields that put on the member device are not in direct
> control of the hypervisor.
> > The device is directly controlled by the guest including the device status and
> when it resets the device all the things stored in the device are lost.
> 
> I think the idea is that when this gateway is in the device then device reset has
> to trap. At a high level, ok. But then what?
> Is a full scan of all memory required until device reset is complete?
> Drivers currently tend to busy poll the reset register, if this takes very long we
> might start seeing soft lockup messages. What is the idea then? Maybe for this
> we need a separate weaker reset that does not touch this capability?
>
You meant the gateway is not in the device, right?

I likely didn't understand. I don't see a relation to timing.

When the device reset is not trapped by the hypervisor, most things does not work, it requires trapping other things to like cvq, device registers and more.
It may be fine for those use case, but it does not fullfill the requirement of passthrough mode of hw.
  
> >
> > 2. the PCI FLR is clearing all the registers you exposed here.
> 
> Same problem, though FLR at least is expected to take a long time.
> 
> 
> > 3. Endless expansion of config registers of dirty tracking is not scalable, as they
> are not init time registers not following the Appendix B guidelines.
> 
> > 4. bitmap based dirty tracking is not atomic between cpu and device.
> > Hence, it is racy.
> 
> Well pcie atomics exist. Not sure whether it's reasonable to rely on them. Any
> data on who common implementations are?
>
Pci atomics are (a) fetch add, (b) swap, (c) CAS.
Not atomic_OR().
 
> > 5. All the device context needed for passthrough based hypervisor for a
> device type specific is missing.
> > All of those can be used for non-passthrough as well.
> > [1]
> > https://lists.oasis-open.org/archives/virtio-comment/202311/msg00085.h
> > tml
> >
> > > And I
> > > remember this is a point-less topic as MST ever wants to mute
> > > another "pass- through" thread.
> > No. he did not say that.
> > He meant to not endlessly debate which one is better.
> > He clearly said, try to see if you can make multiple hypervisor model work.
> > And your series shows a clear ignorance of his guidance.
> 
> I think you mean "ignoring" :)
> 
I am sorry, yes, I meant ignoring.