From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755362AbZKBPTU (ORCPT ); Mon, 2 Nov 2009 10:19:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755257AbZKBPTT (ORCPT ); Mon, 2 Nov 2009 10:19:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17887 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755161AbZKBPTS (ORCPT ); Mon, 2 Nov 2009 10:19:18 -0500 Message-ID: <4AEEF878.2090805@redhat.com> Date: Mon, 02 Nov 2009 17:19:20 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Gleb Natapov CC: kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 08/11] Add "wait for page" hypercall. References: <1257076590-29559-1-git-send-email-gleb@redhat.com> <1257076590-29559-9-git-send-email-gleb@redhat.com> <4AEED907.5030306@redhat.com> <20091102151320.GC27911@redhat.com> In-Reply-To: <20091102151320.GC27911@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/02/2009 05:13 PM, Gleb Natapov wrote: > On Mon, Nov 02, 2009 at 03:05:11PM +0200, Avi Kivity wrote: > >> On 11/01/2009 01:56 PM, Gleb Natapov wrote: >> >>> We want to be able to inject async pagefault into guest event if a guest >>> is not executing userspace code. But in this case guest may receive >>> async page fault in non-sleepable context. In this case it will be >>> able to make "wait for page" hypercall vcpu will be put to sleep until >>> page is swapped in and guest can continue without reschedule. >>> >> What's wrong with just 'hlt' and checking in the guest? >> >> > Halting here will leave vcpu with interrupt disabled and this will prevent > "wake up" signal delivery. Page faults can be delivered with interrupts disabled. > Enabling interrupts is also not an options > since we can't be sure that vcpu can process interrupt at this point. > That's too bad, allowing interrupts in this context can help maintain responsiveness. -- error compiling committee.c: too many arguments to function