From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: Re: how to handle paged hypercall args? Date: Fri, 3 Dec 2010 10:14:30 +0100 Message-ID: <20101203091430.GC6055@aepfle.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline 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: Keir Fraser Cc: xen-devel@lists.xensource.com, Jan Beulich List-Id: xen-devel@lists.xenproject.org On Thu, Dec 02, Keir Fraser wrote: > On 02/12/2010 10:22, "Keir Fraser" wrote: > > > Firstly, the usage of waitqueues is broken. The waitqueue_head should be > > shared with code that pages in, so that vcpus can be *woken* at some point > > after they start waiting. As it is, if a vcpu does sleep on its local > > waitqueue_head, it will never wake. You might start with a single global > > waitqueue_head and wake everyone on it every time a page (or maybe page > > batch) is paged in. More sophisticated might be to hash page numbers into a > > array of waitqueue_heads, to reduce false wakeups. > > ...Or you might have a per-domain waitqueue_head, and do the wake_up() from > code that adds paged-in entries to the guest physmap. That would seem a > pretty sensible way to proceed, to me. Thats what I'm doing right now. It seems that the existing MEM_EVENT_FLAG_VCPU_PAUSED code can be reused for this. I was messing with wait_event() until I realized that the vcpu is stopped by p2m_mem_paging_populate() already and the wake_up() ran before the vcpu got a chance to call schedule(). If a vcpu happens to be scheduled and the domain is destroyed, the BUG_ON in destroy_waitqueue_vcpu() will trigger. What can happen if there is still an entry in the list? The cleanup should handle this situation to not crash Xen itself. Olaf