From: Joerg Roedel <joro@8bytes.org>
To: Nadav Har'El <nyh@math.technion.ac.il>
Cc: Chris Wright <chrisw@redhat.com>, kvm@vger.kernel.org, avi@redhat.com
Subject: Re: KVM call minutes for Sept 21
Date: Wed, 22 Sep 2010 21:48:28 +0200 [thread overview]
Message-ID: <20100922194828.GM15338@8bytes.org> (raw)
In-Reply-To: <20100922174943.GB12492@fermat.math.technion.ac.il>
On Wed, Sep 22, 2010 at 07:49:43PM +0200, Nadav Har'El wrote:
> I believe that in the current state of the code, nested VMX adds little
> complexity to the non-nested code - just a few if's. Of course, it also
> adds a lot of new code, but none of this code gets run in the non-nested
> case.
As it is with Nested-SVM.
> The maintenance issues I see are the other way around - i.e., once
> in a while when non-nested changes are made to KVM, nested stops working and
> needs to be fixed. A prime example of this was the lazy FPU loading added in
> the beginning of the year, which broke our assumption that L0's
> CR0_GUEST_HOST_MASK always has all its bits on, making nested stop working
> until I fixed it (it wasn't easy debugging these problems ;-)).
> I wholeheartedly agree that if nobody continues to maintain nested VMX,
> it can and will become "stale" and may stop working after unrelated code
> in KVM is modified. Adding tests can help here (so that when someone modifies
> some non-nested KVM feature he will at least know that he broke nested), but
> definitely, we'll need to continue having someone who is interested in
> keeping the nested VMX working. In the forseeable future, I'll volunteer
> to be that someone.
I know very well what you are talking about. It has happend a couple of
times to nested SVM that it broke because of other unrelated patches. I
also had to fix nested SVM when the new lazy FPU switching code was
merged. The best way to cope with that in the future is to restructure
the code to that it is more unlikely to break.
One example: I had bugs where the generic KVM code called into SVM
specific parts which intended to changed state in the L1 VMCB. But since
L2 was running this was changed in the VMCB of L2 and got lost when the
next vmexit was emulated (which is really bad for tsc_offset for
example).
Another thing is intercepts. When KVM wants to change the intercept
masks for L1 you have to recalculate the merged intercept masks for L2.
The best strategy to cope with that is to add accessor functions which
change L1 state and which are aware of nesting.
Joerg
next prev parent reply other threads:[~2010-09-22 19:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-21 18:05 KVM call minutes for Sept 21 Chris Wright
2010-09-21 18:23 ` Anthony Liguori
2010-09-22 0:04 ` Nadav Har'El
2010-09-22 1:48 ` Chris Wright
2010-09-22 17:49 ` Nadav Har'El
2010-09-22 18:03 ` Anthony Liguori
2010-09-22 19:34 ` Joerg Roedel
2010-09-22 19:48 ` Joerg Roedel [this message]
2010-09-22 9:02 ` Gleb Natapov
2010-09-22 16:29 ` Nadav Har'El
2010-09-22 17:47 ` Gleb Natapov
2010-09-22 19:20 ` Joerg Roedel
2010-09-22 20:18 ` Gleb Natapov
2010-09-22 23:00 ` Nadav Har'El
2010-09-26 14:03 ` Avi Kivity
2010-09-26 20:25 ` Joerg Roedel
2010-09-27 8:36 ` Avi Kivity
2010-09-27 14:18 ` Gleb Natapov
2010-09-27 14:22 ` Avi Kivity
2010-09-26 13:27 ` Avi Kivity
2010-09-26 14:28 ` Nadav Har'El
2010-09-26 14:50 ` Avi Kivity
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=20100922194828.GM15338@8bytes.org \
--to=joro@8bytes.org \
--cc=avi@redhat.com \
--cc=chrisw@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=nyh@math.technion.ac.il \
/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