[Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity <avi@redhat.com>]

Jan Kiszka wrote:
> Avi Kivity wrote:
>   
>> Jan Kiszka wrote:
>>     
>>> And the fact that kqemu has to use tcg in order to achieve a reasonable
>>> performance is rather a disadvantage. The complexity and overhead for
>>> synchronizing tcg with the in-kernel accelerator is enormous. If there
>>> were a feasible way to overcome this with kqemu, it would benefit a lot.
>>> But unfortunately there is none (given you don't want to invest
>>> reasonable efforts).
>>>   
>>>       
>> Note that kvm suffers from something similar (to a smaller magnitude) as
>> well: if a guest pages in its page tables, kvm knows nothing about it
>> and will thus have outdated shadows.  To date we haven't encountered a
>> problem with it, but it's conceivable.  I think Windows can page its
>> page tables, but maybe it's disabled by default, or maybe it doesn't dma
>> directly into the page tables.
>>     
>
> Can't follow, always thought that kernel space gets informed when some
> I/O operation handled by user space modified an "interesting" page.
>   

It doesn't.  Host userspace has unrestricted access to guest memory.

>> Not sure how to fix.  Maybe write protect the host page tables when we
>>     
>
> You mean guest page table?
>   

Both :)

When kvm write protects a guest page table in the shadow page table 
entries pointing to that guest page, it should also write protect the 
guest page table in the host page table entries to the same guest page.

>> shadow a page table, and get an mmu notifier to tell us when its made
>> writable?  Seems expensive.  Burying head in sand is much easier.
>>
>>     
>
> Does this still apply to nested paging? I guess (hope) not...
>   

No, nested paging brings cancer and cures world peace.  Or something.

-- 
error compiling committee.c: too many arguments to function