On 14/01/2020 17:30, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 17/20] tools/libx[cl]: Plumb static_data_done()
> up into libxl"):
>> /* callbacks provided by xc_domain_restore */
>> struct restore_callbacks {
>> + /*
>> + * Called once the STATIC_DATA_END record has been received/inferred.
>> + * Passes in the blocks of static data which have not been received,
>> which
>> + * the higher level toolstack must provide backwards compatibility for.
>> + */
>> +#define XGR_SDD_MISSING_CPUID (1 << 0)
>> +#define XGR_SDD_MISSING_MSR (1 << 1)
>> + int (*static_data_done)(unsigned int missing, void *data);
> This is a bit weird, isn't it ? I mean: if these blocks of data *are*
> received then libxc handles them; but if they are not, libxc's caller
> must do so.
>
> I appreciate that the interface at the top of libxc is already rather
> complex and uneven but this doesn't seem to be helping...
There are several things going on here.
One is the control flow marker of "We reached the end of the static
data". A higher level toolstack needs to know this unconditionally,
which is why the callback is mandatory.
For v2 compatibility, its callers cope with "this is where an end of
static data would be in a v3 stream", but that abstracted away so the
higher level toolstack doesn't know or need to care.
The missing parameter is "p.s. here are the things we were expecting but
didn't get - you need to pick up the pieces". For now, it is synonymous
with "here is a v2 stream without CPUID data", but that won't be
accurate in the future if/when new static data records get retrofitted.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
