[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Identifying pagetype in they hypervisor
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@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 -- Tim Deegan <Tim.Deegan@xxxxxxxxxx> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |