[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: HYBRID: gnttab_map() to map shared frames..



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.