| Message ID | 20231006130059.97700-3-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | domain: followup for phys address mapping series | expand |
On 06/10/2023 2:00 pm, Roger Pau Monne wrote: > diff --git a/xen/include/public/features.h b/xen/include/public/features.h > index d2a9175aae67..22713a51b520 100644 > --- a/xen/include/public/features.h > +++ b/xen/include/public/features.h > @@ -111,6 +111,15 @@ > #define XENFEAT_not_direct_mapped 16 > #define XENFEAT_direct_mapped 17 > > +/* > + * Signal whether the domain is permitted to use the following hypercalls: > + * > + * VCPUOP_register_runstate_phys_area > + * VCPUOP_register_vcpu_time_phys_area > + */ > +#define XENFEAT_runstate_phys_area 18 > +#define XENFEAT_vcpu_time_phys_area 19 > + > #define XENFEAT_NR_SUBMAPS 1 > > #endif /* __XEN_PUBLIC_FEATURES_H__ */ > diff --git a/xen/include/public/vcpu.h b/xen/include/public/vcpu.h > index 8fb0bd1b6c03..03b031a3e557 100644 > --- a/xen/include/public/vcpu.h > +++ b/xen/include/public/vcpu.h > @@ -236,6 +236,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_register_time_memory_area_t); > * Note that the area registered via VCPUOP_register_runstate_memory_area will > * be updated in the same manner as the one registered via virtual address PLUS > * VMASST_TYPE_runstate_update_flag engaged by the domain. > + * > + * XENFEAT_{runstate,vcpu_time}_phys_area feature bits signal if the domain is > + * permitted the usage of the hypercalls. > */ > #define VCPUOP_register_runstate_phys_area 14 > #define VCPUOP_register_vcpu_time_phys_area 15 For both of these, I'd suggest s/permitted/able/. For older versions of Xen which don't advertise the XENFEAT, it's a matter of capability, not permission. Otherwise, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> and I'm happy to adjust on commit to save sending out a v3. Thanks, ~Andrew
On Fri, Oct 06, 2023 at 02:05:18PM +0100, Andrew Cooper wrote: > On 06/10/2023 2:00 pm, Roger Pau Monne wrote: > > diff --git a/xen/include/public/features.h b/xen/include/public/features.h > > index d2a9175aae67..22713a51b520 100644 > > --- a/xen/include/public/features.h > > +++ b/xen/include/public/features.h > > @@ -111,6 +111,15 @@ > > #define XENFEAT_not_direct_mapped 16 > > #define XENFEAT_direct_mapped 17 > > > > +/* > > + * Signal whether the domain is permitted to use the following hypercalls: > > + * > > + * VCPUOP_register_runstate_phys_area > > + * VCPUOP_register_vcpu_time_phys_area > > + */ > > +#define XENFEAT_runstate_phys_area 18 > > +#define XENFEAT_vcpu_time_phys_area 19 > > + > > #define XENFEAT_NR_SUBMAPS 1 > > > > #endif /* __XEN_PUBLIC_FEATURES_H__ */ > > diff --git a/xen/include/public/vcpu.h b/xen/include/public/vcpu.h > > index 8fb0bd1b6c03..03b031a3e557 100644 > > --- a/xen/include/public/vcpu.h > > +++ b/xen/include/public/vcpu.h > > @@ -236,6 +236,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_register_time_memory_area_t); > > * Note that the area registered via VCPUOP_register_runstate_memory_area will > > * be updated in the same manner as the one registered via virtual address PLUS > > * VMASST_TYPE_runstate_update_flag engaged by the domain. > > + * > > + * XENFEAT_{runstate,vcpu_time}_phys_area feature bits signal if the domain is > > + * permitted the usage of the hypercalls. > > */ > > #define VCPUOP_register_runstate_phys_area 14 > > #define VCPUOP_register_vcpu_time_phys_area 15 > > For both of these, I'd suggest s/permitted/able/. For older versions of > Xen which don't advertise the XENFEAT, it's a matter of capability, not > permission. > > Otherwise, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> and > I'm happy to adjust on commit to save sending out a v3. TBH I've used permitted because that's the wording you used in your reply to v1, I'm perfectly fine with switching to able. https://lore.kernel.org/xen-devel/ac4842a9-7f62-4c64-9a3a-2ec2b1e97699@citrix.com/ Thanks, Roger.
Hi, > On Oct 6, 2023, at 21:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > > On 06/10/2023 2:00 pm, Roger Pau Monne wrote: >> diff --git a/xen/include/public/features.h b/xen/include/public/features.h >> index d2a9175aae67..22713a51b520 100644 >> --- a/xen/include/public/features.h >> +++ b/xen/include/public/features.h >> @@ -111,6 +111,15 @@ >> #define XENFEAT_not_direct_mapped 16 >> #define XENFEAT_direct_mapped 17 >> >> +/* >> + * Signal whether the domain is permitted to use the following hypercalls: >> + * >> + * VCPUOP_register_runstate_phys_area >> + * VCPUOP_register_vcpu_time_phys_area >> + */ >> +#define XENFEAT_runstate_phys_area 18 >> +#define XENFEAT_vcpu_time_phys_area 19 >> + >> #define XENFEAT_NR_SUBMAPS 1 >> >> #endif /* __XEN_PUBLIC_FEATURES_H__ */ >> diff --git a/xen/include/public/vcpu.h b/xen/include/public/vcpu.h >> index 8fb0bd1b6c03..03b031a3e557 100644 >> --- a/xen/include/public/vcpu.h >> +++ b/xen/include/public/vcpu.h >> @@ -236,6 +236,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_register_time_memory_area_t); >> * Note that the area registered via VCPUOP_register_runstate_memory_area will >> * be updated in the same manner as the one registered via virtual address PLUS >> * VMASST_TYPE_runstate_update_flag engaged by the domain. >> + * >> + * XENFEAT_{runstate,vcpu_time}_phys_area feature bits signal if the domain is >> + * permitted the usage of the hypercalls. >> */ >> #define VCPUOP_register_runstate_phys_area 14 >> #define VCPUOP_register_vcpu_time_phys_area 15 > > For both of these, I'd suggest s/permitted/able/. For older versions of > Xen which don't advertise the XENFEAT, it's a matter of capability, not > permission. > > Otherwise, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> and > I'm happy to adjust on commit to save sending out a v3. Release-acked-by: Henry Wang <Henry.Wang@arm.com> Kind regards, Henry > > Thanks, > > ~Andrew
On 06/10/2023 2:19 pm, Roger Pau Monné wrote: > On Fri, Oct 06, 2023 at 02:05:18PM +0100, Andrew Cooper wrote: >> On 06/10/2023 2:00 pm, Roger Pau Monne wrote: >>> diff --git a/xen/include/public/features.h b/xen/include/public/features.h >>> index d2a9175aae67..22713a51b520 100644 >>> --- a/xen/include/public/features.h >>> +++ b/xen/include/public/features.h >>> @@ -111,6 +111,15 @@ >>> #define XENFEAT_not_direct_mapped 16 >>> #define XENFEAT_direct_mapped 17 >>> >>> +/* >>> + * Signal whether the domain is permitted to use the following hypercalls: >>> + * >>> + * VCPUOP_register_runstate_phys_area >>> + * VCPUOP_register_vcpu_time_phys_area >>> + */ >>> +#define XENFEAT_runstate_phys_area 18 >>> +#define XENFEAT_vcpu_time_phys_area 19 >>> + >>> #define XENFEAT_NR_SUBMAPS 1 >>> >>> #endif /* __XEN_PUBLIC_FEATURES_H__ */ >>> diff --git a/xen/include/public/vcpu.h b/xen/include/public/vcpu.h >>> index 8fb0bd1b6c03..03b031a3e557 100644 >>> --- a/xen/include/public/vcpu.h >>> +++ b/xen/include/public/vcpu.h >>> @@ -236,6 +236,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_register_time_memory_area_t); >>> * Note that the area registered via VCPUOP_register_runstate_memory_area will >>> * be updated in the same manner as the one registered via virtual address PLUS >>> * VMASST_TYPE_runstate_update_flag engaged by the domain. >>> + * >>> + * XENFEAT_{runstate,vcpu_time}_phys_area feature bits signal if the domain is >>> + * permitted the usage of the hypercalls. >>> */ >>> #define VCPUOP_register_runstate_phys_area 14 >>> #define VCPUOP_register_vcpu_time_phys_area 15 >> For both of these, I'd suggest s/permitted/able/. For older versions of >> Xen which don't advertise the XENFEAT, it's a matter of capability, not >> permission. >> >> Otherwise, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> and >> I'm happy to adjust on commit to save sending out a v3. > TBH I've used permitted because that's the wording you used in your > reply to v1, I'm perfectly fine with switching to able. > > https://lore.kernel.org/xen-devel/ac4842a9-7f62-4c64-9a3a-2ec2b1e97699@citrix.com/ Yeah, sorry. I didn't think fully before making the suggestion. I was mainly looking to avoid saying "what the hypervisor is capable of" :) ~Andrew
On 06.10.2023 15:00, Roger Pau Monne wrote: > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -1580,6 +1580,10 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) > { > struct vcpu_register_time_memory_area area; > > + rc = -ENOSYS; > + if ( 0 /* TODO: Dom's XENFEAT_vcpu_time_phys_area setting */ ) > + break; > + > rc = -EFAULT; > if ( copy_from_guest(&area.addr.p, arg, 1) ) > break; > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -1998,6 +1998,10 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) > { > struct vcpu_register_runstate_memory_area area; > > + rc = -ENOSYS; > + if ( 0 /* TODO: Dom's XENFEAT_runstate_phys_area setting */ ) > + break; > + > rc = -EFAULT; > if ( copy_from_guest(&area.addr.p, arg, 1) ) > break; ENOSYS is not correct here. EPERM, EACCES, or EOPNOTSUPP would all be more correct. > --- a/xen/common/kernel.c > +++ b/xen/common/kernel.c > @@ -607,7 +607,11 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) > switch ( fi.submap_idx ) > { > case 0: > - fi.submap = (1U << XENFEAT_memory_op_vnode_supported); > + fi.submap = (1U << XENFEAT_memory_op_vnode_supported) | > +#ifdef CONFIG_X86 > + (1U << XENFEAT_vcpu_time_phys_area) | > +#endif > + (1U << XENFEAT_runstate_phys_area); No provisions here for the "disabled for this domain" case? Jan
On Mon, Oct 16, 2023 at 02:35:44PM +0200, Jan Beulich wrote: > On 06.10.2023 15:00, Roger Pau Monne wrote: > > --- a/xen/arch/x86/domain.c > > +++ b/xen/arch/x86/domain.c > > @@ -1580,6 +1580,10 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) > > { > > struct vcpu_register_time_memory_area area; > > > > + rc = -ENOSYS; > > + if ( 0 /* TODO: Dom's XENFEAT_vcpu_time_phys_area setting */ ) > > + break; > > + > > rc = -EFAULT; > > if ( copy_from_guest(&area.addr.p, arg, 1) ) > > break; > > --- a/xen/common/domain.c > > +++ b/xen/common/domain.c > > @@ -1998,6 +1998,10 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) > > { > > struct vcpu_register_runstate_memory_area area; > > > > + rc = -ENOSYS; > > + if ( 0 /* TODO: Dom's XENFEAT_runstate_phys_area setting */ ) > > + break; > > + > > rc = -EFAULT; > > if ( copy_from_guest(&area.addr.p, arg, 1) ) > > break; > > ENOSYS is not correct here. EPERM, EACCES, or EOPNOTSUPP would all be more > correct. I don't think so, common_vcpu_op() default case does return -ENOSYS, and the point of this path is to mimic the behavior of an hypervisor that doesn't have the hypercalls implemented, hence -ENOSYS is the correct behavior. > > > --- a/xen/common/kernel.c > > +++ b/xen/common/kernel.c > > @@ -607,7 +607,11 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) > > switch ( fi.submap_idx ) > > { > > case 0: > > - fi.submap = (1U << XENFEAT_memory_op_vnode_supported); > > + fi.submap = (1U << XENFEAT_memory_op_vnode_supported) | > > +#ifdef CONFIG_X86 > > + (1U << XENFEAT_vcpu_time_phys_area) | > > +#endif > > + (1U << XENFEAT_runstate_phys_area); > > No provisions here for the "disabled for this domain" case? TBH I'm not sure the `if ( 0` above are of much help, if we ever want to provide toolstack overwrites for those it's fairly easy to spot the paths that need to be patched anyway. Thanks, Roger.
On 16.10.2023 15:00, Roger Pau Monné wrote: > On Mon, Oct 16, 2023 at 02:35:44PM +0200, Jan Beulich wrote: >> On 06.10.2023 15:00, Roger Pau Monne wrote: >>> --- a/xen/common/domain.c >>> +++ b/xen/common/domain.c >>> @@ -1998,6 +1998,10 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) >>> { >>> struct vcpu_register_runstate_memory_area area; >>> >>> + rc = -ENOSYS; >>> + if ( 0 /* TODO: Dom's XENFEAT_runstate_phys_area setting */ ) >>> + break; >>> + >>> rc = -EFAULT; >>> if ( copy_from_guest(&area.addr.p, arg, 1) ) >>> break; >> >> ENOSYS is not correct here. EPERM, EACCES, or EOPNOTSUPP would all be more >> correct. > > I don't think so, common_vcpu_op() default case does return -ENOSYS, > and the point of this path is to mimic the behavior of an hypervisor > that doesn't have the hypercalls implemented, hence -ENOSYS is the > correct behavior. Besides that other ENOSYS being wrong too, I question such "mimic-ing". Imo error codes should be the best representation of the real reason, not be arbitrarily "made up". Jan
On Mon, Oct 16, 2023 at 03:58:22PM +0200, Jan Beulich wrote: > On 16.10.2023 15:00, Roger Pau Monné wrote: > > On Mon, Oct 16, 2023 at 02:35:44PM +0200, Jan Beulich wrote: > >> On 06.10.2023 15:00, Roger Pau Monne wrote: > >>> --- a/xen/common/domain.c > >>> +++ b/xen/common/domain.c > >>> @@ -1998,6 +1998,10 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) > >>> { > >>> struct vcpu_register_runstate_memory_area area; > >>> > >>> + rc = -ENOSYS; > >>> + if ( 0 /* TODO: Dom's XENFEAT_runstate_phys_area setting */ ) > >>> + break; > >>> + > >>> rc = -EFAULT; > >>> if ( copy_from_guest(&area.addr.p, arg, 1) ) > >>> break; > >> > >> ENOSYS is not correct here. EPERM, EACCES, or EOPNOTSUPP would all be more > >> correct. > > > > I don't think so, common_vcpu_op() default case does return -ENOSYS, > > and the point of this path is to mimic the behavior of an hypervisor > > that doesn't have the hypercalls implemented, hence -ENOSYS is the > > correct behavior. > > Besides that other ENOSYS being wrong too, I question such "mimic-ing". > Imo error codes should be the best representation of the real reason, > not be arbitrarily "made up". The point is for the guest to not take any action that it won't take on an hypervisor that doesn't have the hypercalls implemented, and the only way to be sure about that is to return the same exact error code. Thanks, Roger.
On 16.10.2023 16:01, Roger Pau Monné wrote: > On Mon, Oct 16, 2023 at 03:58:22PM +0200, Jan Beulich wrote: >> On 16.10.2023 15:00, Roger Pau Monné wrote: >>> On Mon, Oct 16, 2023 at 02:35:44PM +0200, Jan Beulich wrote: >>>> On 06.10.2023 15:00, Roger Pau Monne wrote: >>>>> --- a/xen/common/domain.c >>>>> +++ b/xen/common/domain.c >>>>> @@ -1998,6 +1998,10 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) >>>>> { >>>>> struct vcpu_register_runstate_memory_area area; >>>>> >>>>> + rc = -ENOSYS; >>>>> + if ( 0 /* TODO: Dom's XENFEAT_runstate_phys_area setting */ ) >>>>> + break; >>>>> + >>>>> rc = -EFAULT; >>>>> if ( copy_from_guest(&area.addr.p, arg, 1) ) >>>>> break; >>>> >>>> ENOSYS is not correct here. EPERM, EACCES, or EOPNOTSUPP would all be more >>>> correct. >>> >>> I don't think so, common_vcpu_op() default case does return -ENOSYS, >>> and the point of this path is to mimic the behavior of an hypervisor >>> that doesn't have the hypercalls implemented, hence -ENOSYS is the >>> correct behavior. >> >> Besides that other ENOSYS being wrong too, I question such "mimic-ing". >> Imo error codes should be the best representation of the real reason, >> not be arbitrarily "made up". > > The point is for the guest to not take any action that it won't take > on an hypervisor that doesn't have the hypercalls implemented, and the > only way to be sure about that is to return the same exact error code. I don't follow this kind of reasoning. Why would a guest, whose code to use the new sub-functions has to be newly written, key its decision to the specific error code it gets, when at the same time you expose feature bits that it can use to decide whether to invoke the hypercall in the first place. Jan
On Mon, Oct 16, 2023 at 04:04:34PM +0200, Jan Beulich wrote: > On 16.10.2023 16:01, Roger Pau Monné wrote: > > On Mon, Oct 16, 2023 at 03:58:22PM +0200, Jan Beulich wrote: > >> On 16.10.2023 15:00, Roger Pau Monné wrote: > >>> On Mon, Oct 16, 2023 at 02:35:44PM +0200, Jan Beulich wrote: > >>>> On 06.10.2023 15:00, Roger Pau Monne wrote: > >>>>> --- a/xen/common/domain.c > >>>>> +++ b/xen/common/domain.c > >>>>> @@ -1998,6 +1998,10 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) > >>>>> { > >>>>> struct vcpu_register_runstate_memory_area area; > >>>>> > >>>>> + rc = -ENOSYS; > >>>>> + if ( 0 /* TODO: Dom's XENFEAT_runstate_phys_area setting */ ) > >>>>> + break; > >>>>> + > >>>>> rc = -EFAULT; > >>>>> if ( copy_from_guest(&area.addr.p, arg, 1) ) > >>>>> break; > >>>> > >>>> ENOSYS is not correct here. EPERM, EACCES, or EOPNOTSUPP would all be more > >>>> correct. > >>> > >>> I don't think so, common_vcpu_op() default case does return -ENOSYS, > >>> and the point of this path is to mimic the behavior of an hypervisor > >>> that doesn't have the hypercalls implemented, hence -ENOSYS is the > >>> correct behavior. > >> > >> Besides that other ENOSYS being wrong too, I question such "mimic-ing". > >> Imo error codes should be the best representation of the real reason, > >> not be arbitrarily "made up". > > > > The point is for the guest to not take any action that it won't take > > on an hypervisor that doesn't have the hypercalls implemented, and the > > only way to be sure about that is to return the same exact error code. > > I don't follow this kind of reasoning. Why would a guest, whose code to > use the new sub-functions has to be newly written, key its decision to > the specific error code it gets, when at the same time you expose > feature bits that it can use to decide whether to invoke the hypercall > in the first place. Because we don't control all possible guest implementations out there. AIUI the point of introducing a way to disable the newly added hypercalls is to make the interface between a Xen previous to the introduction of the hypercalls vs a Xen that has the hypercalls disabled equal, and that requires returning the same error code IMO, or else interfaces are not equal. Thanks, Roger.
diff --git a/CHANGELOG.md b/CHANGELOG.md index e33cf4e1b113..47ea9e275462 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -31,6 +31,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - Add Intel Hardware P-States (HWP) cpufreq driver. - On Arm, experimental support for dynamic addition/removal of Xen device tree nodes using a device tree overlay binary (.dtbo). + - Introduce two new hypercalls to map the vCPU runstate and time areas by + physical rather than linear/virtual addresses. ### Removed - On x86, the "pku" command line option has been removed. It has never diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 8e0af2278104..8d3d52034a6d 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1580,6 +1580,10 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) { struct vcpu_register_time_memory_area area; + rc = -ENOSYS; + if ( 0 /* TODO: Dom's XENFEAT_vcpu_time_phys_area setting */ ) + break; + rc = -EFAULT; if ( copy_from_guest(&area.addr.p, arg, 1) ) break; diff --git a/xen/common/domain.c b/xen/common/domain.c index 1468638ade8b..8f9ab01c0cb7 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -1998,6 +1998,10 @@ long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) { struct vcpu_register_runstate_memory_area area; + rc = -ENOSYS; + if ( 0 /* TODO: Dom's XENFEAT_runstate_phys_area setting */ ) + break; + rc = -EFAULT; if ( copy_from_guest(&area.addr.p, arg, 1) ) break; diff --git a/xen/common/kernel.c b/xen/common/kernel.c index 52aa28762782..b6302e44b34e 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -607,7 +607,11 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) switch ( fi.submap_idx ) { case 0: - fi.submap = (1U << XENFEAT_memory_op_vnode_supported); + fi.submap = (1U << XENFEAT_memory_op_vnode_supported) | +#ifdef CONFIG_X86 + (1U << XENFEAT_vcpu_time_phys_area) | +#endif + (1U << XENFEAT_runstate_phys_area); if ( VM_ASSIST(d, pae_extended_cr3) ) fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb); if ( paging_mode_translate(d) ) diff --git a/xen/include/public/features.h b/xen/include/public/features.h index d2a9175aae67..22713a51b520 100644 --- a/xen/include/public/features.h +++ b/xen/include/public/features.h @@ -111,6 +111,15 @@ #define XENFEAT_not_direct_mapped 16 #define XENFEAT_direct_mapped 17 +/* + * Signal whether the domain is permitted to use the following hypercalls: + * + * VCPUOP_register_runstate_phys_area + * VCPUOP_register_vcpu_time_phys_area + */ +#define XENFEAT_runstate_phys_area 18 +#define XENFEAT_vcpu_time_phys_area 19 + #define XENFEAT_NR_SUBMAPS 1 #endif /* __XEN_PUBLIC_FEATURES_H__ */ diff --git a/xen/include/public/vcpu.h b/xen/include/public/vcpu.h index 8fb0bd1b6c03..03b031a3e557 100644 --- a/xen/include/public/vcpu.h +++ b/xen/include/public/vcpu.h @@ -236,6 +236,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_register_time_memory_area_t); * Note that the area registered via VCPUOP_register_runstate_memory_area will * be updated in the same manner as the one registered via virtual address PLUS * VMASST_TYPE_runstate_update_flag engaged by the domain. + * + * XENFEAT_{runstate,vcpu_time}_phys_area feature bits signal if the domain is + * permitted the usage of the hypercalls. */ #define VCPUOP_register_runstate_phys_area 14 #define VCPUOP_register_vcpu_time_phys_area 15
XENFEAT_runstate_phys_area is exposed to all architectures, while XENFEAT_vcpu_time_phys_area is currently only implemented for x86, and hence the feature flag is also only exposed on x86. Additionally add dummy guards with TODOs in the respective hypercall implementations, to signal the intention to control the availability of those hypercalls on a guest-by-guest basis from the toolstack. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- Changes since v1: - Adjust comments, and add new one in vcpu.h - Add dummy guard with TDOD in hypercall implementations. --- CHANGELOG.md | 2 ++ xen/arch/x86/domain.c | 4 ++++ xen/common/domain.c | 4 ++++ xen/common/kernel.c | 6 +++++- xen/include/public/features.h | 9 +++++++++ xen/include/public/vcpu.h | 3 +++ 6 files changed, 27 insertions(+), 1 deletion(-)