Anthony Liguori wrote: > Glauber Costa wrote: > >> Anthony Liguori wrote: >> >> No, it can't. Because at the time qemu starts, no vcpu -> thread id >> relationship exists at all. And we don't know when it will. >> > > Sure we do. The vcpu -> thread id relationship is valid after > kvm_init_ap() is called which is after machine init but before the > select loop is entered for the first time. Therefore, if you start qemu > with -S, then connect on the monitor, and do an info cpus, you could be > guaranteed to be told the mapping. > > The threads are *idle* at this point so there's no harm if they were > started on the "wrong" CPU. You can now taskset to your hearts content > and then when you're happy with placement, you can issue a 'cont' so > that the VM actually starts running. I saw "wrong" because you can > still taskset the initial creation guaranteeing that the threads are > created on the right group of physical CPUs, you just can't specify the > exact mapping until you start interacting with the monitor. > >
Good points. Initially I thought we ought to abstract the implementation and not expose the vcpu thread id, but I'm beginning to thing that due the wide variety of options (affinity, page migration, priority, cpu control groups) and the relative obscurity of the feature (which as you point out, isn't needed in the common case), we can export the thread id and let the management tools deal with it directly. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
