From patchwork Mon Mar 24 16:41:12 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefano Stabellini X-Patchwork-Id: 26937 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-pd0-f198.google.com (mail-pd0-f198.google.com [209.85.192.198]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 2E3C220143 for ; Mon, 24 Mar 2014 16:43:51 +0000 (UTC) Received: by mail-pd0-f198.google.com with SMTP id fp1sf14352893pdb.9 for ; Mon, 24 Mar 2014 09:43:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:date:from:to:in-reply-to:message-id :references:user-agent:mime-version:cc:subject:precedence:list-id :list-unsubscribe:list-post:list-help:list-subscribe:sender :errors-to:x-original-sender:x-original-authentication-results :mailing-list:list-archive:content-type:content-transfer-encoding; bh=JlCioz9BCgE29EddyTQEZBRjzEusyyCo8y49h1UD/ZA=; b=QTLUCd613GyrYntVxi/SX6CYxpO+0tgvF/eOENfhUge76qPmnG/tlVMRFR6DGJI4u8 jSPGWul8cbyy/lBxTFyzKhWbXbCaC/haZYxl7wOQWWOQhgcgLrbm1sTwQp+NME4YW71T yhZ+SIKepkuTaeenGr3tLEG6T8l8KgdOyaBsuipYNd233B9wKhBaFtp3MmPCcPB7Gyf0 Emnydk4fASJU+pnyGgBzBM7NQDz1sSyttc2N66oPjtss5BGqkz4o3zU9gO4PvDrTkIkl kxQ8jNEhOo7N4nilpBYUJ/4tY/mSsqASS1+2H3RieZZfZazCyMhRRcADPahZHStZjpFr Hg8g== X-Gm-Message-State: ALoCoQnKBUEcEm7VXQViEngGE65Szpz7VqAl53j+RqdZdcCQ3GoH1FkOsLFgx82b3Gza88qzLwwz X-Received: by 10.66.140.8 with SMTP id rc8mr26314202pab.41.1395679431158; Mon, 24 Mar 2014 09:43:51 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.83.85 with SMTP id i79ls1646760qgd.21.gmail; Mon, 24 Mar 2014 09:43:50 -0700 (PDT) X-Received: by 10.220.12.66 with SMTP id w2mr6049939vcw.15.1395679430923; Mon, 24 Mar 2014 09:43:50 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by mx.google.com with ESMTPS id i3si3104703vcp.52.2014.03.24.09.43.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Mar 2014 09:43:50 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.128.177 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.128.177; Received: by mail-ve0-f177.google.com with SMTP id sa20so5892645veb.8 for ; Mon, 24 Mar 2014 09:43:50 -0700 (PDT) X-Received: by 10.220.96.70 with SMTP id g6mr6215108vcn.19.1395679430792; Mon, 24 Mar 2014 09:43:50 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.220.78.9 with SMTP id i9csp237018vck; Mon, 24 Mar 2014 09:43:50 -0700 (PDT) X-Received: by 10.140.24.151 with SMTP id 23mr73741223qgr.11.1395679429643; Mon, 24 Mar 2014 09:43:49 -0700 (PDT) Received: from lists.xen.org (lists.xen.org. [50.57.142.19]) by mx.google.com with ESMTPS id lz5si6287392qcb.14.2014.03.24.09.43.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 24 Mar 2014 09:43:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of xen-devel-bounces@lists.xen.org designates 50.57.142.19 as permitted sender) client-ip=50.57.142.19; Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WS7wY-0008A6-Fv; Mon, 24 Mar 2014 16:41:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WS7wX-00089q-Gj for xen-devel@lists.xensource.com; Mon, 24 Mar 2014 16:41:45 +0000 Received: from [193.109.254.147:48030] by server-4.bemta-14.messagelabs.com id 6D/3A-02781-84060335; Mon, 24 Mar 2014 16:41:44 +0000 X-Env-Sender: Stefano.Stabellini@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1395679302!3799482!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9307 invoked from network); 24 Mar 2014 16:41:43 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 24 Mar 2014 16:41:43 -0000 X-IronPort-AV: E=Sophos;i="4.97,721,1389744000"; d="scan'208";a="114374860" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 24 Mar 2014 16:41:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Mon, 24 Mar 2014 12:41:41 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1WS7wT-0003GB-4t; Mon, 24 Mar 2014 16:41:41 +0000 Date: Mon, 24 Mar 2014 16:41:12 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1395665864.6294.24.camel@kazak.uk.xensource.com> Message-ID: References: <1395232325-19226-8-git-send-email-stefano.stabellini@eu.citrix.com> <1395408173.19839.65.camel@kazak.uk.xensource.com> <1395421482.25521.36.camel@kazak.uk.xensource.com> <1395665864.6294.24.camel@kazak.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-DLP: MIA2 Cc: julien.grall@citrix.com, jtd@galois.com, xen-devel@lists.xensource.com, Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v4 08/10] xen/arm: second irq injection while the first irq is still inflight X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Post: , List-Help: , List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: stefano.stabellini@eu.citrix.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.128.177 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Archive: On Mon, 24 Mar 2014, Ian Campbell wrote: > > > > > > We also need to force the first injection of evtchn_irq (call > > > > > > gic_vcpu_inject_irq) from vgic_enable_irqs because evtchn_upcall_pending > > > > > > is already set by common code on vcpu creation. > > > > > > > > > > This is because the common code expects that the guest is moving from > > > > > sharedinfo based vcpu info using VCPUOP_register_vcpu_info on x86, but > > > > > on ARM we start off that way anyway. > > > > > > > > > > I suppose it's a minor wrinkle, but I wonder if we can get rid of it... > > > > > > > > Do you mean getting rid of evtchn_upcall_pending being set at vcpu > > > > creation? Wouldn't that cause possible undesirable side effects to > > > > guests that came to rely on it somehow? It would be an ABI change. > > > > > > I mean precisely for the boot cpu when it is brought online, there isn't > > > much sense in immediately taking an interrupt when that cpu enables > > > them. > > > > > > The reason for setting it right now is only for the case of a cpu moving > > > its vcpu info, to ensure it can't miss anything. > > > > What about secondary vcpus? Should we keep the spurious injection for > > them? > > Not sure. No? > > > In any case I agree with you that the current behaviour is not nice, > > however I am worried about changing a guest visible interface like this > > one, that would affect x86 guests too. > > Oh, I certainly wouldn't change this for x86! Or maybe I would change it > but only for cpus which are not online at the time when the init happens > (which is effectively the difference between the x86 and arm cases) Today on ARM and x86 PV on HVM VCPUOP_register_vcpu_info is called by each vcpu independently when is coming online, so secondary cpus would be already online at the time of the hypercall. On x86 PV VCPUOP_register_vcpu_info is called in a loop by vcpu0 for all the possible vcpus before smp bringup. Either way I don't think we can easily change this behaviour without affecting x86 guests. Alternatively of course this (ugly) change in Xen would work: diff --git a/xen/common/domain.c b/xen/common/domain.c index ad8a1b6..bd81f43 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -893,7 +893,9 @@ int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset) void *mapping; vcpu_info_t *new_info; struct page_info *page; +#ifdef CONFIG_X86 int i; +#endif if ( offset > (PAGE_SIZE - sizeof(vcpu_info_t)) ) return -EINVAL; @@ -942,6 +944,7 @@ int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset) /* Set new vcpu_info pointer /before/ setting pending flags. */ smp_wmb(); +#ifdef CONFIG_X86 /* * Mark everything as being pending just to make sure nothing gets * lost. The domain will get a spurious event, but it can cope. @@ -949,7 +952,7 @@ int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset) vcpu_info(v, evtchn_upcall_pending) = 1; for ( i = 0; i < BITS_PER_EVTCHN_WORD(d); i++ ) set_bit(i, &vcpu_info(v, evtchn_pending_sel)); - +#endif return 0; }