On 22/09/2017 12:20, Daniel P. Berrange wrote: > On Fri, Sep 22, 2017 at 12:18:44PM +0200, Paolo Bonzini wrote: >> On 22/09/2017 12:16, Stefan Hajnoczi wrote: >>> I suggest adding internal IOThreads alongside user-created IOThreads >>> instead of hiding them. IOThread also needs a bool user_created field >>> and a UserCreatableClass->can_be_deleted() function: >>> >>> static bool iothread_can_be_deleted(UserCreatable *uc) >>> { >>> return IOTHREAD(uc)->user_created; >>> } >>> >>> This way users cannot delete internal IOThreads. >>> >>> But how should object ids be handled? In theory existing -object >>> iothread,id=<id> users could use any name. How can QEMU generate ids >>> for internal IOThreads without conflicting with existing users's ids? >> >> I would add an 'internal' boolean to query-iothreads' response and a new >> 'show-internal' boolean to the command. This way, applications that >> request internal iothreads would know that the "primary key" is >> (internal, id) rather than just the id. > > What is the app going to do with iothreads if it sees "internal" flag > set ? They have no way of knowing what part of QEMU internally is using > this iothread, so I don't see that they can do anything intelligent > once they find out they exist.
The application could apply them default settings for scheduler policy or CPU affinity. Unlike the main or the I/O thread, the monitor thread doesn't interrupt the CPU, so it need not run at SCHED_FIFO even in real-time settings. Alternatively, the application could ensure that such threads would not get in the way of VCPU or I/O threads, providing slightly more stable performance. Paolo