Re: [PATCH v2 1/8] hw/sd/sdcard: Fix size check for backing block image

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 2/9/25 19:53, Jan Kiszka wrote:
> On 02.09.25 19:48, Warner Losh wrote:
>>
>>
>> On Tue, Sep 2, 2025 at 11:37 AM Jan Kiszka <jan.kiszka@siemens.com
>> <mailto:jan.kiszka@siemens.com>> wrote:
>>
>>      On 02.09.25 19:30, Warner Losh wrote:
>>      >
>>      >
>>      > On Tue, Sep 2, 2025 at 11:22 AM Warner Losh <imp@bsdimp.com
>>      <mailto:imp@bsdimp.com>
>>      > <mailto:imp@bsdimp.com <mailto:imp@bsdimp.com>>> wrote:
>>      >
>>      >
>>      >
>>      >     On Tue, Sep 2, 2025 at 11:18 AM Jan Kiszka
>>      <jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>
>>      >     <mailto:jan.kiszka@siemens.com
>>      <mailto:jan.kiszka@siemens.com>>> wrote:
>>      >
>>      >         On 02.09.25 19:07, Warner Losh wrote:
>>      >         >
>>      >         >
>>      >         > On Tue, Sep 2, 2025 at 10:49 AM Jan Lübbe
>>      <jlu@pengutronix.de <mailto:jlu@pengutronix.de>
>>      >         <mailto:jlu@pengutronix.de <mailto:jlu@pengutronix.de>>
>>      >         > <mailto:jlu@pengutronix.de <mailto:jlu@pengutronix.de>
>>      <mailto:jlu@pengutronix.de <mailto:jlu@pengutronix.de>>>> wrote:
>>      >         >
>>      >         >     On Tue, 2025-09-02 at 18:39 +0200, Jan Kiszka wrote:
>>      >         >     > > > I expect us to be safe and able to deal with non-
>>      >         pow2 regions
>>      >         >     if we use
>>      >         >     > > > QEMUSGList from the "system/dma.h" API. But
>>      this is
>>      >         a rework
>>      >         >     nobody had
>>      >         >     > > > time to do so far.
>>      >         >     > >
>>      >         >     > > We have to tell two things apart: partitions
>>      sizes on
>>      >         the one
>>      >         >     side and
>>      >         >     > > backing storage sizes. The partitions sizes are
>>      (to my
>>      >         reading)
>>      >         >     clearly
>>      >         >     > > defined in the spec, and the user partition (alone!)
>>      >         has to be
>>      >         >     power of
>>      >         >     > > 2. The boot and RPMB partitions are multiples of
>>      128K.
>>      >         The sum
>>      >         >     of them
>>      >         >     > > all is nowhere limited to power of 2 or even only
>>      >         multiples of 128K.
>>      >         >     > >
>>      >         >     >
>>      >         >     > Re-reading the part of the device capacity, the rules
>>      >         are more
>>      >         >     complex:
>>      >         >     >  - power of two up to 2 GB
>>      >         >     >  - multiple of 512 bytes beyond that
>>      >         >     >
>>      >         >     > So that power-of-two enforcement was and still is
>>      likely
>>      >         too strict.
>>      >         >
>>      >         >
>>      >         > It is. Version 0 (and MMC) cards had the capacity
>>      encoded like so:
>>      >         >                 m = mmc_get_bits(raw_csd, 128, 62, 12);
>>      >         >                 e = mmc_get_bits(raw_csd, 128, 47, 3);
>>      >         >                 csd->capacity = ((1 + m) << (e + 2)) * csd-
>>      >         >read_bl_len;
>>      >         > so any card less than 2GB (well, technically 4GB, but 4GB
>>      >         version 0
>>      >         > cards were
>>      >         > rare and broke some stacks... I have one and I love it on my
>>      >         embedded
>>      >         > ARM board
>>      >         > that can't do version 1 cards). Version 1 cards encoded
>>      it like:
>>      >         >                 csd->capacity =
>>      >         ((uint64_t)mmc_get_bits(raw_csd, 128,
>>      >         > 48, 22) +
>>      >         >                     1) * 512 * 1024;
>>      >         > So it's a multiple of 512k. These are also called 'high
>>      >         capacity' cards.
>>      >         >
>>      >         > Version 4 introduces an extended CSD, which had a pure
>>      sector
>>      >         count in
>>      >         > the EXT CSD. I think this
>>      >         > is only for MMC cards. And also the partition information.
>>      >         >
>>      >         >
>>      >         >     > But I still see no indication, neither in the existing
>>      >         eMMC code
>>      >         >     of QEMU
>>      >         >     > nor the spec, that the boot and RPMB partition
>>      sizes are
>>      >         included
>>      >         >     in that.
>>      >         >
>>      >         >     Correct. Non-power-of-two sizes are very common for real
>>      >         eMMCs.
>>      >         >     Taking a random
>>      >         >     one from our lab:
>>      >         >     [    1.220588] mmcblk1: mmc1:0001 S0J56X 14.8 GiB
>>      >         >     [    1.228055]  mmcblk1: p1 p2 p3 p4
>>      >         >     [    1.230375] mmcblk1boot0: mmc1:0001 S0J56X 31.5 MiB
>>      >         >     [    1.233651] mmcblk1boot1: mmc1:0001 S0J56X 31.5 MiB
>>      >         >     [    1.236682] mmcblk1rpmb: mmc1:0001 S0J56X 4.00 MiB,
>>      >         chardev (244:0)
>>      >         >
>>      >         >     For eMMCs using MLC NAND, you can also configure part of
>>      >         the user
>>      >         >     data area to
>>      >         >     be pSLC (pseudo single level cell), which changes the
>>      >         available
>>      >         >     capacity (after
>>      >         >     a required power cycle).
>>      >         >
>>      >         >
>>      >         > Yes. Extended partitions are a feature of version 4
>>      cards, so
>>      >         don't have
>>      >         > power-of-2 limits since they are a pure sector count in the
>>      >         ext_csd.
>>      >         >
>>      >
>>      >         JESD84-B51A (eMMC 5.1A):
>>      >
>>      >         "The C_SIZE parameter is used to compute the device
>>      capacity for
>>      >         devices
>>      >         up to 2 GB of density. See 7.4.52, SEC_COUNT [215:212] , for
>>      >         details on
>>      >         calculating densities greater than 2 GB."
>>      >
>>      >         So I would now continue to enforce power-of-2 for 2G
>>      (including)
>>      >         cards,
>>      >         and relax to multiples of 512 for larger ones.
>>      >
>>      >
>>      >     It's a multiple of 512k unless the card has a ext_csd, in
>>      which case
>>      >     it's a multiple of 512.
>>      >
>>      >
>>      > More completely, this is from MMC 4.0 and newer. Extended Capacity SD
>>      > cards report this in units of 512k bytes for all cards > 2GiB.
>>      >
>>
>>      I'm not sure which spec version you are referring to, but JESD84-A441
>>      and JESD84-B51A mention nothing about 512K, rather "Device density =
>>      SEC_COUNT x 512B". And these are the specs we very likely need to follow
>>      here.
>>
>>
>> You are right that this is in the MMC spec. However, the SD spec is
>> controlling for SD cards.
>>
>> SD Specifications Part 1 Physical Layer Simplified Specification Version
>> 9.10
>> December 1, 2023
>>
>> Section 5.3 describes the CSD. Version 1.0 (which I'd called version 0
>> in an earlier email because of its encoding) is the 2GB rule. Version
> 
> < 2G or <= 2G? For eMMC, it is <=.
> 
>> 2.0 and 3.0 encode it as 512k count (from 5.3.3):
>>
>> C_SIZE
>> This field is expanded to 28 bits and can indicate up to 128 TBytes.
>>
>> This parameter is used to calculate the user data area capacity in the
>> SD memory card (note that size of the protected area is zero for SDUC
>> card). The user data area capacity is calculated from C_SIZE as follows:
>>
>> memory capacity = (C_SIZE+1) * 512KByte
>>
>> The Minimum user area size of SDUC Card is 4,294,968,320 sectors
>> (2TB+0.5MB).
>> The Minimum value of C_SIZE for SDUC in CSD Version 3.0 is 0400000h
>> (4194304). The Maximum user area size of SDUC Card is 274,877,906,944
>> sectors (128TB).
>> The Maximum value of C_SIZE for SDUC in CSD Version 3.0 is FFFFFFFh
>> (268435455).
>>
>> So SD cards are yet again gratuitously different than MMC cards.

FTR so far QEMU only models SD spec v2.00 and v3.01, and eMMC spec 4.3.