Li, Xin B wrote: >> - set up a kvm main loop outside vl.c and cpu-exec.c. >> - disable signals on ap threads, so that timer and network signals are >> only handled on vcpu 0 >> > > I prefer to have a separate thread in qemu to execute asynchronous > logic, like the PIC/IOAPIC code. > >
A separate thread for signals and timers is a good idea. >> - set up locking so that qemu code is never executed on more than one >> > thread > > Each vCPU has a corresponding thread and can do synchronous IOs, like > IN/OUT and MMIO to a device in DM, basically we don't need lock or > serialize since guest OS device driver should guarantee device access > won't happen on more than one CPU if that's not allowed. For a bad OS, > it just kills its VM, That is a possibly exploitable hole. We need to have some locking. > or we may need to serialize accesses to the same > device by using a device only lock. Totally we will have CPU# plus 1 > thread. > By this, we can get the best parallelism. > > Agreed. >> - hack qemu's apic so it can sipi and ipi other vcpus >> > > I prefer to keep LAPIC logic in KVM only, IOAPIC logic can be in Qemu > side. > kernel lapic will have better performance and accuracy; user lapic is a fallback so that if there's a problem, we can run with user lapic and see if it reproduces (similar to the -no-kvm switch). -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
