From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Design question for PV superpage support Date: Tue, 03 Mar 2009 09:26:16 -0800 Message-ID: <49AD6838.802@goop.org> References: <200903020754.23534.dcm@mccr.org> <200903021200.09999.dcm@mccr.org> <49AC220E.9030000@Sun.COM> <200903021314.34075.dcm@mccr.org> <49AC89D6.7020701@goop.org> <49ACAB3A.2030703@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49ACAB3A.2030703@Sun.COM> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mick.Jordan@sun.com Cc: Dave McCracken , Xen Developers List List-Id: xen-devel@lists.xenproject.org Mick Jordan wrote: > Since restore already requires quite a lot of reset, e.g., grant table > mappings, on the part of the guest, it seems that checking the > validity of any large page mappings should be possible at the same > time. Obviously you could get in a big mess if you mapped the code > that is going to do the fixup on a large page, but that is unlikely > and easily avoidable. That's actually the most likely case in Linux. Not being able to use 2M mappings for kernel code+data removes about 95% of the utility. > In general, I think the guest should assume that large page mappings > are merely an optimization that (a) might not be possible on domain > start due to machine memory fragmentation and (b) that this condition > might also occur on restore. Given these, it must always be prepared > to function with 4K pages, which implies that it would need to > preserve enough page table frame memory to be able revert from large > to small pages. I think that too intrusive. I'd want to see some very convincing measurements to justify doing these kinds of changes to pvops Linux, for example. J