* KVM x86: Infinite loop on updating accessed bit in r/o page table
@ 2014-02-24 18:29 Jan Kiszka
2014-02-25 10:57 ` Paolo Bonzini
0 siblings, 1 reply; 4+ messages in thread
From: Jan Kiszka @ 2014-02-24 18:29 UTC (permalink / raw)
To: kvm
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
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: KVM x86: Infinite loop on updating accessed bit in r/o page table
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
2014-02-25 11:23 ` Jan Kiszka
0 siblings, 1 reply; 4+ messages in thread
From: Paolo Bonzini @ 2014-02-25 10:57 UTC (permalink / raw)
To: Jan Kiszka, kvm
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: KVM x86: Infinite loop on updating accessed bit in r/o page table
2014-02-25 10:57 ` Paolo Bonzini
@ 2014-02-25 11:23 ` Jan Kiszka
2014-02-25 14:11 ` Paolo Bonzini
0 siblings, 1 reply; 4+ messages in thread
From: Jan Kiszka @ 2014-02-25 11:23 UTC (permalink / raw)
To: Paolo Bonzini, kvm
On 2014-02-25 11:57, Paolo Bonzini wrote:
> 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?
It gets beyond the point where Accessed should be set but loops over
trying to update Dirty in the page table. QEMU in emulation mode simply
ignores both write attempts. I think our ROM should behave like this,
i.e. simply swallow writes.
> 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.
We could still emulate the instruction in such a case to get beyond the
write fault. Slow but more correct, I suppose.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: KVM x86: Infinite loop on updating accessed bit in r/o page table
2014-02-25 11:23 ` Jan Kiszka
@ 2014-02-25 14:11 ` Paolo Bonzini
0 siblings, 0 replies; 4+ messages in thread
From: Paolo Bonzini @ 2014-02-25 14:11 UTC (permalink / raw)
To: Jan Kiszka, kvm
Il 25/02/2014 12:23, Jan Kiszka ha scritto:
>> > 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.
> We could still emulate the instruction in such a case to get beyond the
> write fault. Slow but more correct, I suppose.
They must be writable always, even if A=D=1. So the only solution would
be to emulate everything that puts page tables in ROMs, which is really
too slow to be viable. We're really talking 50-100 times slower than
bare metal.
Paolo
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-02-25 14:11 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2014-02-25 11:23 ` Jan Kiszka
2014-02-25 14:11 ` Paolo Bonzini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).