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

Re: [Xen-devel] Difference between normal Dom0 and PVH Dom0



Thanks for you relay, Konrad.

At 2015-01-23 22:29:48, "Konrad Rzeszutek Wilk" <konrad.wilk@xxxxxxxxxx> wrote:
>On Fri, Jan 23, 2015 at 03:54:07PM +0800, openlui wrote: >> Hi, all: >> From the article [1] and xen-colors picture from Brendan Gergg's blog [2], I have some understanding and question about PVH Dom0 as follows: >> 1. Even after pvops has been support in Linux mainline kernel, current XEN dom0 is still a "Full PV" domain (I will call it as "normal Dom0" in this mail), am I right? >
>It can do both.
Currently, PVH dom0 is still under development. I find it is announced as an experimental feature for XEN 4.5.

>> 2. The normal Dom0 cannot take advantage of the Hardware visualization extensions like HVM Domain, including privileged instructions and pagetables. I am wondering how much performance impact it will have compared with PVH and HVM Domain, and does it means that the technology such as shadow page table is needed for Dom0? >
>It is less faster than PVH.

Without the assistance of hardware visualization extensions, what are the "para-visualization ways" for handling the pagetables or privileged instructions? Hypercall for privileged instructions and Shadow page table for pagetables?
> >> 3. For the normal Dom0 running with x86_64, because of the elimination of segmentation limit, each system call in Dom0 will bounce up into Xen and then context-switch to the Dom0 kernel, and will cause frequent flushing of the TLB. Is this also applied to x86_64 cpus from other vendors other than AMD? How can I verify it? It seems that the problem will have big impact for Dom0 performance, does it? > >It does have - however Linux has made strides in minimizing the need for making TLB flushes and >also the major reason for doing up-calls is batched to minimize the amount the frequent usage of TLB flushes.
I am wondering why frequent flushing of the TLB will be caused when each system call in Dom0 bounces up into Xen and then context-switch to the Dom0 kernel. Could you give me some hint?

>> 4. PVH Dom0 can improve the maintainability of pvops related code of Xen as well as improve the performance of normal Dom0. I am wondering if there are other aspects of performance PVH Dom0 can improve besides the 2 and 3 mentioned above. > >Yes. We can use compound pages without the SWIOTLB finding the pages not being contingous. That >will improve network performance.
I don't have more experience about SWIOTLB and compound pages you mentioned above, could you give me some more info or some reference about them?
>> >> [1] https://blog.xenproject.org/2012/10/31/the-paravirtualization-spectrum-part-2-from-poles-to-a-spectrum/ >> [2] http://www.brendangregg.com/blog/images/2014/xen-colors.png > >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxx >> http://lists.xen.org/xen-devel > > >_______________________________________________ >Xen-devel mailing list >Xen-devel@xxxxxxxxxxxxx >http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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