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/
Home Products Support Community News


Re: [Xen-devel] Identifying pagetype in they hypervisor

To: "Mark Williamson" <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Identifying pagetype in they hypervisor
From: "Mike Sun" <msun@xxxxxxxxxx>
Date: Mon, 25 Aug 2008 12:39:14 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 25 Aug 2008 09:39:39 -0700
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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=HxzcLaCqkHmPNkLTOEX5hLAXOCkIg0imMm6imvrWGjM=; b=vzNtT/Mm/nL0AmahFIki0UqCWOfqAPMKObSAJ5gu0ktV6J8rpu4ogdLFioD5abzWuO c+eKvOFSt+70UDFN1B7dZM3mXZn36CVCPK3yqyISgEhKdJtJaGqkTJdKBSmSC1TxKzr/ keKVWDX7WlnJ3RRtxJc1NZQgsLgDPq2sqRYvc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=YpxG+/xnGCgMLwLIt+Qu5Iweb8m5phPL4f/H+RE7csE85FPXxYbq2ORmBEoRmu91rk pu4S3teeh/ydPKzaupSgtJE4YDW/9LfHKYoBjE5f+M5f9KTYaMypiH4YLod6atgs0HaP nt7G9UThunDlLirJz1dXRWRzaf2vTLbQ1xPVI=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <e4e579070808250924g3ddb4a09y60fe74e1164de074@xxxxxxxxxxxxxx>
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>
References: <e4e579070808241747u2e699972o2e1f35cc96a950e4@xxxxxxxxxxxxxx> <200808250210.43466.mark.williamson@xxxxxxxxxxxx> <e4e579070808241901l5382587bt4034c4f27ebd203@xxxxxxxxxxxxxx> <200808251712.26132.mark.williamson@xxxxxxxxxxxx> <e4e579070808250924g3ddb4a09y60fe74e1164de074@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hmm... maybe this is the answer to my question... found in xen/include/asm/mm.h

 * With shadow pagetables, the different kinds of address start
 * to get get confusing.
 * Elsewhere in the xen code base, the name "gmfn" is generally used to refer
 * to a "machine frame number, from the guest's perspective", or in other
 * words, pseudo-physical frame numbers.  However, in the shadow code, the
 * term "gmfn" means "the mfn of a guest page"; this combines naturally with
 * other terms such as "smfn" (the mfn of a shadow page), gl2mfn (the mfn of a
 * guest L2 page), etc...

On Mon, Aug 25, 2008 at 12:24 PM, Mike Sun <msun@xxxxxxxxxx> wrote:
> Hi Mark,
> Those were the naming conventions that I was working with...  but the
> confusion in the shadow comes about because it seems like that in
> certain portions of the code, i.e., sh_mark_dirty(), are passed an
> actual mfn, but the code names it as a gmfn, which in the case of an
> HVM domain that uses auto-translated shadows, they should not be the
> same (the gmfn would denote a pseudo-physical address).
> In sh_mark_dirty(struct domain *d, mfn_t gmfn), I'm lead to believe
> the gmfn argument actually represents an mfn even in the HVM case
> because partway through the function, this occurs:
>  /* We /really/ mean PFN here, even for non-translated guests. */
>    pfn = get_gpfn_from_mfn(mfn_x(gmfn));
> If in HVM, gmfn == gpfn, then this pfn in this function should ==
> gmfn, but in my debugging output, it does not.  It makes me think that
> gmfn is a real mfn.  (I also looked at the get_gpfn_from_mfn()
> function and it looks like it's just doing an M2P table lookup).
> Have any ideas?  Thanks,
> Mike
> On Mon, Aug 25, 2008 at 12:12 PM, Mark Williamson
> <mark.williamson@xxxxxxxxxxxx> wrote:
>> Hi Mike,
>> On Monday 25 August 2008 03:01:05 Mike Sun wrote:
>>> Thanks Mark.  That's what I think I'm looking for.
>>> I think I've managed to confuse myself a bit again (haven't touched
>>> the modifications I made to the shadow code in a while) with the
>>> gmfn/mfn naming in the shadow code.  In _sh_propagate(...,
>>> target_fmn,..) and _sh_mark_dirty(..., gmfn), I'm assuming that a real
>>> machine frame number is passed to those functions, not a
>>> pseudo-physical one... am I correct?
>> The shadow code isn't something I'm familiar with, except conceptually.  My
>> understanding of the naming was that:
>> mfn = real machine frame number
>> gmfn = machine frame number as seen by the guest
>> gpfn = pseudo-physical frame number as seen by the guest
>> For HVM, we have gmfn == gpfn
>> and mfn is translated to gmfn by shadow-related code
>> For PV (assuming we're not doing shadow_translate) we have mfn == gmfn
>> and gpfn is translated to gmfn == mfn by the guest itself
>> Does that help at all?
>> Cheers,
>> Mark
>>> Basically, I need to be sure that when the sh_page_fault_handler()
>>> eventually calls _sh_propagate(), it passes the machine frame number
>>> of the faulting page, not the HVM guest's perceived physical address
>>> (gmfn/pseudo-physical).
>>> Thanks,
>>> Mike
>>> On Sun, Aug 24, 2008 at 9:10 PM, Mark Williamson
>>> <mark.williamson@xxxxxxxxxxxx> wrote:
>>> > I'm looking at the latest code but I would think the same code applies.
>>> >
>>> > Maybe you could try mfn_to_page() to get the struct page_info * and then
>>> > poke about in that for the current type?  In order to make this useful
>>> > you'd probably have to do a get_page or similar to avoid races with other
>>> > CPUs.
>>> >
>>> > Cheers,
>>> > Mark
>>> >
>>> > On Monday 25 August 2008 01:47:19 Mike Sun wrote:
>>> >> Hi --
>>> >>
>>> >> I'm working off of a bit older branch, 3.1.0, but hopefully the
>>> >> question is still relevant.
>>> >>
>>> >> In the suspend/restore code in 'tools/libxc/xc_domain_save.c', as part
>>> >> of the saved record, a list of pfn_types are saved prior to the actual
>>> >> pages themselves.  These pfn_types are pfns with a type bits
>>> >> associated with them that are accessed with the XEN_DOMCTL_PFINFO_XTAB
>>> >> bitmask.
>>> >>
>>> >> I'm doing some copy-on-write work, and when I intercept writes in the
>>> >> hypervisor, I need to copy both the actual page, and the type
>>> >> associated with the page (so that it could later be properly written
>>> >> out to the save record).  I've modified the shadow page table code to
>>> >> handle write faults associated with CoW and am able to get the mfn of
>>> >> the faulting page and perform the copy; I cannot seem to find where
>>> >> given the mfn, I can find the page type associated with it.  Could
>>> >> anybody help point me to the right place or direction?
>>> >>
>>> >> Much thanks,
>>> >> Mike
>>> >>
>>> >> _______________________________________________
>>> >> Xen-devel mailing list
>>> >> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> >> http://lists.xensource.com/xen-devel

Xen-devel mailing list