a) only 10% of the fleet are running a version of the hypervisor that is affected by the bug
b) based on the turnover rate, they expect 10% to need rebooting under the customers by the date the bugs are being released.
c) 10% are running a combination of the affected hypervisor and vm's that are reasonably at risk of exploitation, other's may have the faulty hypervisor but either are being used as single tenant (there is no risk of someone breaking out and affecting someone else) or are running vm's that may not be able to break out depending on the nature of bugs.
In the past, Xen has has vulnerabilities based on things different between Intel and AMD processors, or even between different processors from the same company. It seems likely that the fleet is all running the same version of the hypervisor, but the bug only matters on 10% of their hardware.
Here's a previous Xen vulnerability based on Intel implementing the SYSRET instruction (originally introduced by AMD, along with SYSCALL; Intel's version of this was SYSENTER and SYSEXIT, with different semantics about kernel stacks and things) in a slightly different way from how AMD implemented it. Both Intel's docs and AMD's docs were accurate for their own processors, but if you only read AMD's docs, you'd implement syscalls in a way that was vulnerable on Intel.
a) only 10% of the fleet are running a version of the hypervisor that is affected by the bug
b) based on the turnover rate, they expect 10% to need rebooting under the customers by the date the bugs are being released.
c) 10% are running a combination of the affected hypervisor and vm's that are reasonably at risk of exploitation, other's may have the faulty hypervisor but either are being used as single tenant (there is no risk of someone breaking out and affecting someone else) or are running vm's that may not be able to break out depending on the nature of bugs.
Just speculating, any ideas?