[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/5] Mini-OS: get own domid
Hi Jan,
On 13/11/2023 10:34, Jan Beulich wrote:
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?
For anything non-x86 specific yes. I think information like domid should
never have belonged to the CPUID and instead provided via an hypercalls.
Cheers,
--
Julien Grall
|
