| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
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
|
|
|
| |
|
Home