| Message ID | 20231110113435.22609-3-jgross@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Mini-OS: preparations for 9pfs in xenstore-stubdom | expand |
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. Thanks, Roger.
On 10.11.23 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. I'm in favor of an "official" way to get the domid. As this might be needed on other architectures, too, I guess this will most likely require a (stable) hypercall. As soon as this is available, I'd be happy to change Mini-OS again to use the new hypercall. In order not to block my Xenstore-stubdom series, I'd like to use the hack of this patch until then. Maybe I should rename the function to get_own_domid() in order to avoid having to change the user(s). Juergen
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? Jan
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. Cheers,
Hi, On 10/11/2023 11:34, 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 > > Signed-off-by: Juergen Gross <jgross@suse.com > --- > V2: > - new patch > Signed-off-by: Juergen Gross <jgross@suse.com> > --- > events.c | 32 ++++++++++++++++++++++++++++++++ > include/events.h | 2 ++ > 2 files changed, 34 insertions(+) > > diff --git a/events.c b/events.c > index cdae90f4..af9f9f9e 100644 > --- a/events.c > +++ b/events.c > @@ -261,6 +261,38 @@ int evtchn_get_peercontext(evtchn_port_t local_port, char *ctx, int size) > return rc; > } > > +domid_t evtchn_get_domid(void) I think the function name should be generic so the caller doesn't need to be modified everytime the implementation is updated. How about get_domid()? Cheers,
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. Jan
On 10.11.23 18:40, Julien Grall wrote: > Hi, > > On 10/11/2023 11:34, 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 >> >> Signed-off-by: Juergen Gross <jgross@suse.com >> --- >> V2: >> - new patch >> Signed-off-by: Juergen Gross <jgross@suse.com> >> --- >> events.c | 32 ++++++++++++++++++++++++++++++++ >> include/events.h | 2 ++ >> 2 files changed, 34 insertions(+) >> >> diff --git a/events.c b/events.c >> index cdae90f4..af9f9f9e 100644 >> --- a/events.c >> +++ b/events.c >> @@ -261,6 +261,38 @@ int evtchn_get_peercontext(evtchn_port_t local_port, char >> *ctx, int size) >> return rc; >> } >> +domid_t evtchn_get_domid(void) > I think the function name should be generic so the caller doesn't need to be > modified everytime the implementation is updated. > > How about get_domid()? Fine with me. And I think it should have a prototype in include/lib.h Juergen
On Fri, Nov 10, 2023 at 01:44:50PM +0100, 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? Hm, maybe. In retrospective heaving leafs with PV or HVM only fields was not the best decision. It would have been better to have a generic leaf and then fields/flags that only apply to HVM or PV as necessary. Thanks, Roger.
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. Cheers,
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. (Clearly just one may not be sufficient long term, so there might be a scalability issue with such an approach. Unlike x86'es CPUID Arm's MRS, aiui, doesn't take inputs other than the coordinates of the system register to read.) Jan
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. At which point, why not using hypercall? What's wrong with it? Cheers,
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
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,
diff --git a/events.c b/events.c index cdae90f4..af9f9f9e 100644 --- a/events.c +++ b/events.c @@ -261,6 +261,38 @@ int evtchn_get_peercontext(evtchn_port_t local_port, char *ctx, int size) return rc; } +domid_t evtchn_get_domid(void) +{ + int rc; + domid_t domid = DOMID_INVALID; + evtchn_alloc_unbound_t op; + struct evtchn_status status; + struct evtchn_close close; + + op.dom = DOMID_SELF; + op.remote_dom = DOMID_SELF; + rc = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &op); + if ( rc ) + { + printk("ERROR: alloc_unbound failed with rc=%d", rc); + return domid; + } + + status.dom = DOMID_SELF; + status.port = op.port; + rc = HYPERVISOR_event_channel_op(EVTCHNOP_status, &status); + if ( rc ) + printk("ERROR: EVTCHNOP_status failed with rc=%d", rc); + else + domid = status.u.unbound.dom; + + close.port = op.port; + rc = HYPERVISOR_event_channel_op(EVTCHNOP_close, &close); + if ( rc ) + printk("WARN: close_port %d failed rc=%d. ignored\n", close.port, rc); + + return domid; +} /* * Local variables: diff --git a/include/events.h b/include/events.h index 705ad93a..87311481 100644 --- a/include/events.h +++ b/include/events.h @@ -57,4 +57,6 @@ static inline int notify_remote_via_evtchn(evtchn_port_t port) void fini_events(void); void suspend_events(void); +domid_t evtchn_get_domid(void); + #endif /* _EVENTS_H_ */