On Mon, Jan 11, 2016 at 05:09:27PM +0100, Andrew Jones wrote:
> On Mon, Jan 11, 2016 at 04:09:29PM +0100, Christoffer Dall wrote:
> > Are vcpu ids already exposed to userspace (beyond the stupid
> > KVM_IRQ_LINE) ioctl and as such we're bound to whatever upper limit and
> > format they have?
>
> The only other place I found is KVM_CREATE_VCPU. I suppose we could move
> to MPIDR for that, and it would be a nice way to handle the "userspace
> determines MPIDR" work that I plan to do. Both KVM and its userspaces
> would still use some counter-based vcpu identifiers internally, to avoid
> large, sparse structures, but I guess the advantage is that they don't
> have to agree on how they do that. The 'vcpu id' used by KVM_CREATE_VCPU
> is already 32-bits, and is supposed to be an arbitrary identifier. That
> all looks good for converting to MPIDR.
>
Correction. I understand that vcpu-id is "supposed" to be an arbitrary
identifier now, but it doesn't appear that all the assumptions that it's
a counter are gone yet... virt/kvm/kvm_main.c has
static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
...
if (id >= KVM_MAX_VCPUS)
return -EINVAL;
More to do there I guess...
drew
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
