Re: [PATCH v3 0/2] VFIO mdev aggregated resources handling

From: Alex Williamson <alex.williamson@redhat.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"intel-gvt-dev@lists.freedesktop.org" 
	<intel-gvt-dev@lists.freedesktop.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Zhenyu Wang <zhenyuw@linux.intel.com>
Subject: Re: [PATCH v3 0/2] VFIO mdev aggregated resources handling
Date: Fri, 10 Jul 2020 09:12:17 -0600	[thread overview]
Message-ID: <20200710091217.7a62b4cc@x1.home> (raw)
In-Reply-To: <20200710062958.GB29271@joy-OptiPlex-7040>

On Fri, 10 Jul 2020 14:29:59 +0800
Yan Zhao <yan.y.zhao@intel.com> wrote:

> On Fri, Jul 10, 2020 at 02:09:06AM +0000, Tian, Kevin wrote:
> <...>
> > > > > We also can't even seem to agree that type is a necessary requirement
> > > > > for compatibility.  Your discussion below of a type-A, which is
> > > > > equivalent to a type-B w/ aggregation set to some value is an example
> > > > > of this.  We might also have physical devices with extensions to
> > > > > support migration.  These could possibly be compatible with full mdev
> > > > > devices.  We have no idea how an administrative tool would discover
> > > > > this other than an exhaustive search across every possible target.
> > > > > That's ugly but feasible when considering a single target host, but
> > > > > completely untenable when considering a datacenter.  
> > > >
> > > > If exhaustive search can be done just one-off to build the compatibility
> > > > database for all assignable devices on each node, then it might be
> > > > still tenable in datacenter?  
> > > 
> > > 
> > > I'm not sure what "one-off" means relative to this discussion.  Is this
> > > trying to argue that if it's a disturbingly heavyweight operation, but
> > > a management tool only needs to do it once, it's ok?  We should really  
> > 
> > yes
> >   
> > > be including openstack and ovirt folks in any discussion about what
> > > might be acceptable across a datacenter.  I can sometimes get away with
> > > representing what might be feasible for libvirt, but this is the sort
> > > of knowledge and policy decision that would occur above libvirt.  
> > 
> > Agree. and since this is more about general migration compatibility,
> > let's start new thread and involve openstack/ovirt guys. Yan, can you
> > initiate this?
> >  
> sure.
> hi Alex,
> I'm not sure if below mailling lists are enough and accurate,
> do you know what extra people and lists I need to involve in?
> 
> devel@ovirt.org, openstack-discuss@lists.openstack.org,
> libvir-list@redhat.com

You could also include

Daniel P. Berrangé <berrange@redhat.com>
Sean Mooney <smooney@redhat.com>

> BTW, I found a page about live migration of SRIOV devices in openstack.
> https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/libvirt-neutron-sriov-livemigration.html

Sean, above, is involved with that specification.  AFAIK the only
current live migration of SR-IOV devices involve failover and hotplug
trickery.  Thanks,

Alex