From: Valentine Sinitsyn <valentine.sinitsyn@gmail.com>
To: Jan Kiszka <jan.kiszka@web.de>, kvm <kvm@vger.kernel.org>,
Jailhouse <jailhouse-dev@googlegroups.com>
Subject: Re: SVM: vmload/vmsave-free VM exits?
Date: Tue, 07 Apr 2015 11:10:43 +0500 [thread overview]
Message-ID: <552374E3.1060707@gmail.com> (raw)
In-Reply-To: <55236E6F.7090705@web.de>
Hi Jan,
On 07.04.2015 10:43, Jan Kiszka wrote:
> On 2015-04-05 19:12, Valentine Sinitsyn wrote:
>> Hi Jan,
>>
>> On 05.04.2015 13:31, Jan Kiszka wrote:
>>> studying the VM exit logic of Jailhouse, I was wondering when AMD's
>>> vmload/vmsave can be avoided. Jailhouse as well as KVM currently use
>>> these instructions unconditionally. However, I think both only need
>>> GS.base, i.e. the per-cpu base address, to be saved and restored if no
>>> user space exit or no CPU migration is involved (both is always true for
>>> Jailhouse). Xen avoids vmload/vmsave on lightweight exits but it also
>>> still uses rsp-based per-cpu variables.
>>>
>>> So the question boils down to what is generally faster:
>>>
>>> A) vmload
>>> vmrun
>>> vmsave
>>>
>>> B) wrmsrl(MSR_GS_BASE, guest_gs_base)
>>> vmrun
>>> rdmsrl(MSR_GS_BASE, guest_gs_base)
>>>
>>> Of course, KVM also has to take into account that heavyweight exits
>>> still require vmload/vmsave, thus become more expensive with B) due to
>>> the additional MSR accesses.
>>>
>>> Any thoughts or results of previous experiments?
>> That's a good question, I also thought about it when I was finalizing
>> Jailhouse AMD port. I tried "lightweight exits" with apic-demo but it
>> didn't seem to affect the latency in any noticeable way. That's why I
>> decided not to push the patch (in fact, I was even unable to find it now).
>>
>> Note however that how AMD chips store host state during VM switches are
>> implementation-specific. I did my quick experiments on one CPU only, so
>> your mileage may vary.
>>
>> Regarding your question, I feel B will be faster anyways but again I'm
>> afraid that the gain could be within statistical error of the experiment.
>
> It is, at least 160 cycles with hot caches on an AMD A6-5200 APU, more
> towards 600 if they are colder (added some usleep to each loop in the test).
Great, thanks. Could you post absolute numbers, i.e how long do A and B
take on your CPU?
Valentine
--
You received this message because you are subscribed to the Google Groups "Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
next prev parent reply other threads:[~2015-04-07 6:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-05 8:31 SVM: vmload/vmsave-free VM exits? Jan Kiszka
2015-04-05 17:12 ` Valentine Sinitsyn
2015-04-07 5:43 ` Jan Kiszka
2015-04-07 6:10 ` Valentine Sinitsyn [this message]
2015-04-07 6:13 ` Jan Kiszka
2015-04-07 6:19 ` Valentine Sinitsyn
2015-04-07 6:23 ` Jan Kiszka
2015-04-07 6:29 ` Valentine Sinitsyn
2015-04-07 6:35 ` Jan Kiszka
2015-04-13 7:01 ` Jan Kiszka
2015-04-13 17:29 ` Avi Kivity
2015-04-13 17:35 ` Jan Kiszka
2015-04-13 17:41 ` Avi Kivity
2015-04-13 17:48 ` Avi Kivity
2015-04-13 17:57 ` Jan Kiszka
2015-04-13 18:07 ` Avi Kivity
2015-04-13 18:14 ` Jan Kiszka
2015-04-14 6:39 ` Valentine Sinitsyn
2015-04-14 7:02 ` Jan Kiszka
2015-04-14 7:11 ` Valentine Sinitsyn
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=552374E3.1060707@gmail.com \
--to=valentine.sinitsyn@gmail.com \
--cc=jailhouse-dev@googlegroups.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
/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.