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

RE: [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
> > 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

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.

> It looks like this work may have to be done outside of the
> 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
> >  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
> > or do we modify the domain struct so hvm and pv guests don't share
> > same fields? Probably the latter.
> >

Xen-devel mailing list



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