On Tue, Feb 15, 2011 at 6:51 PM, Iustin Pop <iusty@xxxxxxxxx> wrote:
> On Sun, Feb 13, 2011 at 07:50:35PM -0500, Javier Guerra Giraldez wrote:
>> On Sun, Feb 13, 2011 at 7:02 PM, Iustin Pop <iusty@xxxxxxxxx> wrote:
>> > The QEMU process
>> > still needs to run, and still does runs code on behalf of the VM; yes,
>> > CPU is not emulated, memory access is direct, but IIRC even my paravirt
>> > drivers, some stuff still goes through QEMU/kvm.
>>
>> just the same stuff that goes through Dom0 daemons
>
> No, not at all. You can kill all dom0 daemons, and Xen VMs still run. We
> used to rely on this in old Xen versions where xend sometimes got stuck.
> What the dom0 daemons are used for is setting up the VM, afterwards they
> are not running it. Yes, the drivers in dom0 respond to I/O requests,
> but this is different.
i think you're missing some important points about KVM execution
architecture (although i fear it's becoming off-topic).
a KVM process has several threads: one for qemu, one or more for IO,
and one for each virtualized CPU. the last ones are switched to the
virtualization mode and run 'guest' code. all the guest OS is run on
these threads, only when there's a mode-exit trap, the VM thread(s) is
suspended by the kernel and the qemu thread receives a signal.
exactly the same as on HVM Xen DomU's, when there's a mode-exit trap,
the hypervisor switches contexts and signals the Dom0 daemons.
the fact that there's no way to keep the VM while killing/restarting
qemu is just because they're threads in a single process. there's no
'code run in behalf of the VM' by qemu beyond hardware emulation.
again, just like Dom0 daemons.
the pros/cons of each architecture are (once again) debatable in
importance: Xen is (in theory) more resilient to bugs; KVM gets (in
theory) less context switches per I/O
--
Javier
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home