Re: [Qemu-devel] [virtio-dev] Re: [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...

[Cornelia Huck <cohuck@redhat.com>]

On Tue, 3 Jul 2018 09:28:17 -0500
Venu Busireddy <venu.busireddy@oracle.com> wrote:

> On 2018-07-03 12:58:25 +0300, Roman Kagan wrote:
> > On Mon, Jul 02, 2018 at 02:14:52PM -0700, si-wei liu wrote:  
> > > On 7/2/2018 9:14 AM, Roman Kagan wrote:  
> > > > Is the scheme going to be applied/extended to other transports (vmbus,
> > > > virtio-ccw, etc.)?  
> > > Well, it depends on the use case, and how feasible it can be extended to
> > > other transport due to constraints and transport specifics.
> > >   
> > > > Is the failover group concept going to be used beyond PT-PV network
> > > > device failover?  
> > > Although the concept of failover group is generic, the implementation itself
> > > may vary.  
> > 
> > My point with these two questions is that since this patchset is
> > defining external interfaces -- with guest OS, with management layer --  
> 
> This patch set is not defining any external interfaces. All this is doing
> is provide the means and locations to store the "group identifier". How
> that info will be used, I thought, should be another patch set.
> 
> Venu
> 
> > which are not easy to change later, it might make sense to try and see
> > if the interfaces map to other usecases.  E.g. I think we can get enough
> > information on how Hyper-V handles PT-PV network device failover from
> > the current Linux implementation; it may be a good idea to share some
> > concepts and workflows with virtio-pci.

But this patch set defines a host<->guest interface to make pairing
information on the host available to the guest, no?

From my point of view, there are several concerns:
- This approach assumes a homogeneous pairing (same transport), and
  even more, it assumes that this transport is pci.
- It won't work for zPCI (although zPCI is really strange) -- this
  means it will be completely unusable on s390x.
- It is too focused on a narrow use case. How is it supposed to be
  extended?

What I would prefer:
- Implement a pairing id support that does not rely on a certain
  transport, but leverages virtio (which is in the game anyway). We'd
  get at least the "virtio-net device paired with vfio" use case, which
  is what is currently implemented in the Linux kernel.
- Think about a more generic way to relay configuration metadata to the
  host.