On Thu, 3 Mar 2022 19:49:51 -0400 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Thu, Mar 03, 2022 at 12:59:30PM -0700, Alex Williamson wrote: > > > > > If it's an abuse, then let's not do it. It was never my > > > > impression or intention > > So maybe abuse is the wrong word, but I don't want to mess up this > interface, which is intended to support real pre-copy devices, just > because devices that don't actually implement true precopy might do > silly things. Abuse... silly... either way, you're clearly not comfortable misusing PRE_COPY for this purpose. > The vGPU case you imagine will still work and qemu will switch to > STOP_COPY with a huge trailer and be slow. That is unavoidable and I > think it is fine. It's not really fine, but I think it will require some better defined interfaces and userspace support to give a clear picture of how data is partitioned. > > > > Furthermore the acc driver was explicitly directed not to indicate any degree > > > > of trailing data size in dirty_bytes, so while trailing data may be small for acc, > > > > this interface is explicitly not intended to provide any indication of trailing > > > > data size. Thanks, > > Yes, trailing data is not what this is for. This is only to help > decide when to switch from PRE_COPY to STOP_COPY. If the device can > execute STOP_COPY in the right time is a completely different > discussion/interface. > > > > Just to clarify, so the suggestion here is not to use PRE_COPY for compatibility > > > check at all and have a different proper infrastructure for that later as Jason > > > suggested? > > > > > > If so, I will remove this patch from this series and go back to the old revision > > > where we only have STOP_COPY and do the compatibility check during the final > > > load data operation. > > > > Hi Shameer, > > > > I think NVIDIA has a company long weekend, so I'm not sure how quickly > > we'll hear a rebuttal from Jason, but at this point I'd rather not > > move > > Yes, company long weekend. > > > forward with using PRE_COPY exclusively for compatibility testing if > > that is seen as an abuse of the interface, regardless of the size of > > the remaining STOP_COPY data. It might be most expedient to respin > > without PRE_COPY and we'll revisit methods to perform early > > compatibility testing in the future. Thanks, > > Shameerali has talked about wanting this compat check early from the > start, and done all the work to implement it. I think it is pretty > extreme to blow up his series over trailing_data. > > To me acc is fine to use it this way until we get a better solution > for compatability. We all need this, but I expect it to be complicated > to define. It was only in v7 that we made this switch to use PRE_COPY for this purpose, I wouldn't call it blowing up his series to step back and decide that was a poor choice and clearly v8 exists without this. This isn't the end of the discussion regarding early compatibility testing, but I'm not going to rush a PRE_COPY interface to support that early compatibility testing if we're not agreed that it's a valid use case, and not just a marginally acceptable one due to the trailing data being inconsequential. Let's focus on v8 and we can talk about further extensions later. Thanks, Alex
