WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Making pages writable again in paging_log_dirty mode

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Making pages writable again in paging_log_dirty mode
From: "Mike Sun" <msun@xxxxxxxxxx>
Date: Fri, 19 Dec 2008 15:54:50 -0500
Delivery-date: Fri, 19 Dec 2008 12:55:16 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=UpImvvFh52y+nMK1n/C8lQb0hl+chtHSr5gRgcbbs4I=; b=T5XL2FvQ3bVECPc2JtqRmBuhbRTOhVFQmw8Yo0zHJ2V4IAGLcJvkOJzq86r6lTvzx0 PUSkkyYNilERAegX4QxZnlt87G4DLZgYh3fiTrHgCnCQ8fZ5zRwcQWqdgiaYLYMUSses HDu3g9Hn5PgngnnV6/+dfECX5mOKYgD6WnxBc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=JzoV/U0Y0WuabbYDWA9T4NNaxK++rEwg6GZ8+KzABqcjfbWwxVd+RtQ5AUx5XLArqv Kx5s6tluGrcYfeAw3DSBQ/BZ5+7M+RD4x06hbsUtJ9CDUz1A03JlUPMN0xaskZm9ymjO 5dUtwh1UXyTAl6ZOvfB7doJRW2AAnBmTb+2rY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi,

I'm working off the 3.2.x codebase.

I've seen how "sh_page_fault()" uses "_sh_propagate()" to restore
writable access to pages after they have been dirtied.  I have a
situation in which I'd like to restore writable access to a set of
pages that haven't necessarily been dirtied yet, or have been dirtied,
but have not caused a page fault which would then make them writable
again.  I'm trying to use a hypercall invoked from dom0 that would
provide a list of pages to make writable again in log_dirty_mode.

Looking at the code which removes all writable mappings to a page from
an L2E, I tried to do something like this, where I walk the shadow
page tables for the log_dirty_domain and restore writable access to
certain pages.  Unfortunately, I get errors about page_type_count
overflows and other kinds of type errors.

    SHADOW_FOREACH_L2E(sl2mfn, sl2e, 0, done_l2, v->domain,
    {
        flags_l2 = shadow_l2e_get_flags(*sl2e);
        if ((flags_l2 & _PAGE_PRESENT) && (flags_l2 & _PAGE_USER))
        {
            sl1mfn = shadow_l2e_get_mfn(*sl2e);
            SHADOW_FOREACH_L1E(sl1mfn, sl1e, 0, done_l1,
            {
                flags_l1 = shadow_l1e_get_flags(*sl1e);
                if ((flags_l1 & _PAGE_PRESENT) &&
                    (flags_l1 & _PAGE_USER) &&
                    !(flags_l1 & _PAGE_RW))
                {
                    mfn = shadow_l1e_get_mfn(*sl1e);
                    if (mfn_valid(mfn))
                    {
                        struct page_info *page = mfn_to_page(mfn);
                        if ((page->u.inuse.type_info & PGT_type_mask)
                            == PGT_writable_page)
                        {
                            pfn = mfn_to_gfn(v->domain, mfn);
                            if (VALID_M2P(pfn) && my_check(pfn))
                            {
                                shadow_l1e_t rw_sl1e =
                                    shadow_l1e_add_flags(*sl1e, _PAGE_RW);
                                (void)
                                    shadow_set_l1e(v, sl1e, rw_sl1e, sl1mfn);
                            }
                        }
                    }
                }
            });
        }
    });

I dug a bit more to make sure I was increment/decrementing the ref
counts correctly and noticed this in the code of "get_page_type()":

else if ( unlikely((x & PGT_count_mask) == 0) )
        {
            struct domain *d = page_get_owner(page);

            /* Never allow a shadowed frame to go from type count 0 to 1 */
            if ( d && shadow_mode_enabled(d) )
                shadow_remove_all_shadows(d->vcpu[0], _mfn(page_to_mfn(page)));

I'm confused about this piece of code?  Do we have to destroy all
shadows mapping that mfn if the page type changes?

Thanks,
Mike

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>