[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Identifying pagetype in they hypervisor
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |