Re: [Xen-devel] pvh dom0: memory leak from iomem map

[Tim Deegan <tim@xxxxxxx>]

At 19:12 -0700 on 05 Jun (1401991969), Mukesh Rathor wrote:
> On Thu, 5 Jun 2014 11:20:32 +0200
> Tim Deegan <tim@xxxxxxx> wrote:
> 
> > At 18:29 -0700 on 03 Jun (1401816588), Mukesh Rathor wrote:
> > > Hi Tim,
> > > 
> > > When building a dom0 pvh, we populate the p2m with 0..N pfns
> > > upfront. Then in pvh_map_all_iomem, we walk the e820 and map all
> > > iomem 1:1. As such any iomem range below N would cause those ram
> > > frames to be silently dropped. Since the holes could be pretty big,
> > > I am concenred this could result in significant loss of frames. 
> > 
> > Right.  So, er, don't do that then? :)  You have all the information
> > you need available at the time that you build dom0's p2m, so why not
> 
> 
> I thought about that, and wasn't sure how easy it would be to change
> construct_dom0 for that purpose. It's common for both PV and PVH, and is 
> pretty
> messy as is. Anyways, Roger has already done the work of reusing the frames 
> via snooping into M2P, and repopulating those frames that got invalidated
> when mapping iomem 1:1. 
> 
> We don't have any case where a frame is used for some special purpose and 
> does not have a mapping in the M2P, right? Otherwise, his code would be 
> broken....

Not that I know of.  But I can't believe that any path that builds a
p2m, punches holes in it, and then uses the _m2p_ to figure out where
the memory went could be the easy option. 

If doing it right the first time is too fiddly, we do have code that
moves a frame from one gfn to another (for the xatp call) -- perhaps
you could do that when you want to make a hole for mmio?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel