All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Petersson, Mats" <Mats.Petersson@amd.com>
To: Liang Yang <multisyncfe991@hotmail.com>,
	Xen devel list <xen-devel@lists.xensource.com>,
	xen-users@lists.xensource.com
Subject: RE: [Xen-users] Does vt-x itself have perf. impact on Hypervisor w/o considering HVM?
Date: Tue, 23 Jan 2007 17:33:29 +0100	[thread overview]
Message-ID: <907625E08839C4409CE5768403633E0B018E18C3@sefsexmb1.amd.com> (raw)
In-Reply-To: <BAY125-DAV1904C01DC1D3A317B1D2CC93AD0@phx.gbl>

 

> -----Original Message-----
> From: Liang Yang [mailto:multisyncfe991@hotmail.com] 
> Sent: 23 January 2007 16:15
> To: Petersson, Mats; Xen devel list; xen-users@lists.xensource.com
> Subject: Re: [Xen-users] Does vt-x itself have perf. impact 
> on Hypervisor w/o considering HVM?
> 
> Without VT-x support, binary translation has to be used to make those 
> non-virtualizable instructions throw exception. With VT-x 
> support, no binary 
> translation is needed. So you mean, binary translation could 
> be implemented 
> as efficient as they are done in hardware?

Not at all - I'm saying that if you're not using VT-x, then VT-x has no
performance impact to your tests, which is what you originally asked. Or
at least, that's how I interpreted:
"both domain0 and Para-Virtualized Guest Domain (HVM domain is not
considered)" in your original post. 

Xen doesn't use binary translation, it uses para-virtualization, which
is another way to say "source-code of the operating systme being
modified to support virtualization". 

Binary translation or hardware support is needed if you're using an
operating system where it is unpractical to do para-virtualization (for
example, source-code is not publicly available (say Windows), or the
user-base isn't big enough to sustain a para-virtualization effort (say
Linux kernel 2.4.x)).

Whether binary translation or hardware is more efficient will depend on:
1. Implementation of the binary translation and hardware. 
2. What application and OS is being run on the system. 

It is by no means sure that Binary translation is either faster or
slower than hardware implementations of virtualization. There are too
many other factors that affect the situation to say for sure - one case
may be faster for binary translation (because the type of operations
suit binary translation), whilst another is slower.

For most common cases, Para-virtualization should be able to be overall
faster than both, because there are possibilities to bunch together
several operations that cause a hypervisor interaction, and those can be
"pacakged together" rahter than each event needing it's own separate
hypervisor interaction. Of course, REALLLY clever binary translation may
be able to detect a loop writing to the page-table and translate that
into a block-call of "translate these 100 page-writes", rather than
"for(...) do { translate one page write }" as the obvious solution would
be. In hardware, there is no choice but to intercept each and every
operation on it's own, so it's most likely the slowest operation, unless
there's some way to avoid the hypervisor being called overall (there are
some such cases too, and again, it depends on the exact circumstances of
the application + OS that is run as a guest). 

There's also more possibilities to add things to the hardware to support
future enhancements of the hardware, which just plain isn't going to
happen in the software solution. One such feature is nested paging,
which allows the guest-page-table operations to avoid being intercepted
(instead of an intercept and a whole bunch of code to perform the
page-table write, the processor does a second page-table access of the
"host-page-table" which translates the guest physical address into
machine physical address). 

--
Mats
> 
> Thanks,
> 
> Liang
> 
> ----- Original Message ----- 
> From: "Petersson, Mats" <Mats.Petersson@amd.com>
> To: "Liang Yang" <multisyncfe991@hotmail.com>; "Xen devel list" 
> <xen-devel@lists.xensource.com>; <xen-users@lists.xensource.com>
> Sent: Tuesday, January 23, 2007 3:05 AM
> Subject: RE: [Xen-users] Does vt-x itself have perf. impact 
> on Hypervisor 
> w/o considering HVM?
> 
> 
> > -----Original Message-----
> > From: xen-users-bounces@lists.xensource.com
> > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of 
> Liang Yang
> > Sent: 22 January 2007 18:33
> > To: Xen devel list; xen-users@lists.xensource.com
> > Subject: [Xen-users] Does vt-x itself have perf. impact on
> > Hypervisor w/o considering HVM?
> >
> > Hello,
> >
> > Suppose I have two different kinds of CPUs which have exactly
> > the same
> > configuration except one supports VT-X while the other does
> > not. If I want
> > to test the I/O performance (or other perf. testing which is not
> > particularly related to I/O) of the both domain0 and
> > Para-Virtualized Guest
> > Domain (HVM domain is not considered), shall I expect to 
> get the same
> > performance results on these two CPUs?
> 
> Assuming ALL other aspects are the same, when you're not using HVM,
> there should be absolutely zero impact from it (aside from it 
> using up a
> few kilobytes of memory, to be precise, HVM (including both 
> VMX and SVM)
> takes up 129459 bytes when not used - more memory is allocated
> dynamically when it's being used for obvious reasons. For modern
> systems, that's so small that it doesn't matter).
> 
> --
> Mats
> >
> > Thanks,
> >
> > Liang
> >
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
> >
> >
> >
> 
> 
> 
> 
> 
> 

      reply	other threads:[~2007-01-23 16:33 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-18 13:57 32-on-64: pvfb issue Gerd Hoffmann
2007-01-18 14:07 ` Keir Fraser
2007-01-18 15:00 ` Markus Armbruster
2007-01-18 15:35   ` Gerd Hoffmann
2007-01-18 15:53     ` Daniel P. Berrange
2007-01-18 16:34       ` Gerd Hoffmann
2007-01-18 16:55         ` Gerd Hoffmann
2007-01-18 17:05         ` Daniel P. Berrange
2007-01-18 18:31     ` Keir Fraser
2007-01-19  9:46       ` Gerd Hoffmann
2007-01-19  9:54       ` Gerd Hoffmann
2007-01-19 10:31         ` Markus Armbruster
2007-01-19 10:46           ` Gerd Hoffmann
2007-01-19 11:53             ` Markus Armbruster
2007-01-19 11:10         ` Keir Fraser
2007-01-19 11:43           ` Gerd Hoffmann
2007-01-19 12:01             ` Keir Fraser
2007-01-19 12:59               ` Gerd Hoffmann
2007-01-19 13:45                 ` Keir Fraser
2007-01-19 15:08                   ` Gerd Hoffmann
2007-01-19 15:22                     ` Keir Fraser
2007-01-19 15:31                       ` Gerd Hoffmann
2007-01-19 16:05                         ` Keir Fraser
2007-01-20  0:09                           ` [Patch] [VTPM_TOOLS] Add HVM support to vtpm_manager Scarlata, Vincent R
2007-01-22  7:50                           ` 32-on-64: pvfb issue Gerd Hoffmann
2007-01-22 14:01                             ` Gerd Hoffmann
2007-01-22 14:48                               ` Keir Fraser
2007-01-23 12:53                                 ` Gerd Hoffmann
2007-01-23 15:07                                   ` Keir Fraser
2007-01-23 15:56                                     ` Gerd Hoffmann
2007-01-24 11:23                                   ` Gerd Hoffmann
2007-01-24 12:02                                     ` Keir Fraser
2007-01-24 12:24                                     ` Markus Armbruster
2007-01-24 12:38                                       ` Gerd Hoffmann
2007-01-24 14:24                                         ` Markus Armbruster
2007-01-24 15:25                                           ` Gerd Hoffmann
2007-01-25 13:16                                   ` 32-on-64 broken in unstable Gerd Hoffmann
2007-01-25 13:25                                     ` Keir Fraser
2007-01-25 13:34                                       ` Gerd Hoffmann
2007-01-22 15:22                               ` 32-on-64: pvfb issue Markus Armbruster
2007-01-22 15:33                                 ` Gerd Hoffmann
2007-01-22 15:40                                   ` Keir Fraser
2007-01-19 16:06                         ` Markus Armbruster
2007-01-22  7:56                           ` Gerd Hoffmann
2007-01-19 10:43       ` Ian Campbell
2007-01-19 12:03         ` Markus Armbruster
2007-01-22 18:32       ` Does vt-x itself have perf. impact on Hypervisor w/o considering HVM? Liang Yang
2007-01-23 10:05         ` [Xen-users] " Petersson, Mats
2007-01-23 16:15           ` Liang Yang
2007-01-23 16:33             ` Petersson, Mats [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=907625E08839C4409CE5768403633E0B018E18C3@sefsexmb1.amd.com \
    --to=mats.petersson@amd.com \
    --cc=multisyncfe991@hotmail.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xen-users@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.