On 01/10/18 14:24, Ian Jackson wrote: > >>> handle_tsc_info has no code to verify that padding is indeed zero. Due >>> to the lack of a version field it is impossible to know if the sender >>> already has the newly introduced vtsc_tolerance field. In the worst >>> case the receiving domU will get an unemulated TSC. >> The lack of padding verification is deliberate, for forwards >> compatibility. Why does the sending code matter? One way or another, >> if the field is 0, the option wasn't present or wasn't configured. >> Neither of these situations affect the decision-making that the >> receiving side needs to perform. > We are talking here about an unused field that is (supposedly?) > always sent as zero ?
The spec requires the padding to always be sent as zero, and verify-stream-v2 does check the padding and object to non-zero values. libxc's write_tsc_info() has always fully zeroed the structure, and convert-legacy-stream also behaves the same way. However, I notice this change will break migration from pre 4.6 as write_libxc_tsc_info() now has a mismatched number of parameters to pack and throw an exception. > > AIUI: > > In the new code the semantics of zero is "do not allow any tolerance". > The old code handles this correctly. The issue is with migrations > from new code to old: the tolerance value will silently ignored. Migrating from new to old doesn't remotely work, and whether things explode or not is very context dependent. I'm not sure its worth caring about this case. We never have before. (Getting backwards migration working for emergency cases is on my TODO list, but it is dependent on rewriting the hypervisor interfaces for getting/setting guest state.) ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
