Hello, Why can''t a guest domain be associated with a dom0 kernel thread (I call hyper thread) instead of a stub domain to do the I/O independently? I''m talking about introducing hyper threads (essentially dom0 kernel threads) below a guest domain''s kernel threads and moving backend drivers and qemu device model functionality from dom0 to these "hyper threads" to do I/O independently.The idea is based on user-kernel thread model i.e. similar to the user-kernel thread architecture to do I/O through syscalls in an OS, there can be a guest kernel thread and a hyper thread association to do the I/O through hypercalls in an hypervisor based platform. -Ashish _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Samuel Thibault
2008-May-14 16:42 UTC
Re: [Xen-devel] stub domain or "hyper thread" in xen
Hello, Ashish Bijlani, le Tue 13 May 2008 23:40:52 -0400, a écrit :> he idea is based on user-kernel thread model i.e. similar to the > user-kernel thread architecture to do I/O through syscalls in an OS, > there can be a guest kernel thread and a hyper thread association to > do the I/O through hypercalls in an hypervisor based platform.Mmmm, it looks to me like you want to reinvent the paravirtualization interface... If a guest is paravirtualized, we don''t use a qemu/stubdomain/whatever, and the guest indeed basically just talks with a dom0 kernel thread, or anything looking like that (tasklet, etc.). If the guest is not paravirtualized, then we have to emulate virtual devices, and that we clearly don''t want to do it in dom0 kernel space :) Even running it as root in dom0 is already frowned upon. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel