Correct way of tracking reads on given gfn ?

Correct way of tracking reads on given gfn ?

[Sunil]

Hello List,

(1) What is the correct way of tracking reads on given gfn ?

Looks like functions rmap_write_protect(kvm, gfn) and
kvm_mmu_rmap_write_protect(kvm, gfn, slot) removes the write
permission for the given page, by flipping write bit using
PT_WRITABLE_MASK. Thus trapping writes.

For trapping reads, are there similar routines ? If not, I see
equivalent flag PM_PRESENT_MASK. Thus one way probably is writing
wrapper routines similar to above to flip both read(present) and write
bits. Or would it be just enough to drop the spte instead using
function drop_spte() ?

(2) Is kvm_flush_remote_tlbs() required after either of above approaches ?
Is kvm_flush_remote_tlbs() correct function to flush tlbs ?

--

Re: Correct way of tracking reads on given gfn ?

[Paolo Bonzini]

Il 09/09/2013 11:45, Sunil ha scritto:
> Hello List,
> 
> (1) What is the correct way of tracking reads on given gfn ?
> 
> Looks like functions rmap_write_protect(kvm, gfn) and
> kvm_mmu_rmap_write_protect(kvm, gfn, slot) removes the write
> permission for the given page, by flipping write bit using
> PT_WRITABLE_MASK. Thus trapping writes.
> 
> For trapping reads, are there similar routines ? If not, I see
> equivalent flag PM_PRESENT_MASK. Thus one way probably is writing
> wrapper routines similar to above to flip both read(present) and write
> bits. Or would it be just enough to drop the spte instead using
> function drop_spte() ?

If you are using EPT and your processor has the accessed and dirty bits
for EPT page tables (cat /sys/module/kvm_intel/parameters/eptad), you
could use the accessed bit to track reads.  They wouldn't trap, but you
would be able to poll the EPT page tables.

Paolo

> (2) Is kvm_flush_remote_tlbs() required after either of above approaches ?
> Is kvm_flush_remote_tlbs() correct function to flush tlbs ?
> 
> --
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Correct way of tracking reads on given gfn ?

[SPA]

Thanks Paolo.

Is there a way where reads would trap ?

I explored a bit on PM_PRESENT_MASK.  Though its not READ bit, but a
PRESENT bit,  it looks like it should generate traps on reads if this
bit is reset. From code, looks like rmap_write_protect() like function
I stated in previous mail should do. Would this approach work ? Are
there any glaring problems with this approach ?

--
Sunil

On Mon, Sep 9, 2013 at 3:08 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 09/09/2013 11:45, Sunil ha scritto:
>> Hello List,
>>
>> (1) What is the correct way of tracking reads on given gfn ?
>>
>> Looks like functions rmap_write_protect(kvm, gfn) and
>> kvm_mmu_rmap_write_protect(kvm, gfn, slot) removes the write
>> permission for the given page, by flipping write bit using
>> PT_WRITABLE_MASK. Thus trapping writes.
>>
>> For trapping reads, are there similar routines ? If not, I see
>> equivalent flag PM_PRESENT_MASK. Thus one way probably is writing
>> wrapper routines similar to above to flip both read(present) and write
>> bits. Or would it be just enough to drop the spte instead using
>> function drop_spte() ?
>
> If you are using EPT and your processor has the accessed and dirty bits
> for EPT page tables (cat /sys/module/kvm_intel/parameters/eptad), you
> could use the accessed bit to track reads.  They wouldn't trap, but you
> would be able to poll the EPT page tables.
>
> Paolo
>
>> (2) Is kvm_flush_remote_tlbs() required after either of above approaches ?
>> Is kvm_flush_remote_tlbs() correct function to flush tlbs ?
>>
>> --
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Correct way of tracking reads on given gfn ?

[Paolo Bonzini]

Il 09/09/2013 12:22, SPA ha scritto:
> Thanks Paolo.
> 
> Is there a way where reads would trap ?
> 
> I explored a bit on PM_PRESENT_MASK.  Though its not READ bit, but a
> PRESENT bit,  it looks like it should generate traps on reads if this
> bit is reset. From code, looks like rmap_write_protect() like function
> I stated in previous mail should do. Would this approach work ? Are
> there any glaring problems with this approach ?

