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