Re: [PATCH] common: don't require use of DOMID_SELF

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/01/2021 15:30, Jan Beulich wrote:
> On 14.01.2021 15:43, Julien Grall wrote:
>> On 14/01/2021 14:02, Jan Beulich wrote:
>>> It's not overly difficult for a domain to figure out its ID, so
>>> requiring the use of DOMID_SELF in a very limited set of places isn't
>>> really helpful towards keeping the ID opaque to the guest.
>> So I agree that a domid can be figured out really easily today and in 
>> principle it would be fine to relax it.
>>
>> However, most of the guest OSes will care about running on older Xen 
>> versions. Therefore they are not going to be able to use this relaxation.
>>
>> So I am not entirely convinced the relaxation is actually worth it for 
>> existing hypercalls.
> I'm aware of the concern (Andrew has voiced it both here and in
> earlier contexts), but personally I think undue restrictions should
> not be retained just because they used to be enforced. We've gone
> this same route in a few other occasions not overly long ago, and
> iirc there are two patches going in a similar direction (different
> area of course) that I have still pending and which neither got
> ack-ed nor firmly rejected.
>
>> Anyway, if we decide to relax it, then I think we should update the 
>> public headers because an OS using this relaxation will not work on 
>> older Xen. A developper will not be able to know that without looking at 
>> the implementation.
> Well, DOMID_SELF exists because that's the preferred form to use.
> I can certainly add commentary, but it would feel a little odd to
> do so. To be honest I'm also not sure how helpful this is going to
> be, considering that consumers often have their own clones of our
> headers.

What I envisioned would be an RST ::warning in the "how to grant table"
guide for guest kernel developers in the sphinx docs.

Of course, this presupposed that such a doc exists, but its the only
useful place to put a note.

~Andrew