* Cornelia Huck (cohuck@xxxxxxxxxx) wrote: > On Tue, 14 May 2019 03:47:36 -0400 > Yan Zhao <yan.y.zhao@xxxxxxxxx> wrote: > > > On Tue, May 14, 2019 at 03:43:44PM +0800, Erik Skultety wrote: > > > On Tue, May 14, 2019 at 03:32:19AM -0400, Yan Zhao wrote: > > > > On Tue, May 14, 2019 at 03:20:40PM +0800, Erik Skultety wrote: > > > > > > That said, from libvirt POV as a consumer, I'd expect there to be truly only 2 > > > > > errors (I believe Alex has mentioned something similar in one of his responses > > > > > in one of the threads): > > > > > a) read error indicating that an mdev type doesn't support migration > > > > > - I assume if one type doesn't support migration, none of the other > > > > > types exposed on the parent device do, is that a fair assumption? > > Probably; but there might be cases where the migratability depends not > on the device type, but how the partitioning has been done... or is > that too contrived? > > > > > > b) write error indicating that the mdev types are incompatible for > > > > > migration > > > > > > > > > > Regards, > > > > > Erik > > > > Thanks for this explanation. > > > > so, can we arrive at below agreements? > > > > > > > > 1. "not to define the specific errno returned for a specific situation, > > > > let the vendor driver decide, userspace simply needs to know that an errno on > > > > read indicates the device does not support migration version comparison and > > > > that an errno on write indicates the devices are incompatible or the target > > > > doesn't support migration versions. " > > > > 2. vendor driver should log detailed error reasons in kernel log. > > > > > > That would be my take on this, yes, but I open to hear any other suggestions and > > > ideas I couldn't think of as well. > > So, read to find out whether migration is supported at all, write to > find out whether it is supported for that concrete pairing is > reasonable for libvirt? > > > > > > > Erik > > got it. thanks a lot! > > > > hi Cornelia and Dave, > > do you also agree on: > > 1. "not to define the specific errno returned for a specific situation, > > let the vendor driver decide, userspace simply needs to know that an errno on > > read indicates the device does not support migration version comparison and > > that an errno on write indicates the devices are incompatible or the target > > doesn't support migration versions. " > > 2. vendor driver should log detailed error reasons in kernel log. > > Two questions: > - How reasonable is it to refer to the system log in order to find out > what exactly went wrong? > - If detailed error reporting is basically done to the syslog, do > different error codes still provide useful information? Or should the > vendor driver decide what it wants to do? I don't see error codes as being that helpful; if we can't actually get an error message back up the stack (which was my preference), then I guess syslog is as good as it will get. Dave -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
