On Mon Dec 16, 2024 at 12:03 PM GMT, Jan Beulich wrote:
> On 16.12.2024 13:00, Alejandro Vallejo wrote:
> > On Mon Dec 9, 2024 at 4:30 PM GMT, Jan Beulich wrote:
> >> On 05.11.2024 15:33, Alejandro Vallejo wrote:
> >>> --- a/xen/arch/x86/xstate.c
> >>> +++ b/xen/arch/x86/xstate.c
> >>> @@ -1022,9 +1022,10 @@ int handle_xsetbv(u32 index, u64 new_bv)
> >>>
> >>> uint64_t read_bndcfgu(void)
> >>> {
> >>> + uint64_t bndcfgu = 0;
> >>> unsigned long cr0 = read_cr0();
> >>> - struct xsave_struct *xstate
> >>> - = idle_vcpu[smp_processor_id()]->arch.xsave_area;
> >>> + struct vcpu *v = idle_vcpu[smp_processor_id()];
> >>
> >> Can this be pointer-to-const? Certainly right now, so the question is
> >> rather
> >> meant to be forward looking.
> >>
> >>> + struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v);
> >>
> >> This certainly can be pointer-to-const, just like ...
> >>
> >>> const struct xstate_bndcsr *bndcsr;
> >>
> >> ... this is.
> >
> > Yes, those retained non-const because of the now missing patch to zero-out
> > bndcfgu.
>
> I'm afraid this reply is ambiguous as to what's going to happen in the next
> version. I can read both "will change" and "needs to stay" into it.
>
> Jan
It was an answer to "Can this be pointer to const?". Yes, I'll put the const
back.
Cheers,
Alejandro
