[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Xen/hypercall: Update vcpu_op to take an unsigned vcpuid



>>> On 16.01.15 at 13:03, <andrew.cooper3@xxxxxxxxxx> wrote:
> This has no guest-visible change, but makes the Hypervisor side bounds
> checking more simple.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.