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] RE: Rearchitecting IO Emulation for HVM Guests

To: "Natasha Jarymowycz" <natasha@xxxxxxxxxx>
Subject: RE: [Xen-devel] RE: Rearchitecting IO Emulation for HVM Guests
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 15 Jun 2006 09:46:00 +0100
Cc: dsteklof@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 15 Jun 2006 01:46:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcaQK79uWIU3kM1oRC2ReNk5vswDRAAK0sHw
Thread-topic: [Xen-devel] RE: Rearchitecting IO Emulation for HVM Guests
> >  3. implement 'stub domains' -- rings 1-3 in the root VMCS (normally
> > used by PV guests) are free for use in HVM domains (we need to have
some
> > discussion on the best way of doing this [*])
> 
> Is anyone currently working on this?  Have any discussions been had
> previously about the best way to hook the stub domain into the HVM
> domain?

No one is currently working on it. It requires a bit more thought before
action.

There are two basic possibilities;

 * stub domain and the HVM domain each have their own domain structures.
The scheduler knows that they're actually the same real domain, and
hacking is required to let the stub domain map the HVM domain's memory.

 * Implement them within the same domain structure, duplicating fields
as required to make it work (effectively having PV guest and HVM areas
to the domain struct).

The 2nd is probably preferable, it needs more work though.

When scheduling the domain, the PV guest 'stub domain' would always be
run if it is runable, otherwise xen will run the hvm guest.

Ian
 
> It looks like this work may have to be done outside of the
xen-unstable
> tree, especially if we're modifying xen data structures.  Will there
> be/is there a public tree available for this effort?
> 
> Thanks,
> Natasha
> 
> >  4. run linux in the stub domain with qemu running from an initrd
> >  5a. link qemu directly against the linux kernel to avoid system
calls
> >  5b. or, link qemu against minios if we have IO support in minios.
> >
> > Thanks,
> > Ian
> >
> > [*] do we have a separate domain struct that the scheduler knows is
> > actually the same as another domain for scheduling/accounting
purposes,
> > or do we modify the domain struct so hvm and pv guests don't share
the
> > same fields? Probably the latter.
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel