On Wed, 4 May 2022 01:02:42 +0000 Vineeth Pillai <vineethrp@xxxxxxxxxx> wrote: > The current detection of vcpu pid is based on the assumption that vcpuid > is monotonically increasing starting from 0 to max_cpus - 1. But the > crosvm uses the apic id as the vcpuid if topology is exposed to the > guest. And apicid can be non-contiguous. > > This patch gets the max apicid from guest and then uses it to detect the > vcpu pids. Even this approach is not fool proof an it assumes that > apicid monotonically increases. If we encounter a scenario where it is > not the case, we might need to implement a mechanism to get a map of > cpuid to vcpu from the guest and then use that to detect the pid. > > Signed-off-by: Vineeth Pillai <vineethrp@xxxxxxxxxx> If you haven't noticed I have patches that are a workaround that fixes this issue if the conditions are "right". (I Cc'd you) [1] The work around is to not depend on the number in debugfs/kvm/vcpuX to match the CPU of the guest, but instead to match the ordering of the CPUs of the guest. It also requires that the guest's CPUs are consecutive and non sparse. That is, if you have vcpu0, vcpu1, vcpu8 and vcpu9 on the host, then the guest needs to have CPU 0-3 with the mapping of: vcpu0 -> CPU 0 vcpu1 -> CPU 1 vcpu8 -> CPU 2 vcpu9 -> CPU 3 and then it works. Of course if this is not true, then it breaks again and will require some more communication between the host and the guest. [1] https://lore.kernel.org/all/20220708014244.677826-1-rostedt@xxxxxxxxxxx/
|