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
