Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp4060728ybz; Mon, 20 Apr 2020 14:57:23 -0700 (PDT) X-Google-Smtp-Source: APiQypJOFUIxq45ntmqDsJTMzY9CdYOo/dcFVB3sK62spRaE0AHjPMy2Uc6QSvdNEiBLWGknwHgm X-Received: by 2002:a17:906:eb90:: with SMTP id mh16mr18391862ejb.201.1587419843637; Mon, 20 Apr 2020 14:57:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587419843; cv=none; d=google.com; s=arc-20160816; b=XGUEl+PAkZHoa/bRPyS5ed/+++IbCEtel0uwFMArgpYiQ6hMnf4u5M0hN7LT+p0Hf2 CVsG56ytJWm2EeBpltLaI6n9VTNO/PU807Kut4imC7kEoTl1hHzoLTcFV86PcuOJq7j8 jhFCUrZwaMZQLJAtRvozvFwjr1i+3VKkvLQmJrlO3P4Vd/j++ADka0+Mt7VUkDKGk5ON 78WsCFsGhToIwn1lxGPitpaG3ryW++BlC71OPrmGXABsH7Wld9noIoVrzumRV7+1ntCw IzA/Bn67NE+i+Pn93cd9fDhv6tt+6/CdUPLUx2G/TspII9f/G6R47QFMu/3wI84oiC6L uv4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=e+ELqLq3gPCYEnJS7eOFyYeeckxZ35QYITd49QV5sTk=; b=UvnKEKpXkQlv4T+Yjf47VzTl0BfGnhaal9ZfxvAgrbpxugOFGmkVwBZxpU2ND5Dt8t iTb6uZo/ukWrpR4WSzE9Fk8O/N9UqQ2yD4U+/rBHi+CRZNwKbzG8a/kp3BhitgvKlrA7 oTVIEVNeto18wcgeL76sQjw65buby7F5Bdmp5VxCJydi2vnFBxrh2C/Z9xaULDbuIXRK JqG9VMS26tVTh1AeCOx/4zAJJUIMRIPrDXPNlAo1fCaphg64NjENUIcrC3OD57wbzQFT SMsnk7kHMuitxXtpGHnZl9ab43jndFjq+CmkIZVqztKR/vLEVrl4ts+AO7jFT1jiKA9o owrA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f3si298775ejb.192.2020.04.20.14.56.58; Mon, 20 Apr 2020 14:57:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726809AbgDTVxp (ORCPT + 99 others); Mon, 20 Apr 2020 17:53:45 -0400 Received: from mx2.suse.de ([195.135.220.15]:36894 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725989AbgDTVxp (ORCPT ); Mon, 20 Apr 2020 17:53:45 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0EE2CAE47; Mon, 20 Apr 2020 21:53:41 +0000 (UTC) Date: Mon, 20 Apr 2020 14:50:14 -0700 From: Davidlohr Bueso To: Paolo Bonzini Cc: Marc Zyngier , tglx@linutronix.de, kvm@vger.kernel.org, Davidlohr Bueso , peterz@infradead.org, torvalds@linux-foundation.org, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, rostedt@goodmis.org, linux-mips@vger.kernel.org, Paul Mackerras , joel@joelfernandes.org, will@kernel.org, kvmarm@lists.cs.columbia.edu Subject: Re: [PATCH v2] kvm: Replace vcpu->swait with rcuwait Message-ID: <20200420215014.sarodevmhphnkkn7@linux-p48b> References: <20200324044453.15733-1-dave@stgolabs.net> <20200324044453.15733-4-dave@stgolabs.net> <20200420164132.tjzk5ebx35m66yce@linux-p48b> <418acdb5001a9ae836095b7187338085@misterjones.org> <20200420205641.6sgsllj6pmsnwrvp@linux-p48b> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 20 Apr 2020, Paolo Bonzini wrote: >On 20/04/20 22:56, Davidlohr Bueso wrote: >> On Mon, 20 Apr 2020, Marc Zyngier wrote: >> >>> This looks like a change in the semantics of the tracepoint. Before this >>> change, 'waited' would have been true if the vcpu waited at all. Here, >>> you'd >>> have false if it has been interrupted by a signal, even if the vcpu >>> has waited >>> for a period of time. >> >> Hmm but sleeps are now uninterruptible as we're using TASK_IDLE. > >Hold on, does that mean that you can't anymore send a signal in order to >kick a thread out of KVM_RUN? Or am I just misunderstanding? Considering that the return value of the interruptible wait is not checked, I would not think this breaks KVM_RUN. Thanks, Davidlohr