WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] stub domain or "hyper thread" in xen

To: Ashish Bijlani <ashish.bijlani@xxxxxxxxx>
Subject: Re: [Xen-devel] stub domain or "hyper thread" in xen
From: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Date: Wed, 14 May 2008 18:42:44 +0200
Cc: Xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 14 May 2008 09:43:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <ec55b17e0805132040x53ba0df4v755eb0dfe52aa0a1@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>, Ashish Bijlani <ashish.bijlani@xxxxxxxxx>, Xen-devel@xxxxxxxxxxxxxxxxxxx
References: <ec55b17e0805132040x53ba0df4v755eb0dfe52aa0a1@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.12-2006-07-14
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>