On 14.06.24 22:36, Sean Christopherson wrote:
> On Fri, Jun 14, 2024, Mathias Krause wrote:
>> On 14.06.24 18:35, Sean Christopherson wrote:
>> However, this still doesn't prevent creating VMs that have no BSP as the
>> actual vCPU ID assignment only happens later, when vCPUs are created.
>>
>> But, I guess, that's no real issue. If userland insists on not having a
>> BSP, so be it.
>
> "struct kvm" is zero-allocated, so the BSP will default to vCPU0. I wouldn't be
> at all surprised if VMMs rely on that (after looking, that does appear to be the
> case for our VMM).
Sure, zero-initialized by default makes a lot of sense. I too would
assume that CPU0 is the BSP.
However, I was thinking more along the lines:
--- a/tools/testing/selftests/kvm/x86_64/set_boot_cpu_id.c
+++ b/tools/testing/selftests/kvm/x86_64/set_boot_cpu_id.c
@@ -136,6 +136,7 @@ int main(int argc, char *argv[])
run_vm_bsp(0);
run_vm_bsp(1);
run_vm_bsp(0);
+ run_vm_bsp(42);
check_set_bsp_busy();
}
As in: having two vCPUs with IDs 0 and 1 but the BSP with an ID outside
of that range, e.g. 42 in this case.
That's still a working setup but without any dedicated BSP, so may cause
some hickups for real operating systems. But, again, if a user does this
on purpose and things break, well, can keep the pieces.
Thanks,
Mathias
