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