Hi Joe,
Good questions...
On Mon, 2008-01-28 at 16:27 -0500, Joseph Szczypek wrote:
> Hi everyone,
>
> I've been reading the hybrid virtualization discussions. Could someone
> explain the relationship of a VT-Dom0 to guests? I ask because I see
> several 'requirements' being raised on the xen-ia64-devel list with
> respect to the hybrid virtualization idea, things like PV DomU should
> work, PV Dom0 should still be around, etc. I'm hoping someone could
> help clarify things.
I think a key item that needs to be clarified is that VT only
virtualizes the processor. So when we're talking about a VT-mode
domain, we're really just talking about removing some of the low-level
processor paravirtualization and running the domain with VT enabled to
handle those details. There's still quite a lot of paravirtualization
above that to handle event channels, scheduling, etc...
Dom0 and domU are tied together because of their shared code based,
so removing paravirtualization components from one affects the other.
However, it does not preclude other trees that might still support lower
level paravirtualization. In fact, privified or pre-virtualized guest
domain might achieve the same degree of low-level processor
paravirtualization we have today with less code.
> Here is my assumption:
> VT-Dom0 would have native IO, native FW access, and some paravirtualized
> 'stuff' (process context switching?, what else?) No PV Dom0 like we
> have today would exist.
Careful not to read too much into VT-mode. Dom0 would look and feel
much like it does today, as would hybrid domUs. A PV dom0 kernel could
be achieved via privification/pre-virtualization.
> My questions:
> What type guests would work:
> - HVM only?
> * Qemu still required?
> - HVM guest with PV-on-HVM drivers?
> * does this mean a front-end/back-end would still exist, but now
> between a VT-Dom0 and HVM DomU?
> - PV guests would no longer exist?
All that we have today. Don't get VT-mode confused with HVM. HVM is
VT plus QEMU plus GFW. The hybrid idea is just extracting the VT
portion so that we can make fewer changes to the low-level Linux code
base. The reaim numbers show that there's still significant advantage
to paravirtualization, and we need to be sure to draw the line in a
place that continues to provide that advantage.
> Would VT-Dom0 be unique?
> I'm assuming it would be unique to Dom0, not quite like PV Dom0 today,
> but also not a 'standard umodified guest'. With that in mind, will
> there still be support issues in terms of different things to support
> (today it's PV Dom0 plus PV guest plus HVM guest support - tomorrow it
> would be hybrid Dom0 (VT with PV hooks) plus HVM guest support (assuming
> no PV guest would exist).
Again, I think you might be reading too much into VT-mode. We would
still require paravirtualization, but hopefully we could boot mostly
through the architecture code without much code change. I think the big
questions are performance and lines of code. If we can't maintain
performance with fewer lines of code using VT, then we probably need to
continue down the path of an ia64 equivalent of paravirt_ops. Hope that
helps,
Alex
--
Alex Williamson HP Open Source & Linux Org.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home