I have been thinking about making dom0 VT domain for a long time.
There are some history I want to share.
In 2005, pava-dom0 is not available,
Intel team built VT-dom0 and run VT-guest domain on it.
Since at that time, VT domain was relative slow, so we moved to
para-dom0.
Hybrid virtualization is more suitable for IA64 than IA32 from the point
of the performance.
1. Memory virtualization,
para-domain for IA32 is using direct page table access
VTx-domain for IA32 is using shadow page table or EPT,
In theory direct page table is faster. IMHO, That's the major
reason, VTx-domain is slower than para-domain
While for IA64, both VTi-domain and para-domain are using same
technology. There is no perfomance degradation in memory virlualization.
2. CPU virtualization
para-domain is using memory to emulate vcpu.
Vti-domain currently is using memory to emulate vcpu, while
later on VT-I may move some vcpu context into shadow register.
Accessing shadow register may be faster than accessing memory.
In summary, I think there are similar performance in terms of
cpu vitualization.
3. Device vitualiztion
Both para-domain and VT-I domain can use same technology.
There were some issues we encounterd on building Vti-dom0( there is no
modification for dom0 linux kernel at all),
1. need an interrupt vector to handle event channel,
how to reserve an interrupt vector?
What's the interrupt vector priority?
2. When dom0 wants to map other Vti-domain memory, dom0 don't have
physical address space for it,
so foreign mapped guest memory don't have responding dom0 guest
physical address.
This may have heavy impact on the infrastructure on dom0. We
need to resolve it.
If we use hybrid mode, above two issues can be resolved with current
method.
Hybrid mode is to use VT-I technology to virtualize CPU.
Running dom0 on VT mode is feasible, we have proved this.
There should be no explicit performance degradation for dom0.
While moving dom0 to Vt mode may need great effort, but it is worthwise,
It reduces the effort to maintain xenolinux,
It's painful, Redhat has complained it.
Running dom0 on VT mode is great.
I'm looking forward to what you are thinking about it.
- Anthony
Alex Williamson wrote:
> Hi all,
>
> I've been running some simple kernel compile benchmarks lately and
> getting much better HVM results than I was expecting. In summary,
> both PV and HVM performance are within 11-12% of native performance
> for an SMP guest build on a Montvale system. For the same test on
> x64, PV shows ~12% overhead while HVM is ~55%. This begs the
> question; is paravirtualziation on ia64 worthwhile?
>
> Jun Nakajima has presented his paper[1] on hybrid virtualization
> at a few conferences and at one point asked me what I thought about
> running Dom0 in VT mode. At the time, I didn't have good VT-i
> performance data and assumed it was possible, but had little
> advantage. However, if we're only looking at a very small
> performance gap between PV and HVM already, perhaps we should give
> this some serious consideration.
>
> This idea becomes especially interesting now as we're thinking
> about how to get Xen/ia64 support into upstream kernels. If we
> require VT processors, could we significantly reduce the complexity
> and intrusiveness of the Linux kernel changes required for Dom0/DomU
> support? In the best case, I could imagine that if we can rely on VT,
> then xen-ification of the Linux kernel might be as "simple" as
> creating a Xen aware machine vector (different from the one we have
> now) and a set of hypercall support interfaces. I would envision
> Dom0 operating similar to a PCI pass-through domain with direct
> access to the hardware (but not requiring VT-d). We would obviously
> need the PV drivers to become more pervasive to avoid the I/O
> bottleneck that exists with Qemu and regain PV DomU-like I/O
> performance for guests.
>
> Is it possible? Is it a good idea? What are some of the issues?
> We would lose support for non-VT capable processors (pre-Montecito),
> but is that so bad? Is it a "fast track" to upstream Linux Xen/ia64
> support? Let me know your thoughts. Thanks,
>
> Alex
>
> [1] http://ols.108.redhat.com/2007/Reprints/nakajima-Reprint.pdf
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home