From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 1/3] x86/xen: allow for privcmd hypercalls to be preempted Date: Wed, 12 Feb 2014 10:10:44 +0000 Message-ID: <52FB48A4.9090205@citrix.com> References: <1392146352-16381-1-git-send-email-david.vrabel@citrix.com> <1392146352-16381-2-git-send-email-david.vrabel@citrix.com> <1392197930.13563.7.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1392197930.13563.7.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Boris Ostrovsky , Stefano Stabellini , David Vrabel , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 12/02/14 09:38, Ian Campbell wrote: > On Tue, 2014-02-11 at 19:19 +0000, David Vrabel wrote: >> Implement is_premptible_hypercall() by adding a second hypercall page >> (preemptible_hypercall_page, copied from hypercall_page). Calls made >> via the new page may be preempted. > Wouldn't a per-cpu flag variable set for the duration of privcmd_call do > the job just as well without requiring per-arch knowledge? > > Ian. > Why should privcmd_call be the only preemptible calls? This code allows anyone to voluntarily use the preemptible_hypercall_page. I would not be surprised if modules like gntdev could do with some preemption, but it is the long-running toolstack hypercalls which are currently killing any loaded XenServer system. ~Andrew