lkml.org 
[lkml]   [2009]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 4/7] kvm mmu: implement necessary data structures for second huge page accounting
    On Sun, Mar 29, 2009 at 04:15:07PM +0300, Avi Kivity wrote:
    > Joerg Roedel wrote:
    >>>
    >>>> +static int has_wrprotected_largepage(struct kvm *kvm, gfn_t gfn)
    >>>> +{
    >>>> + struct kvm_memory_slot *slot;
    >>>> + int *hugepage_idx;
    >>>> +
    >>>> + gfn = unalias_gfn(kvm, gfn);
    >>>> + slot = gfn_to_memslot_unaliased(kvm, gfn);
    >>>> + if (slot) {
    >>>> + hugepage_idx = slot_hugepage_idx(gfn, slot);
    >>>>
    >>> slot_largepage_idx() here?
    >>>
    >>> I don't think we ever write protect large pages, so why is this needed?
    >>>
    >>
    >> For 2mb pages we need to check if there is a write-protected 4k page in it
    >> before we map a 2mb page for writing. If there is any write-protected 4k
    >> page in a 2mb area this 2mb page is considered write-protected. These
    >> 'write-protected' 2mb pages are accounted in the account_shadow()
    >> function. This information is taken into account when we decide if we
    >> can map a guest 1gb page as a 1gb page on the host too.
    >>
    >
    > account_shadowed() actually increments a hugepage write_count by 1 for
    > every 4K page, not 2M page, if I read the code correctly. The code I
    > commented on is right though.
    >
    > The naming is confusing. I suggest
    > has_wrprotected_page_in_{large,huge}page(). although with the a level
    > parameter we can keep has_wrprotected_page().

    Yeah true, the name is a bit confusing. I think a level parameter for
    has_wrprotected_page() is the best solution.

    Joerg


    \
     
     \ /
      Last update: 2009-03-29 15:35    [W:0.020 / U:184.040 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site