Linux Virtualization - Oct 2023 - [PATCH vfio 11/11] vfio/virtio: Introduce a vfio driver over virtio devices

> From: Michael S. Tsirkin <mst at redhat.com>
> Sent: Thursday, October 12, 2023 4:23 PM
> 
> On Tue, Sep 26, 2023 at 03:45:36AM +0000, Parav Pandit wrote:
> >
> >
> > > From: Michael S. Tsirkin <mst at redhat.com>
> > > Sent: Tuesday, September 26, 2023 12:06 AM
> >
> > > One can thinkably do that wait in hardware, though. Just defer
> > > completion until read is done.
> > >
> > Once OASIS does such new interface and if some hw vendor _actually_
wants
> to do such complex hw, may be vfio driver can adopt to it.
> 
> The reset behaviour I describe is already in the spec. What else do you
want
> OASIS to standardize? Virtio currently is just a register map it does not
yet
> include suggestions on how exactly do pci express transactions look. You
feel we
> should add that?
The reset behavior in the spec for modern as listed in [1] and [2] is just fine.

What I meant is in context of having MMIO based legacy registers to "defer
completion until read is done".
I think you meant, "Just differ read completion, until reset is done".
This means the hw needs to finish the device reset for thousands of devices
within the read completion timeout of the pci.
So when if OASIS does such standardization, someone can implement it.

What I recollect, is OASIS didn't not standardize such anti-scale approach
and took the admin command approach which achieve better scale.
Hope I clarified.

I am not expecting OASIS to do anything extra for legacy registers.

[1] The device MUST reset when 0 is written to device_status, and present a 0 in
device_status once that is done.
[2] After writing 0 to device_status, the driver MUST wait for a read of
device_status to return 0 before reinitializing
the device.

On Thu, Oct 12, 2023 at 11:11:20AM +0000, Parav Pandit
wrote:
> 
> > From: Michael S. Tsirkin <mst at redhat.com>
> > Sent: Thursday, October 12, 2023 4:23 PM
> > 
> > On Tue, Sep 26, 2023 at 03:45:36AM +0000, Parav Pandit wrote:
> > >
> > >
> > > > From: Michael S. Tsirkin <mst at redhat.com>
> > > > Sent: Tuesday, September 26, 2023 12:06 AM
> > >
> > > > One can thinkably do that wait in hardware, though. Just
defer
> > > > completion until read is done.
> > > >
> > > Once OASIS does such new interface and if some hw vendor
_actually_ wants
> > to do such complex hw, may be vfio driver can adopt to it.
> > 
> > The reset behaviour I describe is already in the spec. What else do
you want
> > OASIS to standardize? Virtio currently is just a register map it does
not yet
> > include suggestions on how exactly do pci express transactions look.
You feel we
> > should add that?
> 
> The reset behavior in the spec for modern as listed in [1] and [2] is just
fine.
> 
> What I meant is in context of having MMIO based legacy registers to
"defer completion until read is done".
> I think you meant, "Just differ read completion, until reset is
done".
yes
> This means the hw needs to finish the device reset for thousands of devices
within the read completion timeout of the pci.
no, each device does it's own reset.
> So when if OASIS does such standardization, someone can implement it.
> 
> What I recollect, is OASIS didn't not standardize such anti-scale
approach and took the admin command approach which achieve better scale.
> Hope I clarified.
You are talking about the extension for trap and emulate.
I am instead talking about devices that work with
existing legacy linux drivers with no traps.
> I am not expecting OASIS to do anything extra for legacy registers.
> 
> [1] The device MUST reset when 0 is written to device_status, and present a
0 in device_status once that is done.
> [2] After writing 0 to device_status, the driver MUST wait for a read of
device_status to return 0 before reinitializing
> the device.
We can add a note explaining that legacy drivers do not wait
after doing reset, that is not a problem.
If someone wants to make a device that works with existing
legacy linux drivers, they can do that.
Won't work with all drivers though, which is why oasis did not
want to standardize this.

-- 
MST