From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: x86's context switch ordering of operations Date: Tue, 29 Apr 2008 10:03:40 -0700 Message-ID: <481754EC.9030109@goop.org> References: <48173326.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <48173326.76E4.0078.0@novell.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: Jan Beulich Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Jan Beulich wrote: > 1) How does the storing of vcpu_info_mfn in the hypervisor survive > migration or save/restore? The mainline Linux code, which uses this > hypercall, doesn't appear to make any attempt to revert to using the > default location during suspend or to re-setup the alternate location > during resume (but of course I'm not sure that guest is save/restore/ > migrate ready in the first place). I would imagine it to be at least > difficult for the guest to manage its state post resume without the > hypervisor having restored the previously established alternative > placement. > The only kernel which uses it is 32-on-32 pvops, and that doesn't currently support migration. It would be easy for the guest to restore that state for itself shortly after resuming. I still need to add 32-on-64 and 64-on-64 implementations for this. Just haven't looked at it yet. > 2) The implementation in the hypervisor seems to have added yet another > scalibility issue (on 32-bits), as this is being carried out using > map_domain_page_global() - if there are sufficiently many guests with > sufficiently many vCPU-s, there just won't be any space left at some > point. This worries me especially in the context of seeing a call to > sh_map_domain_page_global() that is followed by a BUG_ON() checking > whether the call failed. > Yes, we discussed it, and, erm, don't do that. Guests should be able to deal with VCPUOP_register_vcpu_info failing, but that doesn't address overall heap starvation. J