From patchwork Tue Apr 7 14:26:16 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Kevin Wolf X-Patchwork-Id: 1267450 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=jBjOtcEe; dkim-atps=neutral Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 48xVC61zl3z9sTP for ; Wed, 8 Apr 2020 00:28:50 +1000 (AEST) Received: from localhost ([::1]:48248 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLpDc-00048I-4y for incoming@patchwork.ozlabs.org; Tue, 07 Apr 2020 10:28:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55205) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLpBf-0000UY-Kf for qemu-devel@nongnu.org; Tue, 07 Apr 2020 10:26:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLpBe-00070T-Dz for qemu-devel@nongnu.org; Tue, 07 Apr 2020 10:26:47 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:47130 helo=us-smtp-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jLpBe-000708-Av for qemu-devel@nongnu.org; Tue, 07 Apr 2020 10:26:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586269606; 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=EEOR6aQu29iz80z013fDsdrq8dMvIXpmYtmMVT/1Fck=; b=jBjOtcEehXvHLkZcmDxbUO09DM1QMuzQjJij3irEwq73pozQfOMBE94XK1F0Nmx6Aq/P1D FC/kw/46Uk6vhIXKUlWCV2oUYXf/KMsZWio/JcWwxxDnKlSHD5Jy54VGWVqQEoSjcFoRXm 3gUCt/xWD1lTc9XJXNN4KxWiixX3NTQ= 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-258-8mrXYvuROfWlQofSeD2t8g-1; Tue, 07 Apr 2020 10:26:40 -0400 X-MC-Unique: 8mrXYvuROfWlQofSeD2t8g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 293438017F4; Tue, 7 Apr 2020 14:26:39 +0000 (UTC) Received: from linux.fritz.box.com (ovpn-113-253.ams2.redhat.com [10.36.113.253]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2AEA25DA7B; Tue, 7 Apr 2020 14:26:38 +0000 (UTC) From: Kevin Wolf To: qemu-block@nongnu.org Subject: [PULL 7/7] vpc: Don't round up already aligned BAT sizes Date: Tue, 7 Apr 2020 16:26:16 +0200 Message-Id: <20200407142616.7961-8-kwolf@redhat.com> In-Reply-To: <20200407142616.7961-1-kwolf@redhat.com> References: <20200407142616.7961-1-kwolf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 205.139.110.120 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kwolf@redhat.com, peter.maydell@linaro.org, qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" As reported on Launchpad, Azure apparently doesn't accept images for upload that are not both aligned to 1 MB blocks and have a BAT size that matches the image size exactly. As far as I can tell, there is no real reason why we create a BAT that is one entry longer than necessary for aligned image sizes, so change that. (Even though the condition is only mentioned as "should" in the spec and previous products accepted larger BATs - but we'll try to maintain compatibility with as many of Microsoft's ever-changing interpretations of the VHD spec as possible.) Fixes: https://bugs.launchpad.net/bugs/1870098 Reported-by: Tobias Witek Signed-off-by: Kevin Wolf Message-Id: <20200402093603.2369-1-kwolf@redhat.com> Reviewed-by: Max Reitz Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Kevin Wolf --- block/vpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/vpc.c b/block/vpc.c index 6df75e22dc..d8141b52da 100644 --- a/block/vpc.c +++ b/block/vpc.c @@ -835,7 +835,7 @@ static int create_dynamic_disk(BlockBackend *blk, uint8_t *buf, /* Write the footer (twice: at the beginning and at the end) */ block_size = 0x200000; - num_bat_entries = (total_sectors + block_size / 512) / (block_size / 512); + num_bat_entries = DIV_ROUND_UP(total_sectors, block_size / 512); ret = blk_pwrite(blk, offset, buf, HEADER_SIZE, 0); if (ret < 0) {