From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deyuY-0000jV-Fz for qemu-devel@nongnu.org; Tue, 08 Aug 2017 03:26:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1deyuT-0004Ev-Fr for qemu-devel@nongnu.org; Tue, 08 Aug 2017 03:26:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47710) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1deyuT-0004Ea-6P for qemu-devel@nongnu.org; Tue, 08 Aug 2017 03:26:37 -0400 Date: Tue, 8 Aug 2017 09:26:27 +0200 From: Cornelia Huck Message-ID: <20170808092627.4450aa05@gondolin> In-Reply-To: <016df631-ccf8-69bd-0211-becbecac4450@redhat.com> References: <1501767019-4989-1-git-send-email-thuth@redhat.com> <20170807232833-mutt-send-email-mst@kernel.org> <016df631-ccf8-69bd-0211-becbecac4450@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] tests/pxe: Check virtio-net-ccw on s390x List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, Jason Wang , Christian Borntraeger , Victor Kaplansky On Tue, 8 Aug 2017 07:19:54 +0200 Thomas Huth wrote: > On 07.08.2017 22:35, Michael S. Tsirkin wrote: > > On Thu, Aug 03, 2017 at 03:30:19PM +0200, Thomas Huth wrote: > >> Now that we've got a firmware that can do TFTP booting on s390x (i.e. > >> the pc-bios/s390-netboot.img), we can enable the PXE tester for this > >> architecture, too. > >> > >> Signed-off-by: Thomas Huth > >> @@ -81,10 +83,27 @@ int boot_sector_init(char *fname) > >> } > >> > >> /* For Open Firmware based system, we can use a Forth script instead */ > >> - if (strcmp(qtest_get_arch(), "ppc64") == 0) { > >> + if (g_str_equal(arch, "ppc64")) { > >> len = sprintf((char *)boot_sector, "\\ Bootscript\n%x %x c! %x %x c!\n", > >> - LOW(SIGNATURE), BOOT_SECTOR_ADDRESS + SIGNATURE_OFFSET, > >> - HIGH(SIGNATURE), BOOT_SECTOR_ADDRESS + SIGNATURE_OFFSET + 1); > >> + LOW(SIGNATURE), SIGNATURE_ADDR, > >> + HIGH(SIGNATURE), SIGNATURE_ADDR + 1); > >> + } else if (g_str_equal(arch, "s390x")) { > >> + /* For s390x, fake a kernel signature */ > >> + const uint8_t psw[] = { > >> + 0x00, 0x08, 0x00, 0x00, 0x80, 0x01, 0x00, 0x00 > >> + }; > >> + const uint8_t code[] = { > >> + 0xa7, 0xf4, 0x00, 0x0a, /* j 0x10010 */ > >> + 0x00, 0x00, 0x00, 0x00, > >> + 'S', '3', '9', '0', > >> + 'E', 'P', 0x00, 0x01, > >> + 0xa7, 0x38, HIGH(SIGNATURE_ADDR), LOW(SIGNATURE_ADDR), /* lhi r3 */ > >> + 0xa7, 0x48, LOW(SIGNATURE), HIGH(SIGNATURE), /* lhi r4,0xadde */ > >> + 0x40, 0x40, 0x30, 0x00, /* sth r4,0(r3) */ > >> + 0xa7, 0xf4, 0xff, 0xfa /* j 0x10010 */ > >> + }; > >> + memcpy(boot_sector, psw, 8); > >> + memcpy(&boot_sector[0x10000], code, sizeof(code)); > > > > > > Could we avoid overwriting boot sector? > > We really should have > > x86_boot_sector > > ppc64_boot_sector > > s390_boot_sector > > > > And write out the correct thing. That sounds good. > > Ok, I don't mind either way ... I can try to come up with a patch. > > > Also: > > * Q35 machine requires a minimum 0x7e000 bytes disk. > > * (bug or feature?) > > > > probably does not apply to s390x, does it? > > We can also just load 0x10000 + sizeof(code) bytes here. I'll fix it. > > Cornelia, please unqueue the patch, I'll send a v2... OK, I had not yet pushed out anyway.