From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: kvm-devel <kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: [PATCH] Lazy FPU save/restore for VT
Date: Thu, 26 Apr 2007 19:03:59 +0300 [thread overview]
Message-ID: <4630CD6F.8050706@qumranet.com> (raw)
In-Reply-To: <4630CA1E.2000808-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Anthony Liguori wrote:
> Howdy,
>
> Attached patch implements lazy-fpu save/restore for VT. VMEXIT time
> improves by about 10% (~550 cycles). I had to do a couple more things
> to get it working than I had to do with SVM. I changed the CR0 host
> mask to be all 1's so that any attempt to write to CR0 causes a
> VMEXIT. I don't think there are any remaining bits now that we want
> to trap TS that are safe for the guest to access and are in the
> fast-paths.
Great! With a couple more msrs we'll get to 50% off what we had two
weeks ago.
>
> Since we're trapping TS, I had to implement CLTS exit handling.
> vcpu->cr0 also had a rather bizarre life cycle. After a set_cr0, it
> was a proper shadow of the guest's CR0. However, after a decache_cr0,
> it would contain the host's version of the bits covered by the CR0
> host mask so it was no longer a proper shadow.
>
> I got rid of the CR0 caching and made vcpu->cr0 always be equivalent
> to CR0_READ_SHADOW. Once these changes were made, the rest of the
> patch was much like the SVM one.
>
>
> - if ((intr_info & INTR_INFO_INTR_TYPE_MASK) == 0x200) { /* nmi */
> + switch (intr_info & INTR_INFO_VECTOR_MASK) {
> + case NMI_VECTOR:
> asm ("int $2");
> return 1;
> + case NM_VECTOR:
> + vcpu->fpu_active = 1;
> + vmcs_clear_bits(EXCEPTION_BITMAP, 1 << NM_VECTOR);
> + if (!(vcpu->cr0 & CR0_TS_MASK))
> + vmcs_clear_bits(GUEST_CR0, CR0_TS_MASK);
> + return 1;
> }
>
I'd like to be conservative here and not depend just on the vector:
check type == 2 for nmi, and type == 6, vector == NM for #NM. In fact,
I see that is_page_fault() and is_external_interrupt() implement
something like that already.
Also, can you split the patch into the cr0 cache fix and the lazy fpu?
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
next prev parent reply other threads:[~2007-04-26 16:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-26 15:49 [PATCH] Lazy FPU save/restore for VT Anthony Liguori
[not found] ` <4630CA1E.2000808-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2007-04-26 16:03 ` Avi Kivity [this message]
[not found] ` <4630CD6F.8050706-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-04-26 16:10 ` Anthony Liguori
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=4630CD6F.8050706@qumranet.com \
--to=avi-atkuwr5tajbwk0htik3j/w@public.gmane.org \
--cc=aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
--cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox