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@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Williamson
2008-Aug-25 01:10 UTC
Re: [Xen-devel] Identifying pagetype in they hypervisor
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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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? 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@cl.cam.ac.uk> 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@lists.xensource.com >> http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Williamson
2008-Aug-25 16:12 UTC
Re: [Xen-devel] Identifying pagetype in they hypervisor
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@cl.cam.ac.uk> 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@lists.xensource.com > >> http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@cl.cam.ac.uk> 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@cl.cam.ac.uk> 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@lists.xensource.com
>> >> http://lists.xensource.com/xen-devel
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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@gatech.edu> 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@cl.cam.ac.uk> 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@cl.cam.ac.uk> 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@lists.xensource.com >>> >> http://lists.xensource.com/xen-devel >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Williamson
2008-Aug-26 00:08 UTC
Re: [Xen-devel] Identifying pagetype in they hypervisor
Ouch, that makes my head hurt! :-) Glad you found that as I really haven''t worked with the shadow code before. I hope it helps solve your problem, otherwise please do come post on xen-devel some more! Cheers, Mark On Monday 25 August 2008 17:39:14 Mike Sun wrote:> 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@gatech.edu> 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@cl.cam.ac.uk> 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@cl.cam.ac.uk> 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@lists.xensource.com > >>> >> http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 22:01 -0400 on 24 Aug (1219615265), Mike Sun wrote:> 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?In the shadow code (unless someone''s been making careless changes) everything that''s a *mfn is a real machine frame number, suitable for use in pagetable entries, CR3, &c. That''s what an mfn_t is supposed to hold. Any *gfn (in a gfn_t, where available) is the _guest''s_ idea of frame numbers, specifically that means what the guest puts in _his_ pagetables and CR3. That''s not the same as the "guest physical" address space -- the shadow pagetable code doesn''t care about the guest''s internal abstractions, just about pagetables. (For HVM guests, gfns do contain these guest-physical numbers, but for shadowed PV guests they contain machine-physical numbers. Confused yet?) There''s a big block-comment about it that used to be in one of the shadow header files but I think maybe the NPT or EPT patches moved it somewhere else when they moved the mfn_t definition. The comment in the log-dirty code predates shadow-2 and the mfn_t/gfn_t concepts, and is intended to say that regardless of what kind of guest we''re looking at, the log-dirty bitmap is kept in guest-physical numbers, to keep it dense. Cheers, Tim.> 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@cl.cam.ac.uk> 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@lists.xensource.com > >> http://lists.xensource.com/xen-devel > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel