From patchwork Sat Oct 10 03:01:55 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Crosthwaite X-Patchwork-Id: 528509 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 70A79140E3F for ; Sat, 10 Oct 2015 14:02:33 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=g420qK+q; dkim-atps=neutral Received: from localhost ([::1]:43400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkkQZ-00053Z-DA for incoming@patchwork.ozlabs.org; Fri, 09 Oct 2015 23:02:31 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51325) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkkQI-0004mv-PM for qemu-devel@nongnu.org; Fri, 09 Oct 2015 23:02:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkkQA-0005Ob-82 for qemu-devel@nongnu.org; Fri, 09 Oct 2015 23:02:14 -0400 Received: from mail-pa0-x231.google.com ([2607:f8b0:400e:c03::231]:34733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkkQ9-0005Nf-Uj for qemu-devel@nongnu.org; Fri, 09 Oct 2015 23:02:06 -0400 Received: by padhy16 with SMTP id hy16so102459357pad.1 for ; Fri, 09 Oct 2015 20:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=hnoUYMWh32EuXzVBYSkzjjmufhaNg6trHKVlkudshZc=; b=g420qK+qzTnyCCAH6CttD8Di0j0wmpdVodaZj/X4u8QoG4nPJ0fRAjv8ncRBI+5xs0 qFmOGMTUt95qD3SM4zpAHfyJR3GFkDGBZaOtC0in1fqKpCCPxFdAiOgqAs/HVkVffnBU H4d0MduBkkcuLzhqLZmyXjPzg/7yaf2b8oV2AlVP5/NBw4XlYpuuTcsOYLh6y8KmS8mm 2Giz9+sFXsCLSDXtP1m1u68r210Eu9PJGxowSXgLVqStxtFYUhbvttBGpWGiS1Qwa+DF BlYh6ekyTtHhS7Zxni3CddT2hPZcEbuEJOnBLDTIAOEevXjURDDkvfGJ8T1w6rnAF8yq DFJQ== X-Received: by 10.68.217.8 with SMTP id ou8mr19633932pbc.164.1444446125429; Fri, 09 Oct 2015 20:02:05 -0700 (PDT) Received: from pcrost-box.attlocal.net (104-10-248-117.lightspeed.sntcca.sbcglobal.net. [104.10.248.117]) by smtp.gmail.com with ESMTPSA id qn5sm5079380pac.41.2015.10.09.20.02.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Oct 2015 20:02:04 -0700 (PDT) From: Peter Crosthwaite X-Google-Original-From: Peter Crosthwaite To: qemu-devel@nongnu.org Date: Fri, 9 Oct 2015 20:01:55 -0700 Message-Id: <1444446115-3796-1-git-send-email-crosthwaite.peter@gmail.com> X-Mailer: git-send-email 1.9.1 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::231 Cc: kwolf@redhat.com, saipava@xilinx.com, stefanha@redhat.com, Peter Crosthwaite Subject: [Qemu-devel] [RFC] Block device size rounding X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org I have in interesting problem with SD cards, where if you pass a block device that is not multiple-of-512k size the last bit gets chopped off. The problem is the card can only report a 512kX size to the guest, so a significant rounding is needed one way or the other. The current round-down policy causes crashing boots because parts of my guest file-system are missing. The below patch works around it, by changing to round-up and simply ignoring reads and writes past the end of the block device file. What is the correct action here though? If the file is writeable should we just allow the device to extend its size? Is that possible already? Just zero-pad read-only? The same could be applied to pflash, where the device init barfs if the backing file is too small (the devices are inited of a constant size, not based on the block device size). Requiring the user to pad files in a device dependent way is a little user-unfriendly. Regards, Peter --- hw/sd/sd.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/hw/sd/sd.c b/hw/sd/sd.c index 3e2a451..539bb72 100644 --- a/hw/sd/sd.c +++ b/hw/sd/sd.c @@ -248,13 +248,18 @@ static const uint8_t sd_csd_rw_mask[16] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfc, 0xfe, }; -static void sd_set_csd(SDState *sd, uint64_t size) +static uint64_t sd_set_csd(SDState *sd, uint64_t size) { - uint32_t csize = (size >> (CMULT_SHIFT + HWBLOCK_SHIFT)) - 1; - uint32_t sectsize = (1 << (SECTOR_SHIFT + 1)) - 1; - uint32_t wpsize = (1 << (WPGROUP_SHIFT + 1)) - 1; + uint64_t actual_size; if (size <= 0x40000000) { /* Standard Capacity SD */ + uint32_t sectsize = (1 << (SECTOR_SHIFT + 1)) - 1; + uint32_t wpsize = (1 << (WPGROUP_SHIFT + 1)) - 1; + uint32_t csize; + + actual_size = ROUND_UP(size, 1 << (CMULT_SHIFT + HWBLOCK_SHIFT)); + csize = (actual_size >> (CMULT_SHIFT + HWBLOCK_SHIFT)) - 1; + sd->csd[0] = 0x00; /* CSD structure */ sd->csd[1] = 0x26; /* Data read access-time-1 */ sd->csd[2] = 0x00; /* Data read access-time-2 */ @@ -281,7 +286,8 @@ static void sd_set_csd(SDState *sd, uint64_t size) sd->csd[14] = 0x00; /* File format group */ sd->csd[15] = (sd_crc7(sd->csd, 15) << 1) | 1; } else { /* SDHC */ - size /= 512 * 1024; + actual_size = ROUND_UP(size, 512 * 1024); + size = actual_size / (512 * 1024); size -= 1; sd->csd[0] = 0x40; sd->csd[1] = 0x0e; @@ -301,6 +307,7 @@ static void sd_set_csd(SDState *sd, uint64_t size) sd->csd[15] = 0x00; sd->ocr |= 1 << 30; /* High Capacity SD Memory Card */ } + return actual_size; } static void sd_set_rca(SDState *sd) @@ -408,7 +415,7 @@ static void sd_reset(SDState *sd) sd_set_ocr(sd); sd_set_scr(sd); sd_set_cid(sd); - sd_set_csd(sd, size); + size = sd_set_csd(sd, size); sd_set_cardstatus(sd); sd_set_sdstatus(sd);