From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8424AC433DF for ; Thu, 30 Jul 2020 11:17:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5509C2083E for ; Thu, 30 Jul 2020 11:17:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="IK3yXUqo" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726794AbgG3LR5 (ORCPT ); Thu, 30 Jul 2020 07:17:57 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:54222 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726367AbgG3LR5 (ORCPT ); Thu, 30 Jul 2020 07:17:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596107876; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pWmDyEUJNIWGFgAmxoCDd0Zsu8Ym8vYf2vNm/NuhUkQ=; b=IK3yXUqoHTkK2q+IoQylV5Si+YqbDXgASrfmoeq1M/x//xDxM6CN2XaRbubGPdQrfsrsgG yyI0tpy2zKf155IO1vC3AOZBuxrSduNv+dX7bWuzGEU/8X17mRYU9bdBTcUlRz16sxhbX0 SmSvG1R/pnfnSooll+hIbTqI5xMs504= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-99-iJezKbNFOuCUc0AwNLjD2A-1; Thu, 30 Jul 2020 07:17:52 -0400 X-MC-Unique: iJezKbNFOuCUc0AwNLjD2A-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0766E102C7E9; Thu, 30 Jul 2020 11:17:51 +0000 (UTC) Received: from gondolin (ovpn-112-203.ams2.redhat.com [10.36.112.203]) by smtp.corp.redhat.com (Postfix) with ESMTP id 956361001B2C; Thu, 30 Jul 2020 11:17:46 +0000 (UTC) Date: Thu, 30 Jul 2020 13:16:17 +0200 From: Cornelia Huck To: Janosch Frank Cc: kvm@vger.kernel.org, thuth@redhat.com, linux-s390@vger.kernel.org, david@redhat.com, borntraeger@de.ibm.com, imbrenda@linux.ibm.com Subject: Re: [kvm-unit-tests PATCH v2 3/3] s390x: Ultravisor guest API test Message-ID: <20200730131617.7f7d5e5f.cohuck@redhat.com> In-Reply-To: <20200727095415.494318-4-frankja@linux.ibm.com> References: <20200727095415.494318-1-frankja@linux.ibm.com> <20200727095415.494318-4-frankja@linux.ibm.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, 27 Jul 2020 05:54:15 -0400 Janosch Frank wrote: > Test the error conditions of guest 2 Ultravisor calls, namely: > * Query Ultravisor information > * Set shared access > * Remove shared access > > Signed-off-by: Janosch Frank > Reviewed-by: Claudio Imbrenda > --- > lib/s390x/asm/uv.h | 68 +++++++++++++++++++ > s390x/Makefile | 1 + > s390x/unittests.cfg | 3 + > s390x/uv-guest.c | 159 ++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 231 insertions(+) > create mode 100644 lib/s390x/asm/uv.h > create mode 100644 s390x/uv-guest.c > (...) > +static inline int uv_call(unsigned long r1, unsigned long r2) > +{ > + int cc; > + > + asm volatile( > + "0: .insn rrf,0xB9A40000,%[r1],%[r2],0,0\n" > + " brc 3,0b\n" > + " ipm %[cc]\n" > + " srl %[cc],28\n" > + : [cc] "=d" (cc) > + : [r1] "a" (r1), [r2] "a" (r2) > + : "memory", "cc"); > + return cc; > +} This returns the condition code, but no caller seems to check it (instead, they look at header.rc, which is presumably only set if the instruction executed successfully in some way?) Looking at the kernel, it retries for cc > 1 (presumably busy conditions), and cc != 0 seems to be considered a failure. Do we want to look at the cc here as well? (...)