On Thu, Aug 9, 2012 at 3:15 AM, 陳韋任 (Wei-Ren Chen)
<che...@iis.sinica.edu.tw> wrote:
> Hi Blue,
>
>> > You mean like what KVM does for shadow page table? I think we should
>> > mprotect the QEMU virtual memory which is allocated as a guest page
>> > table by the guest OS, right? If so, how do we know what (QEMU) virtual
>> > memory we should protect? The other way I was thought of is to see if
>> > we can aware some guest code sequence modifying pte, but so far no clue
>> > to it.
>>
>> See for example notdirty and watch_mem handling in exec.c.
>
> There are functions st{l,q}_phys_notdirty and notdirty_mem_write, you
> mean which one? Sadly, I am not familiar with the memory stuff. Could
> you explain a little bit about what notdirty and watch_mem does? Googleing
> doesn't help much...
Dirty tracking (notdirty_mem_write etc.) is used to handle
self-modifying code and to optimize video RAM access.
In the SMC case, pages with code are marked as not dirty until they
are written to. When they are thus dirtied, the TLB entries and TBs
are purged.
A simplistic way to handle video memory would be to track accesses
like any other device MMIO. But it's much faster if the guest can
access video RAM directly like system RAM. Then the video device
emulations track writes with another dirty bit and only redraw regions
which have been written to since last refresh.
For watchpoints, normal memory is replaced by watch_mem handlers (like
MMIO) for the page in concern. Then the watch memory handlers are
called only for those pages instead of for example slowing down all
memory accesses.
In your case, a new dirty bit could be added, or the page table area
could be replaced by dedicated MMIO.
>
> Thanks!
>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Computer Systems Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
> Homepage: http://people.cs.nctu.edu.tw/~chenwj
