Re: [PATCH for-4.19] libxl: fix population of the online vCPU bitmap for PVH

["Oleksii K." <oleksii.kurochko@xxxxxxxxx>]

On Fri, 2024-05-10 at 16:20 +0100, Andrew Cooper wrote:
> On 10/05/2024 1:49 pm, Roger Pau Monne wrote:
> > libxl passes some information to libacpi to create the ACPI table
> > for a PVH
> > guest, and among that information it's a bitmap of which vCPUs are
> > online
> > which can be less than the maximum number of vCPUs assigned to the
> > domain.
> > 
> > While the population of the bitmap is done correctly for HVM based
> > on the
> > number of online vCPUs, for PVH the population of the bitmap is
> > done based on
> > the number of maximum vCPUs allowed.  This leads to all local APIC
> > entries in
> > the MADT being set as enabled, which contradicts the data in
> > xenstore if vCPUs
> > is different than maximum vCPUs.
> > 
> > Fix by copying the internal libxl bitmap that's populated based on
> > the vCPUs
> > parameter.
> > 
> > Reported-by: Arthur Borsboom <arthurborsboom@xxxxxxxxx>
> > Link: https://gitlab.com/libvirt/libvirt/-/issues/399
> > Reported-by: Leigh Brown <leigh@xxxxxxxxxxxxx>
> > Fixes: 14c0d328da2b ('libxl/acpi: Build ACPI tables for HVMlite
> > guests')
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > ---
> > Note that the setup of hvm_info_table could be shared between PVH
> > and HVM, as
> > the fields are very limited, see hvm_build_set_params() for the HVM
> > side.
> > However this late in the release it's safer to just adjust the PVH
> > path.
> > 
> > Also note the checksum is not provided when hvm_info_table is built
> > for PVH.
> > This is fine so far because such checksum is only consumed by
> > hvmloader and not
> > libacpi itself.
> > 
> > It's a bugfix, so should be considered for 4.19.
> 
> Bugfixes are still completely fair game at this point.
Considering that this is bugfixes I will be happy to have that in 4.19
release:
 Release-acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>

~ Oleksii
> 
> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>