>>> On 16.01.15 at 13:03, <andrew.coop...@citrix.com> wrote: > This has no guest-visible change, but makes the Hypervisor side bounds > checking more simple. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Acked-by: Jan Beulich <jbeul...@suse.com> > There are no functional changes as a result of this patch, but I have an RFC > improvement to suggest. > > The bounds check against MAX_VIRT_CPUS is spurious now that PVH domains can > use vcpu_op hypercalls. It is fine as MAX_VIRT_CPUS (8K) is far higher than > current 128 limit for HVM guests, but there is nothing conceptually > preventing > an HVM domain from having more than 8k CPUs (x2apic allows for 2^32 unique > ids). Not exactly, due to the need to allow for clustered mode, but still a few hundred k. > I propose dropping the MAX_VIRT_CPU bounds check completely, and relying on > d->max_vcpus to be within the approprate bounds. This will result in a guest > visible change insofar that some of their -EINVAL errors will turn into > -ENOENT, which is why this is suggestion is RFC. I don't think changes in error code values is problematic in any way, except in cases where for specific ones specific actions are expected to be taken by the guest. So - go for it. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
