Re: [PATCH v2 10/13] x86/mpx: Map/unmap xsave area in in read_bndcfgu()

["Alejandro Vallejo" <alejandro.vallejo@xxxxxxxxx>]

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