| Message ID | 20241008083756.72829-1-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | x86/domctl: fix maximum number of MSRs in XEN_DOMCTL_{get,set}_vcpu_msrs | expand |
On 08.10.2024 10:37, Roger Pau Monne wrote: > Since the addition of the MSR_AMD64_DR{1-4}_ADDRESS_MASK MSRs to the > msrs_to_send array, the calculations for the maximum number of MSRs that > the hypercall can handle is off by 4. > > Remove the addition of 4 to the maximum number of MSRs that > XEN_DOMCTL_{set,get}_vcpu_msrs supports, as those are already part of the > array. > > A further adjustment could be to subtract 4 from the maximum size if the DBEXT > CPUID feature is not exposed to the guest, but guest_{rd,wr}msr() will already > perform that check when fetching or loading the MSRs. The maximum array is > used to indicate the caller of the buffer it needs to allocate in the get case, > and as an early input sanitation in the set case, using a buffer size slightly > lager than required is not an issue. > > Fixes: 86d47adcd3c4 ('x86/msr: Handle MSR_AMD64_DR{0-3}_ADDRESS_MASK in the new MSR infrastructure') > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> > --- > I'm tempted to just get rid of nr_msrs and use ARRAY_SIZE(msrs_to_send) > instead, but refrained from doing it. I think the variable would indeed better go away now. Yet that doesn't necessarily need to happen right here. Jan
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index f76de5be9437..37ebcb3abbc7 100644 --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -1088,10 +1088,6 @@ long arch_do_domctl( !is_pv_domain(d) ) break; - /* Count maximum number of optional msrs. */ - if ( boot_cpu_has(X86_FEATURE_DBEXT) ) - nr_msrs += 4; - if ( domctl->cmd == XEN_DOMCTL_get_vcpu_msrs ) { ret = 0; copyback = true;
Since the addition of the MSR_AMD64_DR{1-4}_ADDRESS_MASK MSRs to the msrs_to_send array, the calculations for the maximum number of MSRs that the hypercall can handle is off by 4. Remove the addition of 4 to the maximum number of MSRs that XEN_DOMCTL_{set,get}_vcpu_msrs supports, as those are already part of the array. A further adjustment could be to subtract 4 from the maximum size if the DBEXT CPUID feature is not exposed to the guest, but guest_{rd,wr}msr() will already perform that check when fetching or loading the MSRs. The maximum array is used to indicate the caller of the buffer it needs to allocate in the get case, and as an early input sanitation in the set case, using a buffer size slightly lager than required is not an issue. Fixes: 86d47adcd3c4 ('x86/msr: Handle MSR_AMD64_DR{0-3}_ADDRESS_MASK in the new MSR infrastructure') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- I'm tempted to just get rid of nr_msrs and use ARRAY_SIZE(msrs_to_send) instead, but refrained from doing it. --- xen/arch/x86/domctl.c | 4 ---- 1 file changed, 4 deletions(-)