I cannot say right away.  Another way could be to set reserved bits to
generate EPT misconfigurations.  See ept_set_mmio_spte_mask and
is_mmio_spte.

This would trap both reads and writes.

Paolo

Re: Correct way of tracking reads on given gfn ?

[Gleb Natapov]

On Mon, Sep 09, 2013 at 12:53:02PM +0200, Paolo Bonzini wrote:
> Il 09/09/2013 12:22, SPA ha scritto:
> > Thanks Paolo.
> > 
> > Is there a way where reads would trap ?
> > 
> > I explored a bit on PM_PRESENT_MASK.  Though its not READ bit, but a
> > PRESENT bit,  it looks like it should generate traps on reads if this
> > bit is reset. From code, looks like rmap_write_protect() like function
> > I stated in previous mail should do. Would this approach work ? Are
> > there any glaring problems with this approach ?
> 
> I cannot say right away.  Another way could be to set reserved bits to
> generate EPT misconfigurations.  See ept_set_mmio_spte_mask and
> is_mmio_spte.
> 
> This would trap both reads and writes.
> 
Dropping all sptes will also work, but trapping each read access will be dog slow. QEMU
emulation will be much faster.

--
			Gleb.

Re: Correct way of tracking reads on given gfn ?

[Arthur Chunqi Li]

On Mon, Sep 9, 2013 at 8:29 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Mon, Sep 09, 2013 at 12:53:02PM +0200, Paolo Bonzini wrote:
>> Il 09/09/2013 12:22, SPA ha scritto:
>> > Thanks Paolo.
>> >
>> > Is there a way where reads would trap ?
>> >
>> > I explored a bit on PM_PRESENT_MASK.  Though its not READ bit, but a
>> > PRESENT bit,  it looks like it should generate traps on reads if this
>> > bit is reset. From code, looks like rmap_write_protect() like function
>> > I stated in previous mail should do. Would this approach work ? Are
>> > there any glaring problems with this approach ?
>>
>> I cannot say right away.  Another way could be to set reserved bits to
>> generate EPT misconfigurations.  See ept_set_mmio_spte_mask and
>> is_mmio_spte.
>>
>> This would trap both reads and writes.
>>
> Dropping all sptes will also work, but trapping each read access will be dog slow. QEMU
> emulation will be much faster.
Hi Gleb,
I'm interested in this topic, what do you mean by QEMU emulation? Do
you mean the functions in arch/x86/kvm/emulate.c? In what scenario
will KVM call these functions?

Thanks,
Arthur
>
> --
>                         Gleb.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Correct way of tracking reads on given gfn ?

[Gleb Natapov]

On Tue, Sep 10, 2013 at 09:12:11AM +0800, Arthur Chunqi Li wrote:
> On Mon, Sep 9, 2013 at 8:29 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Mon, Sep 09, 2013 at 12:53:02PM +0200, Paolo Bonzini wrote:
> >> Il 09/09/2013 12:22, SPA ha scritto:
> >> > Thanks Paolo.
> >> >
> >> > Is there a way where reads would trap ?
> >> >
> >> > I explored a bit on PM_PRESENT_MASK.  Though its not READ bit, but a
> >> > PRESENT bit,  it looks like it should generate traps on reads if this
> >> > bit is reset. From code, looks like rmap_write_protect() like function
> >> > I stated in previous mail should do. Would this approach work ? Are
> >> > there any glaring problems with this approach ?
> >>
> >> I cannot say right away.  Another way could be to set reserved bits to
> >> generate EPT misconfigurations.  See ept_set_mmio_spte_mask and
> >> is_mmio_spte.
> >>
> >> This would trap both reads and writes.
> >>
> > Dropping all sptes will also work, but trapping each read access will be dog slow. QEMU
> > emulation will be much faster.
> Hi Gleb,
> I'm interested in this topic, what do you mean by QEMU emulation? Do
> you mean the functions in arch/x86/kvm/emulate.c? In what scenario
> will KVM call these functions?
> 
No, I mean don't use KVM at all.

--
			Gleb.