[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] RE: Co-scheduling HVM domains...


  • To: "Roger Cruz" <rcruz@xxxxxxxxxxxxxxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Wed, 28 Mar 2007 18:16:54 +0200
  • Delivery-date: Wed, 28 Mar 2007 09:16:02 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: AcdwEslRdy6dEOdyQ7Km6kAAV+zl4AAnNNPQABpkAzAADjDPsAAASuEw
  • Thread-topic: [Xen-users] RE: Co-scheduling HVM domains...

 

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Roger Cruz
> Sent: 28 March 2007 17:05
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-users] RE: Co-scheduling HVM domains...
> 
> >> 1) I've heard of something called stub domains that may do 
> something
> >> similar to case 1.  I'm trying to get more info on it.  Don't 
> >> know if it
> >> even works for Windows HVMs.
> 
> > Stub domains has nothing to do with the problem you're trying to
> solve. 
> 
> My limited understanding of stubs domains is that it allows a
> mini-domain to be scheduled with the main domain as a pair.  The
> mini-domain would have easy access to the domain's memory space.  So
> they are basically two CPU contexts using the same page tables, etc.
> That is all I know so far since the info on this is rather limited.

Yes, but the stub domain isn't a "normal domain". It's more like a
"monitor domain" or "hypervisor extension" that is loaded into the
same/similar memory space and runs on the SAME VCPU as the actual
domain. It's still not going to solve your problem. If stub domains
where implemented today, your two windows domains would each have a
stub-domain - which would be used whenever the guest-domain needs to
perform emulation of hardware. 

The purpose of stub-domains is twofold:
1. To remove the "bottleneck" of Dom0 to perform the emulation of
hardware, instead (a large portion) of this work could be done by the
stub-domain. 
2. To make accounting for emulation of hardware be more easily connected
to the domain that is responsible for that work. 

I don't think it's necessary for the scheduler to change to make this
work (aside from perhaps to keep the stub-domain and "real" domain
account together). 
> 
> 
> On the issue of the scheduler, I would agree with you on making
> "bonding" of domains generic so it can be accepted.
> 
> I just wanted to get these questions out there to make sure I was not
> missing something obvious or support coming in a near-future release.

I don't think you're missing anything important. 
> 
> Javier,
> 
> You asked about whether we have gotten domains to shared 
> memory and the
> answer is not yet. We have not even tried.  Our understanding is that
> there are grant tables that are supposed to do this and the code is
> available for HVM domains as well.  If someone has more accurate info,
> please correct my understanding.

Yup, there's a way to call hypercalls from HVM domains (check out the
"unmodified-driver" directory in the xen distribution - that contains
the Linux Para-virtual drivers for HVM). 

--
Mats
> 
> Thank you all.
> R.
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
> 
> 
> 



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.