All of lore.kernel.org
 help / color / mirror / Atom feed
* Difference between normal Dom0 and PVH Dom0
@ 2015-01-23  7:54 openlui
  2015-01-23 14:29 ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 3+ messages in thread
From: openlui @ 2015-01-23  7:54 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1477 bytes --]

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?
    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?
    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?
    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.


[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

[-- Attachment #1.2: Type: text/html, Size: 2413 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Difference between normal Dom0 and PVH Dom0
  2015-01-23  7:54 Difference between normal Dom0 and PVH Dom0 openlui
@ 2015-01-23 14:29 ` Konrad Rzeszutek Wilk
  2015-01-24  3:00   ` openlui
  0 siblings, 1 reply; 3+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-01-23 14:29 UTC (permalink / raw)
  To: openlui; +Cc: xen-devel

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.
>     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.

>     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.

>     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.
> 
> 
> [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@lists.xen.org
> http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Difference between normal Dom0 and PVH Dom0
  2015-01-23 14:29 ` Konrad Rzeszutek Wilk
@ 2015-01-24  3:00   ` openlui
  0 siblings, 0 replies; 3+ messages in thread
From: openlui @ 2015-01-24  3:00 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk; +Cc: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 3031 bytes --]

Thanks for you relay, Konrad. 

At 2015-01-23 22:29:48, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> 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@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 3538 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-01-24  3:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-23  7:54 Difference between normal Dom0 and PVH Dom0 openlui
2015-01-23 14:29 ` Konrad Rzeszutek Wilk
2015-01-24  3:00   ` openlui

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.