Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3141730imm; Fri, 10 Aug 2018 04:36:29 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzhvhut1l5wyYBukOozcPjhV0VVjBjP99KTIrXOsRMCnsaGKLood7MqHqbvCyp67OctBgdf X-Received: by 2002:a63:65c2:: with SMTP id z185-v6mr6032559pgb.276.1533900989033; Fri, 10 Aug 2018 04:36:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533900988; cv=none; d=google.com; s=arc-20160816; b=OwLvN4LR2yYOgUcD9QjAu5s5Vmk0fJQJ5nAltSr6DhAJK5HyS4iNIgXigtOtzw44oO mfflYKtz2socq+iQiqtf78VV5irMqIW4q8wzEsSWLUrriyNWNDGxJdqxa1QGtE+EOXVs qYYXPPyX8kfxot99LvgyuGcQctO9ACz62zg7vHhJ+4TGPTCIp1TKR5GTcJ0V6OyCcwhn eXBar7FtttkJtzhn4o/0I7cRYHVw9n2mlN5LQmMlnA7SmHZMyJ34zpm+ovc+X8gv07/2 Fc/wrW0hR8Iy+Yle97vWXR+s2UuZzSQQegzf9/SN4goCakjvOBgQx9NMqMXcyw9Dhee3 6NRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=Ph3XF+stKBWEauuU2JkRoO8PEdNmlQ/LA0Lhl/6evss=; b=MlJFmy9kblq0RIKHM1/9ghKtFKyyrzihiRGz+ar3HhaPWDHE5s3YRRm4W2c6wDvHQ2 x+orCMcHt6Vtu0X4WaXMgE96lGNwoYw5G4O17dKPmADhmXxPLpFWsiGvK/s3USV93fdM 2fkjGwWT+5qDj4dp57ZO0Ml+MeZf4pIcLyO0Rah7YHm2FIpQVsyQYdCEJsaSvx+ev9dX MXqpwTbTGdVqeeng7q7OZBs/It4QmaNIw84BEc0qkaCXLJLqO5NIlcje1k0oy2qFx6Tp CZmikqwmH8QldRTSmEapCcsc5LZ6YZbPtvmmlo6/GPFn/WNngbD1lnUXH1CXEFRFAOlR b/uQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 11-v6si8714554plc.154.2018.08.10.04.36.14; Fri, 10 Aug 2018 04:36:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728004AbeHJNq0 (ORCPT + 99 others); Fri, 10 Aug 2018 09:46:26 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:34226 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727598AbeHJNq0 (ORCPT ); Fri, 10 Aug 2018 09:46:26 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DD1A272620; Fri, 10 Aug 2018 11:16:56 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3373E7C54; Fri, 10 Aug 2018 11:16:51 +0000 (UTC) Date: Fri, 10 Aug 2018 13:16:48 +0200 From: Cornelia Huck To: Pierre Morel Cc: Tony Krowiak , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, freude@de.ibm.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, borntraeger@de.ibm.com, kwankhede@nvidia.com, bjsdjshi@linux.vnet.ibm.com, pbonzini@redhat.com, alex.williamson@redhat.com, pmorel@linux.vnet.ibm.com, alifm@linux.vnet.ibm.com, mjrosato@linux.vnet.ibm.com, jjherne@linux.vnet.ibm.com, thuth@redhat.com, pasic@linux.vnet.ibm.com, berrange@redhat.com, fiuczy@linux.vnet.ibm.com, buendgen@de.ibm.com, frankja@linux.ibm.com, Tony Krowiak Subject: Re: [PATCH v8 17/22] s390: vfio-ap: zeroize the AP queues. Message-ID: <20180810131648.4fab1d7a.cohuck@redhat.com> In-Reply-To: References: <1533739472-7172-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1533739472-7172-18-git-send-email-akrowiak@linux.vnet.ibm.com> <20180810111445.015fcf2a.cohuck@redhat.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.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 10 Aug 2018 11:16:57 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Fri, 10 Aug 2018 11:16:57 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'cohuck@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 10 Aug 2018 12:49:08 +0200 Pierre Morel wrote: > On 10/08/2018 11:14, Cornelia Huck wrote: > > On Wed, 8 Aug 2018 10:44:27 -0400 > > Tony Krowiak wrote: > > > >> From: Tony Krowiak > >> > >> Let's call PAPQ(ZAPQ) to zeroize a queue: > >> > >> * For each queue configured for a mediated matrix device > >> when it is released. > >> > >> Zeroizing a queue resets the queue, clears all pending > >> messages for the queue entries and disables adapter interruptions > >> associated with the queue. > >> > >> Signed-off-by: Tony Krowiak > >> Reviewed-by: Halil Pasic > >> Tested-by: Michael Mueller > >> Tested-by: Farhan Ali > >> Signed-off-by: Christian Borntraeger > >> --- > >> drivers/s390/crypto/vfio_ap_ops.c | 29 ++++++++++++++++++++++++++++- > >> drivers/s390/crypto/vfio_ap_private.h | 25 +++++++++++++++++++++++++ > >> 2 files changed, 53 insertions(+), 1 deletions(-) > >> > >> @@ -788,7 +812,10 @@ static void vfio_ap_mdev_release(struct mdev_device *mdev) > >> { > >> struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev); > >> > >> - kvm_arch_crypto_clear_masks(matrix_mdev->kvm); > >> + if (matrix_mdev->kvm) > >> + kvm_arch_crypto_clear_masks(matrix_mdev->kvm); > > Confused. Why is the check for matrix_mdev->kvm added here? > > When using the KVM notifier we can get two notifications: > -> KVM is here / is comming > -> KVM is not here / disappearing > > In the first case we initialize matrix_mdev->kvm with a pointer to KVM > In the second case we nullify the pointer. > > During the open of the mediated device, the guest should have been started > or we refuse to start. > > During the close of the mediated device, the guest should be there, but > we have no certitude that the guest did not disappear before the VFIO > file being closed. > Since we do not allow multiple guests using the same mediated device > this case should not happen with QEMU. But I am not sure that > a rogue user program could not stop KVM before closing the VFIO > mediated device. I'm not sure why the check is introduced in this patch, though. But maybe I just need weekend :) > > Maybe Alex can confirm this point, if not we can remove the test.