From: Joerg Rodel <joerg.roedel@amd.com>
To: Avi Kivity <avi@qumranet.com>
Cc: Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, stable@kernel.org,
Alexander Graf <agraf@suse.de>
Subject: Re: [PATCH] KVM: SVM: fix random segfaults with NPT enabled
Date: Thu, 28 Aug 2008 16:58:38 +0200 [thread overview]
Message-ID: <20080828145838.GA4971@amd.com> (raw)
In-Reply-To: <48B587EC.7020606@qumranet.com>
On Wed, Aug 27, 2008 at 07:59:24PM +0300, Avi Kivity wrote:
> Avi Kivity wrote:
> >Joerg Rodel wrote:
> >>>Meanwhile, I applied the patch, but I'm very worried about this.
> >>>
> >>
> >>Yes, we are also worried. Another question is why this only happens with
> >>NPT. The SoftMMU code should also fail with shadow paging if there is a
> >>bug.
> >>
> >
> >Slightly different paths -- direct_map vs page_fault. Also, with npt, all cpus will access the same pte
> >that's being modified; without npt, faults on the same page will result in different ptes being instantiated,
> >as each access will be from a different guest pte.
> >
> >Maybe we should turn on the dirty bit in the instantiated ptes -- that will reduce the processor's mucking
> >about with them.
> >
>
> I meant the accessed bit. The dirty bit is always set, but the accessed bit it not, due to a bug. Fixing it
> doesn't help, though.
I did a bit meditation about the softmmu code today. In the path of the
NPT fault the function kvm_mmu_free_some_pages() is called which itself
calls kvm_mmu_zap_page(). There the two functions
kvm_mmu_page_unlink_children() and kvm_mmu_unlink_parents() are called.
They both call mmu_page_remove_parent_pte() which modifies ptes. But
only the first function, kvm_mmu_page_unlink_children(), flushes remote
TLBs. The function kvm_mmu_unlink_parents() does not. Is this correct?
If yes, why?
Joerg
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
next prev parent reply other threads:[~2008-08-28 14:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-27 12:18 [PATCH] KVM: SVM: fix random segfaults with NPT enabled Joerg Rodel
2008-08-27 13:11 ` Avi Kivity
2008-08-27 13:53 ` Avi Kivity
2008-08-27 13:57 ` Joerg Rodel
2008-08-27 15:22 ` Avi Kivity
2008-08-27 15:35 ` Joerg Roedel
2008-08-27 15:50 ` Avi Kivity
2008-08-27 16:27 ` Joerg Rodel
2008-08-27 16:49 ` Avi Kivity
2008-08-27 16:59 ` Avi Kivity
2008-08-28 14:58 ` Joerg Rodel [this message]
2008-08-28 15:15 ` Avi Kivity
2008-08-28 15:19 ` Joerg Roedel
2008-08-28 15:47 ` Avi Kivity
2008-08-28 15:29 ` Avi Kivity
2008-08-28 15:58 ` Joerg Roedel
2008-08-27 13:53 ` Joerg Rodel
2008-08-27 15:21 ` Avi Kivity
2008-08-27 15:32 ` Joerg Roedel
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=20080828145838.GA4971@amd.com \
--to=joerg.roedel@amd.com \
--cc=agraf@suse.de \
--cc=avi@qumranet.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=stable@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.