qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: device compatibility interface for live migration with assigned devi


From: Sean Mooney
Subject: Re: device compatibility interface for live migration with assigned devices
Date: Fri, 28 Aug 2020 15:04:12 +0100

On Fri, 2020-08-28 at 15:47 +0200, Cornelia Huck wrote:
> On Wed, 26 Aug 2020 14:41:17 +0800
> Yan Zhao <yan.y.zhao@intel.com> wrote:
> 
> > previously, we want to regard the two mdevs created with dsa-1dwq x 30 and
> > dsa-2dwq x 15 as compatible, because the two mdevs consist equal resources.
> > 
> > But, as it's a burden to upper layer, we agree that if this condition
> > happens, we still treat the two as incompatible.
> > 
> > To fix it, either the driver should expose dsa-1dwq only, or the target
> > dsa-2dwq needs to be destroyed and reallocated via dsa-1dwq x 30.
> 
> AFAIU, these are mdev types, aren't they? So, basically, any management
> software needs to take care to use the matching mdev type on the target
> system for device creation?

or just do the simple thing of use the same mdev type on the source and dest.
matching mdevtypes is not nessiarly trivial. we could do that but we woudl have
to do that in python rather then sql so it would be slower to do at least today.

we dont currently have the ablity to say the resouce provider must have 1 of 
these
set of traits. just that we must have a specific trait. this is a feature we 
have
disucssed a couple of times and delayed untill we really really need it but its 
not out
of the question that we could add it for this usecase. i suspect however we 
would do exact
match first and explore this later after the inital mdev migration works.

by the way i was looking at some vdpa reslated matiail today and noticed vdpa 
devices are nolonger
usign mdevs and and now use a vhost chardev so i guess we will need a 
completely seperate mechanioum
for vdpa vs mdev migration as a result. that is rather unfortunet but i guess 
that is life.
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]