Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.09.16 at 14:23, <ian.jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, 
> re qemu depriv)"):
>> Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, 
>> > So the actual hypercall call sites are all in-tree, in libxc.  If the
>> > format of the struct used for one of these guest handle slots changes,
>> > the same struct definition from the Xen headers is used both in the
>> > hypervisor and in libxc, and any incompatibility will be detected.
>> 
>> Wait, no. The guest handle slots in Jenny's proposal are basically
>> typeless:
> ...
>> Each sub-op implies a certain type for each handle slot it actually
>> uses.
> 
> Yes.  But in practice each such slot will in practice be accessed by
> using copy_dm_buffer_from_guest (or whatever) to copy it to a struct.
> It is intended that that same struct type will be used by libxc to
> populate the buffer.
> 
> Now, it is true that the compiler cannot check that the _same type_ is
> used in both places.  So, as I say:
> 
>    It's true that changes to the semantics of these slots (for example, a
>    change of a slot from "array of struct X" to "one struct Y") will not
>    be detected by the compiler.
> 
> But changes in the contents of the specific struct /will/ be spotted.

As long as it is a structure, yes. What about someone changing
uint64_t to xen_pfn_t?

>>  but I do think that it failed to point out this downside,
>> which imo moves the balance between the two proposals.
> 
> I'm afraid that I want to complain about this part of your approach to
> the thread, which I think is unduly harsh.
> 
> It is of course fair to point out a potential downside of the proposal,
> which wasn't clearly discussed in the discussion document.  And it is
> sensible for us all to consider that potential downside along with the
> others - as indeed I do above.
> 
> But I don't think it is really fair to criticise *the discussion
> document* (which is what Jennifer's email was) on the grounds that it
> ommitted to discuss a potential downside which its authors felt was
> minor[1].

Hmm, then I'm sorry if this came over the wrong way. I didn't
mean to criticize the document as a whole, or how it was written.

>  The purpose of a discussion document is to put forward a
> proposal and/or summarise previous discussion.  It is not required to
> be either neutral or, indeed, comprehensive - and even so, I found
> this one quite comprehensive.

Nevertheless I think such a document should be as honest as
possible wrt downsides of the (by the author(s)) preferred of
potentially multiple approaches. If some aspect is deemed minor,
I don't think it should be omitted (as then readers won't know
whether the aspect was considered at all), but mentioned and
stated to be believed to be minor.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel