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

Re: [Xen-devel] [PATCH RFC v2 1/4] x86/mm: Shadow and p2m changes for PV mem_access



At 18:50 +0000 on 03 Sep (1409766654), Aravindh Puthiyaparambil (aravindp) 
wrote:
> >> Is the page_list the only place that will tell me the range of pages that
> >> belong to a PV guest?
> >
> >Yes. No upper bound on the PFN space is being tracked.
> 
> OK, in that case the only thing I can think of is to set a max
> memory limit for PV domains that an access listener can attach to so
> that the hypercall preemption / continuation is not required. In
> addition we could add a kernel command line parameter that overrides
> this and document that this could cause denial of service issues
> when used.

I suspect that such a limit would be too small to to be practical,
and so in effect would be the same as saying 'this feature may cause
your system to crash or misbehave' (which is obviously no good).

> Tim, can you think of any other options here?

It might be possible to make the walk restartable if we arrange that:
- all additions to the page list are at the tail;
- walks in progress are recorded (though I'm not sure where: it might
  be possible just to use a single bit in the page_info to say "this
  page is the cursor of an interrupted walk" and have a separate
  per-domain list of interrupted walks); and
- anything that removes a page from a domain's page_list must check
  that bit; if it finds it set it must update the per-walk state to
  point to the next page.

Jan, do you think that's viable?  I think it'll need a bit of thought
around the edge cases, and the semantics will need to be written down
carefully.

Tim.

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


 


Rackspace

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