On Wed, 19 Oct 2011 09:39:33 +0100
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Tue, 2011-10-18 at 20:17 +0100, Mukesh Rathor wrote:
> > On Tue, 18 Oct 2011 09:13:02 +0100
> > Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > ...
> > > Could GNTTABOP_setup_table return GFNs from the very top of the
> > > GFN space? Perhaps even above what would be architecturally valid,
> > > although perhaps that is incompatible with HAP. Anything above
> > > max_pfn would seem to be valid for the hypervisor to place "magic"
> > > mappings in?
> >
> > Well, what's confusing me for this is that there are few max
> > pfn's inside the guest! The nr_pages being one for example, then
> > there's max_pfn in shared_info.arch. I'm not sure if these two are
> > in sync with max_pfn in mm/bootmem.c. Then, we would need to adjust
> > EPT to add these pfns there. So that may put a damper on this.
>
> What about using PFNs from right at the top, i.e. right up near
> 0xffffffff? I don't think there's any particular reason these special
> PFNs need to be contiguous with the "regular" ones. This would limit
> the total amount of RAM you could give a hybrid guest, but not by
> much.
Yeah, I dinkered around a bit with e820 and realized it would be
migration headache, so just decided to do this. I allocate pfn's near
0xffffffff and map it. Things are fine, I see all page table entries
just fine, the entry is put into the p2m also via ept_set_entry, but
for some reason it's taking fault on accessing shared[0] with error
code 0xb that doesn't make sense. Even the mfn in xen is writable
page.
PGD 77895067 PUD 77896067 PMD 77897067 PTE 80000ffffffdf063
I'll continue debugging.
thanks,
Mukesh
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home