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

["Mike Sun" <msun@xxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel