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