Re: [PATCH v2 2/5] Mini-OS: get own domid

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.11.2023 11:20, Julien Grall wrote:
> Hi,
> 
> On 13/11/2023 09:28, Jan Beulich wrote:
>> On 13.11.2023 10:12, Julien Grall wrote:
>>>
>>>
>>> On 13/11/2023 07:37, Jan Beulich wrote:
>>>> On 10.11.2023 18:38, Julien Grall wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 10/11/2023 12:44, Jan Beulich wrote:
>>>>>> On 10.11.2023 13:23, Roger Pau Monné wrote:
>>>>>>> On Fri, Nov 10, 2023 at 12:34:32PM +0100, Juergen Gross wrote:
>>>>>>>> Get the own domid via creation of a temporary event channel. There is
>>>>>>>> no "official" way to read the own domid in PV guests, so use the event
>>>>>>>> channel interface to get it:
>>>>>>>>
>>>>>>>> - allocate an unbound event channel specifying DOMID_SELF for the
>>>>>>>>      other end
>>>>>>>>
>>>>>>>> - read the event channel status which will contain the own domid in
>>>>>>>>      unbound.dom
>>>>>>>>
>>>>>>>> - close the event channel
>>>>>>>
>>>>>>> Should we look into introducing a way to expose the domid, so that in
>>>>>>> the future we might not need to resort to this workarounds to get the
>>>>>>> domid?
>>>>>>>
>>>>>>> Maybe in the PV-specific cpuid leaf?  It's a shame we didn't put it in
>>>>>>> a non-HVM specific leaf when it was made available to HVM for pvshim
>>>>>>> reasons.
>>>>>>
>>>>>> Couldn't we retroactively generalize the type-agnostic parts of that
>>>>>> leaf?
>>>>>
>>>>> This would only work for x86. I think we want to have a generic
>>>>> hypercalls so it can be used by all arch.
>>>>
>>>> Hmm, yes, perhaps. Otoh it would seem desirable to me if arch-es also
>>>> provided some extension to an arch-natural way of feature detection
>>>> (which CPUID is on x86), without the need to invoke any hypercalls.
>>>
>>> For Arm, I can't really think of anything other than hvc/smc which are
>>> used for calls to the hypervisor/monitor (so basically hypercalls).
>>>
>>> Please suggest if you have a better idea.
>>
>> I don't know enough Arm to properly suggest something. Arm64 has various
>> id_* system registers, so I would be wondering whether having a properly
>> virtual one reserved in system register space couldn't do the trick.
> 
> AFAIK there are none available. But if such exists, then I don't see how 
> that would suit with my requests to have an arch-agnostic approach.
> 
> Each architecture would need to have to provide a way to expose those 
> values.

Right. Just like hardware of each architecture also surfaces its
capabilities in architecture-specific ways.

> At which point, why not using hypercall? What's wrong with it?

There's nothing "wrong" with hypercalls, they're just less natural to use
in certain cases. Plus of course using them may require setup inside the
guest.

I'm tempted to ask a counter question: Do you consider it a mistake that
on x86 certain capability information is surfaced as CPUID data?

Jan