On 07.08.2025 12:17, Andrew Cooper wrote: > On 07/08/2025 10:30 am, Jan Beulich wrote: >> On 06.08.2025 18:55, Andrew Cooper wrote: >>> --- a/xen/arch/x86/domctl.c >>> +++ b/xen/arch/x86/domctl.c >>> @@ -372,6 +372,14 @@ long arch_do_domctl( >>> struct page_info *page; >>> void *hypercall_page; >>> >>> + /* >>> + * Kernels should use the MSR method to get a hypercall page. The >>> + * toolstack should not be using the DOMCTL on itself. >>> + */ >>> + ret = -EINVAL; >>> + if ( d == currd ) >>> + break; >> Isn't what the comment says more generally true? To act on themselves, most >> domctl-s are inappropriate to use, I think. There are a few exceptions, where >> alternatives simply don't exist (and where, if a kernel wanted to use a >> domctl >> [or sysctl], it would need to go through hoops to deal with the interface >> versioning). Yet there's still the question of whether we shouldn't apply >> this >> restriction in a broader fashion. > > I'd go so far as to say that domctls ought to be restricted against > oneself, but it's not quite that easy. The majority of them already are > restricted because of domain/vcpu_pause(), but this is all ad-hoc. > > In principle, the control domain ought to be able to issue some of the > getter's on itself, but even that's inconsistent. get_dominfo is > permitted, but paging ops are not.
Hmm, right. And as said, there are a few which simply can't be done a non- domctl way. For the patch here: Reviewed-by: Jan Beulich <jbeul...@suse.com> > This is still a TBD for the stable tools interfaces. One option I am > considering was to split the opcode space by whether it was logically a > getter or setter, but I expect this does not work nicely if we also want > to retain backwards compatibility. I didn't expect we'd strive for (binary) backwards compatibility there. Source compatibility (i.e. merely requiring a re-compile) may be a goal, yet even there I wouldn't be certain. Jan
