[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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@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 |