From patchwork Wed Feb 24 12:49:49 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Beulich X-Patchwork-Id: 8405901 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id A06159F1D4 for ; Wed, 24 Feb 2016 12:52:46 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D7CE6202EB for ; Wed, 24 Feb 2016 12:52:45 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EC08B202E9 for ; Wed, 24 Feb 2016 12:52:44 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aYYt9-0007ZN-6O; Wed, 24 Feb 2016 12:49:55 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aYYt7-0007ZI-2h for xen-devel@lists.xen.org; Wed, 24 Feb 2016 12:49:53 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 4E/FB-04060-0F6ADC65; Wed, 24 Feb 2016 12:49:52 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1456318190!24143074!1 X-Originating-IP: [137.65.248.74] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 63980 invoked from network); 24 Feb 2016 12:49:51 -0000 Received: from prv-mh.provo.novell.com (HELO prv-mh.provo.novell.com) (137.65.248.74) by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 24 Feb 2016 12:49:51 -0000 Received: from INET-PRV-MTA by prv-mh.provo.novell.com with Novell_GroupWise; Wed, 24 Feb 2016 05:49:49 -0700 Message-Id: <56CDB4FD02000078000D5A34@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.2.0 Date: Wed, 24 Feb 2016 05:49:49 -0700 From: "Jan Beulich" To: "George Dunlap" , "Feng Wu" References: <1456216452-3745-1-git-send-email-feng.wu@intel.com> <1456216452-3745-2-git-send-email-feng.wu@intel.com> <56CC980E02000078000D551B@prv-mh.provo.novell.com> <56CD1D19.1020505@cardoe.com> <56CD9D66.7080402@citrix.com> In-Reply-To: <56CD9D66.7080402@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Kevin Tian , Keir Fraser , GeorgeDunlap , Andrew Cooper , Dario Faggioli , Doug Goldstein , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v13 1/2] vmx: VT-d posted-interrupt core logic handling X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP >>> On 24.02.16 at 13:09, wrote: > Another reason for such a comment is that it actually raises awareness > that the hook isn't properly structured: if you get such a compile > error, then it's either not defined in the right place, or it's not > using the right calling convention. Well, why I generally agree with you here, I'm afraid there are many pre-existing instances in our headers. Cleaning that up is likely going to be a major work item. > It also makes me realize that this code will no longer build on ARM, > since arch_do_block() is only defined in asm-x86 (and not asm-arm). The patch has (and for the avoidance of doubt there's no arch_do_block() afaics). > It seems like to do the callback properly, we should do something like > the attached. Jan, what do you think? Well, as per above that would address the particular issue here without addressing the many other existing ones, and it would cause out of line functions _plus_ another indirect call when the idea is to have such hooks inlined as far as possible. But you indeed point out one important problem - the hook as it is right now lacks a has_hvm_container_vcpu(), and hence would break for PV guests. Jan --- a/xen/include/asm-arm/domain.h +++ b/xen/include/asm-arm/domain.h @@ -310,6 +310,8 @@ static inline void free_vcpu_guest_context(struct vcpu_guest_context *vgc) xfree(vgc); } +static inline void arch_vcpu_block(struct vcpu *v) {} + #endif /* __ASM_DOMAIN_H__ */ /*