Bump VCPU from u8 to u32

[KshitijKapoor8]

Bumped related information to u32 data type to support more vcpu's

#5345

[rbradford]

This won't work - you can't subscript with u32. Did you run clippy over all the commits? (or better - set up the pre-commit hook from CONTRIBUTING.md to do it for you.)

[liuw]

The old issue implies that it is more complicated than just changing the type. Has the underlying issue been resolved?

[up2wing]

I noticed that Rob did some work before: #5600.

Would you like to tell about underlying issue you encountered? @rbradford

[thomasbarrett]

I looked into this at one point when doing some CPU topology work. At least on x86_64, when we go above 254 vCPUs (the current max on x86_64 cloud-hypervisor), we may run into issues related to (io/x2/x)apic configuration.

From what I remember:

1. Each cpu is assigned an x2apic id. The x2apic id encodes the CPU topology (e.g. bit 0 represents the thread ID, bits 1-4 represent the core ID, bits 5+ represent the socket ID, etc). We assign the ioapic an apic id of (ncpus + 1). The ioapic cannot be assigned an x2apic, so it must be assigned an apic id in the 0-255 range. As far as I can tell, a cpu would needs to share an x2apic id with the ioapic. From what I remember, qemu just assigns the ioapic an apic id of 0.

2. Certain ACPI tables must be different for cpus have an x2apic id below 255 and above 255.

I don't think that we are that far off of support for >255 cpus on x86_64, but it requires some Intel doc reading to make sure we aren't doing anything evil.

[rbradford]

I noticed that Rob did some work before: #5600.

Would you like to tell about underlying issue you encountered? @rbradford

I think @thomasbarrett covered it well - there is also the issue of the mptable becoming too large and overwriting other in memory structures.

Correctly addressing this issue requires cultivating a good understanding of the appropriate x86 quirks - other architectures may be significantly simpler. Either way this is much more complicated than just bumping some data types. I'm going to close this PR because it doesn't even do the data type bump correctly (doesn't compile).