From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkth8-0004dB-GA for qemu-devel@nongnu.org; Thu, 24 Aug 2017 11:05:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkth4-00036r-H0 for qemu-devel@nongnu.org; Thu, 24 Aug 2017 11:05:18 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:43226 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 1dkth4-00036N-Bw for qemu-devel@nongnu.org; Thu, 24 Aug 2017 11:05:14 -0400 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7OEuSfx169661 for ; Thu, 24 Aug 2017 11:05:13 -0400 Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by mx0b-001b2d01.pphosted.com with ESMTP id 2chypywpmx-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Aug 2017 11:05:13 -0400 Received: from localhost by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 24 Aug 2017 09:05:12 -0600 From: Farhan Ali Date: Thu, 24 Aug 2017 11:05:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Message-Id: Subject: [Qemu-devel] S390 bios breaks in qemu 2.10.rc3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Cornelia Huck Cc: Halil Pasic , Christian Borntraeger , "Collin L. Walling" Hi, There is an issue in QEMU bios which is exposed by commit commit 198c0d1f9df8c429502cb744fc26b6ba6e71db74 Author: Halil Pasic Date: Thu Jul 27 17:48:42 2017 +0200 s390x/css: check ccw address validity According to the PoP channel command words (CCW) must be doubleword aligned and 31 bit addressable for format 1 and 24 bit addressable for format 0 CCWs. If the channel subsystem encounters a ccw address which does not satisfy this alignment requirement a program-check condition is recognised. The situation with 31 bit addressable is a bit more complicated: both the ORB and a format 1 CCW TIC hold the address of (the rest of) the channel program, that is the address of the next CCW in a word, and the PoP mandates that bit 0 of that word shall be zero -- or a program-check condition is to be recognized -- and does not belong to the field holding the ccw address. Since in code the corresponding fields span across the whole word (unlike in PoP where these are defined as 31 bit wide) we can check this by applying a mask. The 24 addressable case isn't affecting TIC because the address is composed of a halfword and a byte portion (no additional zero bit requirements) and just slightly complicates the ORB case where also bits 1-7 need to be zero. The same requirements (especially n-bit addressability) apply to the ccw addresses generated while chaining. Let's make our CSS implementation follow the AR more closely. Signed-off-by: Halil Pasic Message-Id: <20170727154842.23427-1-pasic@linux.vnet.ibm.com> Reviewed-by: Dong Jia Shi Signed-off-by: Cornelia Huck It looks like the bios does not create a double word aligned CCW. Looking at the bios code we the CCW1 struct is not aligned /* channel command word (type 1) */ struct ccw1 { __u8 cmd_code; __u8 flags; __u16 count; __u32 cda; } __attribute__ ((packed)); and it looks like the compiler does not guarantee a doubleword alignment. The weird thing about it is I see it break in one of my system and works fine in another system. Trying a simple fix of aligning the struct also doesn't seem to work all the time. Thanks Farhan