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@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
|
Home