From: Paolo Bonzini <pbonzini@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>, kvm <kvm@vger.kernel.org>
Subject: Re: KVM x86: Infinite loop on updating accessed bit in r/o page table
Date: Tue, 25 Feb 2014 11:57:21 +0100 [thread overview]
Message-ID: <530C7711.1050102@redhat.com> (raw)
In-Reply-To: <530B8F92.50202@siemens.com>
Il 24/02/2014 19:29, Jan Kiszka ha scritto:
> Hi,
>
> I noticed that KVM (with VMX at least) enters an inifite loop of
> vmentries and ept-violations when it has to set the accessed bit in a
> guest page table that is in read-only memory (namely: the F-segment of
> the BIOS). I don't think this is the proper reaction...
>
> Jan
Thanks, I'll try to reproduce this. Does it work with shadow page tables?
I'm asking because this commit wanted to fix something similar for the shadow
page table case:
commit ba6a3541545542721ce821d1e7e5ce35752e6fdf
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Mon Sep 9 13:52:33 2013 +0200
KVM: mmu: allow page tables to be in read-only slots
Page tables in a read-only memory slot will currently cause a triple
fault because the page walker uses gfn_to_hva and it fails on such a slot.
OVMF uses such a page table; however, real hardware seems to be fine with
that as long as the accessed/dirty bits are set. Save whether the slot
is readonly, and later check it when updating the accessed and dirty bits.
Reviewed-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
even though OVMF sets the accessed/dirty bits so it's not exactly the same
scenario.
Note that NPT simply does not support this. Page tables must be writable
in the NPT page tables, according to the AMD manual.
Paolo
next prev parent reply other threads:[~2014-02-25 10:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-24 18:29 KVM x86: Infinite loop on updating accessed bit in r/o page table Jan Kiszka
2014-02-25 10:57 ` Paolo Bonzini [this message]
2014-02-25 11:23 ` Jan Kiszka
2014-02-25 14:11 ` Paolo Bonzini
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=530C7711.1050102@redhat.com \
--to=pbonzini@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.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.