Re: guest PTE write emulation

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Dong, Eddie wrote:
> BTW, in kvm_mmu_pte_write, I feel a little bit stranger for following
> code:
>
>
>   
>>                level = page->role.level;
>>                npte = 1;
>>                if (page->role.glevels == PT32_ROOT_LEVEL) {
>>                        page_offset <<= 1;      /* 32->64 */          
>> /* 
>>                         * A 32-bit pde maps 4MB while the shadow pdes
>> map 
>>                         * only 2MB.  So we need to double the offset
>> again 
>>                         * and zap two pdes instead of one.           
>>                        */ if (level == PT32_ROOT_LEVEL) {
>>                                page_offset &= ~7; /* kill rounding
>>                                error */ page_offset <<= 1;
>>                                npte = 2;
>>     
>
> 1st of all, do we have 2MB pde in shadow PT? I think we don't provide
> contiguous physical mfn for shadow PT.
>   

No, we don't.  The intent is that a shadow pde maps 2MB through a shadow 
page table, not through a a large host page.

> If page->role.level == PT32_ROOT_LEVEL, sequencial call of
> mmu_pte_write_new_pte will simply return w/o any real spte operation.
> Does this ever happen w/ a real spte write?
>   

Yes.  This is a missed optimization, but I don't think that it impacts 
performance.  pde updates are very rare.

> I tried a 32 bits FC5 with no found of this combination till Linux boot.
>
>   

Usually pde updates are before the page directory is shadowed, so the 
host doesn't see it.

>>                        }
>>                        quadrant = page_offset >> PAGE_SHIFT;
>>                        page_offset &= ~PAGE_MASK;
>>                        if (quadrant != page->role.quadrant)
>>                                continue;
>>                }
>>                spte = &page->spt[page_offset / sizeof(*spte)];
>>                while (npte--) {
>>                        mmu_pte_write_zap_pte(vcpu, page, spte);
>>                        mmu_pte_write_new_pte(vcpu, page,
>> spte, new, bytes);
>>     
>
> If above comments is correct, we need to provide an increased (gfn) gpte
> so that the next 2MB spte can have right gfn from gpte. Am I missing
> something?

On a pte update, npte will always be 1.  On a pde update, we won't do 
anything in mmu_pte_write_new_pte because it doesn't handle pdes.  If we 
extend it to handle pdes, then we need either to modify the new gpde or 
to have the update take the quadrant into account.

I don't think there's a real need to extend it though.  A pde write will 
usually be followed by lots of pte writes.

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


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/