From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Fwd: Re: [RFC] XI Shadow Page Table Mechanism] Date: Thu, 22 Jun 2006 09:14:30 -0500 Message-ID: <449AA5C6.2050108@us.ibm.com> References: <449A9BD5.5030703@virtualiron.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Robert Phillips Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Robert Phillips wrote: > > This isn't supported currently? Since an HVM must go through 16 > bit, 32 > bit, and 64 bit mode to boot up, how can we start more than one > guest at > a time currently if this doesn't already work? > > > Ed Smith's daily test results show there have been problems with SMP. > We haven't diagnosed these problems but, from reading the pre-XI > shadow code, it's not clear how it copes with multiple VCPUs in the > same domain running in different modes. There's only a short period of time when this would be happening right? During boot up? > - how do you deal with large pages within the hypervisor? do you > coalesce or just hope there is contiguous pages available? > > > We just hope that contiguous pages are available. However we allocate > pages for the guest in large extents to maximize this likelihood. In > practice this is very effective for guests created soon after boot > time. There may be fragmentation problems later. Any ideas about how to deal with this long term? Large page support would also be useful for PV domains. There was a lot of people at the last summit that were interested in this... Thanks for the responses, Anthony Liguori > - what is the performance benefit in saving the shadow pages for each > domain? there's clearly a memory trade-off here so understanding the > performance gain seems important. > > > The performance benefit appears to be substantial but we have not done > a thorough study yet. > > - OOM can be dealt with in the existing code by just invalidating > existing mappings to free up pages. what advantages do your approach > have to this? (i realize we don't do this today but in theory, we > could). > > > Ultimately XI deals with OOM by tearing down cached shadow pages, > just as you say. But it uses LRU to pick the victims. > > Interesting stuff. I'm eager to see the code. > > Regards, > > Anthony Liguori > > > Thanks, > > -b > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > -- > ------------------------------------------------------------------------ > Ben Thomas Virtual Iron > Software > bthomas@virtualiron.com > Tower > 1, Floor 2 > 978-849-1214 900 Chelmsford > Street > Lowell, MA 01851 > > ------------------------------------------------------------------------ > Robert S. Phillips Virtual Iron Software > rsp.vi.xen@virtualiron.com > Tower 1, Floor 2 > 978-849-1220 900 Chelmsford Street > Lowell, MA 01851