From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVdqE-00079l-5h for qemu-devel@nongnu.org; Thu, 13 Jul 2017 09:07:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVdqB-0005yp-H3 for qemu-devel@nongnu.org; Thu, 13 Jul 2017 09:07:38 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:40579 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dVdqB-0005yi-B4 for qemu-devel@nongnu.org; Thu, 13 Jul 2017 09:07:35 -0400 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6DD4K4T075364 for ; Thu, 13 Jul 2017 09:07:34 -0400 Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by mx0b-001b2d01.pphosted.com with ESMTP id 2bp1sqrx0y-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Jul 2017 09:07:34 -0400 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 13 Jul 2017 14:07:32 +0100 References: <1499942429-55449-1-git-send-email-borntraeger@de.ibm.com> <1499942429-55449-3-git-send-email-borntraeger@de.ibm.com> <20170713141158.32e74897@gondolin> <20170713145714.1c5443f2@gondolin> From: Halil Pasic Date: Thu, 13 Jul 2017 15:07:28 +0200 MIME-Version: 1.0 In-Reply-To: <20170713145714.1c5443f2@gondolin> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Message-Id: <0eaf8425-c497-25a7-a529-6a806fbc51e4@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH/s390-next 2/3] s390x/cpumodel: add zpci, aen and ais facilities List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck , Christian Borntraeger Cc: qemu-devel , Alexander Graf , Richard Henderson , Yi Min Zhao , Pierre Morel , Thomas Huth On 07/13/2017 02:57 PM, Cornelia Huck wrote: > On Thu, 13 Jul 2017 14:41:05 +0200 > Christian Borntraeger wrote: > >> On 07/13/2017 02:11 PM, Cornelia Huck wrote: >>> On Thu, 13 Jul 2017 12:40:28 +0200 >>> Christian Borntraeger wrote: >>> >>>> From: Yi Min Zhao >>>> >>>> zPCI instructions and facilities are available since IBM zEnterprise >>>> EC12. To support z/PCI in QEMU we enable zpci, aen and ais facilities >>>> starting with zEC12 GA1. And we always set zpci and aen bits in max cpu >>>> model. Later they might be switched off due to applied real cpu model. >>>> For ais bit, we only provide it in the full cpu model beginning with >>>> zEC12 and defer its enablement in the default cpu model to a later point >>>> in time. At the same time, disable them for 2.9 and older machines. >>>> >>>> Because of introducing AIS facility, we could check if it's enabled to >>>> initialize flic->ais_supported with the real value. >>>> >>>> Signed-off-by: Yi Min Zhao >>>> Signed-off-by: Christian Borntraeger >>>> --- >>>> hw/intc/s390_flic.c | 3 ++- >>>> hw/intc/s390_flic_kvm.c | 3 --- >>>> hw/s390x/s390-virtio-ccw.c | 3 +++ >>>> target/s390x/cpu_features.c | 3 +++ >>>> target/s390x/cpu_features_def.h | 3 +++ >>>> target/s390x/gen-features.c | 5 +++++ >>>> target/s390x/kvm.c | 7 +++++++ >>>> 7 files changed, 23 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/hw/intc/s390_flic.c b/hw/intc/s390_flic.c >>>> index ff6e4ec..6e7c610 100644 >>>> --- a/hw/intc/s390_flic.c >>>> +++ b/hw/intc/s390_flic.c >>>> @@ -163,9 +163,10 @@ static void s390_flic_common_realize(DeviceState *dev, Error **errp) >>>> if (max_batch > ADAPTER_ROUTES_MAX_GSI) { >>>> error_setg(errp, "flic property adapter_routes_max_batch too big" >>>> " (%d > %d)", max_batch, ADAPTER_ROUTES_MAX_GSI); >>>> + return; >>> >>> Hunk should go into a previous patch? >>> >>> (And does it really matter?) >> >> I can >> - move to the previous series patch 8 (s390x/flic: introduce modify_ais_mode callback) >> - remove the return as it does not matter (this is realize, and realize failures here >> are fatal as far as I can tell) >> - keep it here since this version was tested and it does not hurt >> > > I'd say 2 or 3, no need to juggle existing patches for what is > basically a non-issue. > Realize failures are supposed to be fatal and it's also working like that for flic. I'm in favor of 3 (keeping) as the resulting code is cleaner: it does not make any sense to 'continue realizing', even if 'continue realizing' and set a correct ais_supported just to fail later does not hurt.