From: Marcelo Tosatti <mtosatti@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org, sheng.yang@intel.com
Subject: Re: [patch 3/5] KVM: MMU: add kvm_mmu_shadow_walk helper
Date: Wed, 10 Jun 2009 10:17:31 -0300 [thread overview]
Message-ID: <20090610131731.GG6672@amt.cnet> (raw)
In-Reply-To: <4A2FA5D3.9020604@redhat.com>
On Wed, Jun 10, 2009 at 03:23:47PM +0300, Avi Kivity wrote:
> Marcelo Tosatti wrote:
>>> Isn't it simpler to invoke for_each_shadow_entry(), instead of
>>> defining a callback and calling it?
>>>
>>> We had those callbacks once, then switched to for_each.
>>>
>>
>> The point is its exported to use in a external module (kvm-intel.ko),
>> so you hide the details (such as locking) in the kvm_mmu_shadow_walk
>> helper. Let me know how do you prefer this to be.
>>
>
> Ah, you're right.
>
> I don't think it's worthwhile to add all this just for debugging. You
> can add a function that dumps the spte chain as well as the features
> MSR, and we can decode it by hand when we see it. Disadvantage is more
> work for us when we hit the bug, but at least that function is reusable
> in other contexts.
The problem is if someone hits the bug who has no possibility of
reporting the printks. Nice thing about the WARN_ON's there is you can
look up kerneloops.org, match the line number to the kernel version,
and narrow down what bits are wrong (you still need reporter to send
contents of dmesg for full spte value).
Also the bit-by-bit validity checks (the inspect_spte function in vmx.c)
can be used in the mmu audit code (thats the reason for print=0 in the
callback parameters), so it is reusable in other contexes.
What you dislike is hardcoding the bits checked in C code? Don't worry
about the level stuff, will be handled next.
next prev parent reply other threads:[~2009-06-10 13:18 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-09 21:30 [patch 0/5] VMX EPT misconfigurtion handler Marcelo Tosatti
2009-06-09 21:30 ` [patch 1/5] KVM: VMX: more MSR_IA32_VMX_EPT_VPID_CAP capability bits Marcelo Tosatti
2009-06-09 21:30 ` [patch 2/5] KVM: MMU: make for_each_shadow_entry aware of largepages Marcelo Tosatti
2009-06-10 9:15 ` Avi Kivity
2009-06-10 9:21 ` Avi Kivity
2009-06-11 12:38 ` Marcelo Tosatti
2009-06-11 14:17 ` Avi Kivity
2009-06-09 21:30 ` [patch 3/5] KVM: MMU: add kvm_mmu_shadow_walk helper Marcelo Tosatti
2009-06-10 9:17 ` Avi Kivity
2009-06-10 12:14 ` Marcelo Tosatti
2009-06-10 12:23 ` Avi Kivity
2009-06-10 13:17 ` Marcelo Tosatti [this message]
2009-06-10 15:24 ` Avi Kivity
2009-06-11 3:20 ` Avi Kivity
2009-06-11 14:02 ` [patch 0/5] VMX EPT misconfiguration handler v2 Marcelo Tosatti
2009-06-11 14:02 ` [patch 1/5] KVM: VMX: more MSR_IA32_VMX_EPT_VPID_CAP capability bits Marcelo Tosatti
2009-06-11 14:02 ` [patch 2/5] KVM: MMU: make for_each_shadow_entry aware of largepages Marcelo Tosatti
2009-06-11 14:02 ` [patch 3/5] KVM: MMU: add kvm_mmu_get_spte_hierarchy helper Marcelo Tosatti
2009-06-11 14:31 ` Avi Kivity
2009-06-11 15:07 ` [patch 0/5] VMX EPT misconfiguration handler v3 Marcelo Tosatti
2009-06-14 9:54 ` Avi Kivity
2009-06-11 15:07 ` [patch 1/5] KVM: VMX: more MSR_IA32_VMX_EPT_VPID_CAP capability bits Marcelo Tosatti
2009-06-11 15:07 ` [patch 2/5] KVM: MMU: make for_each_shadow_entry aware of largepages Marcelo Tosatti
2009-06-11 15:07 ` [patch 3/5] KVM: MMU: add kvm_mmu_get_spte_hierarchy helper Marcelo Tosatti
2009-06-11 15:07 ` [patch 4/5] KVM: VMX: EPT misconfiguration handler Marcelo Tosatti
2009-06-11 15:07 ` [patch 5/5] KVM: VMX: conditionally disable 2M pages Marcelo Tosatti
2009-06-11 14:02 ` [patch 4/5] KVM: VMX: EPT misconfiguration handler Marcelo Tosatti
2009-06-11 14:02 ` [patch 5/5] KVM: VMX: conditionally disable 2M pages Marcelo Tosatti
2009-06-09 21:30 ` [patch 4/5] KVM: VMX: EPT misconfiguration handler Marcelo Tosatti
2009-06-09 21:30 ` [patch 5/5] KVM: VMX: conditionally disable 2M pages Marcelo Tosatti
2009-06-10 9:18 ` Avi Kivity
2009-06-10 9:13 ` [patch 0/5] VMX EPT misconfigurtion handler Yang, Sheng
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=20090610131731.GG6672@amt.cnet \
--to=mtosatti@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=sheng.yang@intel.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.