Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp578481pxu; Fri, 11 Dec 2020 09:09:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJyJeJAmmNchkseWF5cbAJM0vkQ55RIkJZTVVcDwUEDPmcBRCU1pZwp6dciEPv4+8nidBh+H X-Received: by 2002:a05:6402:895:: with SMTP id e21mr12956104edy.284.1607706546367; Fri, 11 Dec 2020 09:09:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607706546; cv=none; d=google.com; s=arc-20160816; b=fDaL2p0pgR5Urs42ZqZQdN/mQWB954XbTtVLRQrDwZWxCovY70pYkgk86OUNakOy6G TIO2oXdOdA/8Ebz8IExSLMuEgwqzJkutV6RJZmMK4U1ICJgoDo5z2oP2UEyWDcw2U99J T8pwhY1iepNuQ9185jFWNsEnPzw/R2Kt7XrjZSnpd+Rtq8d6vdO2KDnB3kzU64nDMdYs fPRmsQQiONUOiCyI6YxhwYJEEht4OUOgKoVHTkl9XeT9k0fWArm/gYyEyzfgZyrcMWeb dEFWKOXRqx5O40YlWKtmJayReWtF8DcdoXDnuuiBCHVcenFZBixMFMvxJepBLvCLqCMV +wUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=RqIjgNGP8EpRseSxFoBnqE8y63I178BwzCy3MXCM4mw=; b=ImSLPfRC2lGz/cplznVU6hLdenuzkkvbFubswAq58c4asqMp//vyaBLekVSaEPjWH7 +ymqa9jCpMaMa6FXxvQlibHf3E2oQoLNy1/n4JbGTk9nFqGPqxaLZKm71UtOt7Ed4YgE VA/M6zC+8xZA+DJ/PEivQsa6dJ1XHtYM7CCcFZzEkGGrhyAgfoKkVQeJxNSVBQIMWe8M ZV3JVDXAc61K+huu5AwGn5YQHrym+R00j1iJiEAxRMTWMBwzaORtjVvpzbbUZ10uYfbe kE9W9E3HaYgQ8KJLR/b04jHUl1e38QRPls2NAroI2ep6HCXO6S1sz97X9ke/+PQvIqJt fEtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dGzEMqk0; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k5si4801337ejk.655.2020.12.11.09.08.42; Fri, 11 Dec 2020 09:09:06 -0800 (PST) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dGzEMqk0; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394408AbgLKLjQ (ORCPT + 99 others); Fri, 11 Dec 2020 06:39:16 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:23313 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391880AbgLKLjK (ORCPT ); Fri, 11 Dec 2020 06:39:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607686664; 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=RqIjgNGP8EpRseSxFoBnqE8y63I178BwzCy3MXCM4mw=; b=dGzEMqk0j9e/Z6L3lTiQxCZYMmZaaKmobd7quwyWEoyYFLA5NA0gMxKTtIQ/Nydbghp7/v bqY8qTonJPMGK7m+KoEQe5TX0j0tHonmuuNBSXTJp9GxMvHqw7EQK633tgnAMa30JrpPNr KD2W3OzA7oIMf/hGphGKQBcqcnCkHPs= 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-91-uYx1psuZPVahtzYjTJGM0w-1; Fri, 11 Dec 2020 06:37:40 -0500 X-MC-Unique: uYx1psuZPVahtzYjTJGM0w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 282FC190A7A4; Fri, 11 Dec 2020 11:37:38 +0000 (UTC) Received: from gondolin (ovpn-112-240.ams2.redhat.com [10.36.112.240]) by smtp.corp.redhat.com (Postfix) with ESMTP id 851305D705; Fri, 11 Dec 2020 11:37:32 +0000 (UTC) Date: Fri, 11 Dec 2020 12:37:29 +0100 From: Cornelia Huck To: Matthew Rosato Cc: alex.williamson@redhat.com, schnelle@linux.ibm.com, pmorel@linux.ibm.com, borntraeger@de.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com, gerald.schaefer@linux.ibm.com, linux-s390@vger.kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 1/4] s390/pci: track alignment/length strictness for zpci_dev Message-ID: <20201211123729.37647fa0.cohuck@redhat.com> In-Reply-To: <15132f7f-cad7-d663-a8b9-90f417e85c81@linux.ibm.com> References: <1607545670-1557-1-git-send-email-mjrosato@linux.ibm.com> <1607545670-1557-2-git-send-email-mjrosato@linux.ibm.com> <20201210113318.136636e2.cohuck@redhat.com> <15132f7f-cad7-d663-a8b9-90f417e85c81@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.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 10 Dec 2020 10:26:22 -0500 Matthew Rosato wrote: > On 12/10/20 5:33 AM, Cornelia Huck wrote: > > On Wed, 9 Dec 2020 15:27:47 -0500 > > Matthew Rosato wrote: > > > >> Some zpci device types (e.g., ISM) follow different rules for length > >> and alignment of pci instructions. Recognize this and keep track of > >> it in the zpci_dev. > >> > >> Signed-off-by: Matthew Rosato > >> Reviewed-by: Niklas Schnelle > >> Reviewed-by: Pierre Morel > >> --- > >> arch/s390/include/asm/pci.h | 3 ++- > >> arch/s390/include/asm/pci_clp.h | 4 +++- > >> arch/s390/pci/pci_clp.c | 1 + > >> 3 files changed, 6 insertions(+), 2 deletions(-) > >> > >> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h > >> index 2126289..f16ffba 100644 > >> --- a/arch/s390/include/asm/pci.h > >> +++ b/arch/s390/include/asm/pci.h > >> @@ -133,7 +133,8 @@ struct zpci_dev { > >> u8 has_hp_slot : 1; > >> u8 is_physfn : 1; > >> u8 util_str_avail : 1; > >> - u8 reserved : 4; > >> + u8 relaxed_align : 1; > >> + u8 reserved : 3; > >> unsigned int devfn; /* DEVFN part of the RID*/ > >> > >> struct mutex lock; > >> diff --git a/arch/s390/include/asm/pci_clp.h b/arch/s390/include/asm/pci_clp.h > >> index 1f4b666..9fb7cbf 100644 > >> --- a/arch/s390/include/asm/pci_clp.h > >> +++ b/arch/s390/include/asm/pci_clp.h > >> @@ -150,7 +150,9 @@ struct clp_rsp_query_pci_grp { > >> u16 : 4; > >> u16 noi : 12; /* number of interrupts */ > >> u8 version; > >> - u8 : 6; > >> + u8 : 4; > >> + u8 relaxed_align : 1; /* Relax length and alignment rules */ > >> + u8 : 1; > >> u8 frame : 1; > >> u8 refresh : 1; /* TLB refresh mode */ > >> u16 reserved2; > >> diff --git a/arch/s390/pci/pci_clp.c b/arch/s390/pci/pci_clp.c > >> index 153720d..630f8fc 100644 > >> --- a/arch/s390/pci/pci_clp.c > >> +++ b/arch/s390/pci/pci_clp.c > >> @@ -103,6 +103,7 @@ static void clp_store_query_pci_fngrp(struct zpci_dev *zdev, > >> zdev->max_msi = response->noi; > >> zdev->fmb_update = response->mui; > >> zdev->version = response->version; > >> + zdev->relaxed_align = response->relaxed_align; > >> > >> switch (response->version) { > >> case 1: > > > > Hm, what does that 'relaxed alignment' imply? Is that something that > > can apply to emulated devices as well? > > > The relaxed alignment simply loosens the rules on the PCISTB instruction > so that it doesn't have to be on particular boundaries / have a minimum > length restriction, these effectively allow ISM devices to use PCISTB > instead of PCISTG for just about everything. If you have a look at the > patch "s390x/pci: Handle devices that support relaxed alignment" from > the linked qemu set, you can get an idea of what the bit changes via the > way qemu has to be more permissive of what the guest provides for PCISTB. Ok, so it is basically a characteristic of a specific device that changes the rules of what pcistb will accept. > > Re: emulated devices... The S390 PCI I/O layer in the guest is always > issuing strict? aligned I/O for PCISTB, and if it decided to later > change that behavior it would need to look at this CLP bit to decide > whether that would be a valid operation for a given PCI function anyway. > This bit will remain off in the CLP response we give for emulated > devices, ensuring that should such a change occur in the guest s390 PCI > I/O layer, we'd just continue getting strictly-aligned PCISTB. My question was more whether that was a feature that might make sense to emulate on the hypervisor side for fully emulated devices. I'd like to leave the door open for emulated devices to advertise this and make it possible for guests using those devices to use pcistb with the relaxed rules, if it makes sense. I guess we can easily retrofit this if we come up with a use case for it.