On 08/19/2012 10:22 PM, Peter Maydell wrote: > On 19 August 2012 20:12, Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx> wrote: >> On Sun, Aug 19, 2012 at 1:01 PM, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: >>> On 18 August 2012 20:25, Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx> wrote: >>>> I don't think we should have a vcpu ioctl for this purpose at all for >>>> two reasons 1) this happens asynchronously to the vcpu thread and 2) >>>> even a PPI is semantically not a vcpu operation but an operation on >>>> the gic distributor, which belongs to the VM. >>> >>> I'm not at all convinced by (1) as a reason but (2) is more compelling. >> >> I am not saying (1) is something written in stone, but if that's the >> consensus for things now (as Avi indicates) I don't see why we should >> come and change it when we can easily build on what is there. > > My point is more that if there are operations that are really cpu > specific I don't see why we should arbitrarily claim that you can't > do them with a vcpu ioctl even if the actual implementation of that > vcpu ioctl would be perfectly OK with doing it from some other thread > than the vcpu thread. I am trying to enforce some regularity here. To qualify for the brand of a "vcpu ioctl", one must: - be called synchronously to the vcpu - take the vcpu mutex - only be called from the vcpu thread I'm not saying a per-vcpu async ioctl that doesn't take the vcpu mutex isn't a sensible thing, but it's not a vcpu ioctl. We can create a new type of ioctl, or we can shoehorn it into a vm ioctl, but we're not going to bend that definition. The reason is that I would like to eventually get rid of the vcpu mutex and fds and switch to a syscall based setup. A vcpu ioctl translates naturally to a syscall with no vcpu argument, since there'll be a 1:1 vcpu:task association. All vcpu ioctls translate to lookups on the task to find the vcpu, and all vm ioctls translate to lookups on the mm to find the struct kvm. -- error compiling committee.c: too many arguments to function _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
