> On Jun 24, 2021, at 4:56 AM, Peter Maydell wrote: > > On Thu, 24 Jun 2021 at 11:27, Tom Yan wrote: >> I really think we should get (/ have gotten) things clear first. What >> exactly is the bug we have been talking about here? I mean like, where >> does it occur and what's the nature of it. >> >> 1. Is it specific to a certain type / model of backend / physical >> storage device that will be made use of by qemu for the emulated >> storage? (I presume not since you mention about image, unless you >> irrationally related/bound the emulated storage type and the physical >> storage type together.) >> >> 2. Does it have anything to do with a certain flaw in qemu itself? >> Like the code that does read/write operation is flawed that it cannot >> be handled by a certain *proper* backend device? >> >> 3. Or is it actually a bug in a certain driver / firmware blob that >> will be used by an *emulated* device in the guest? In that case, can >> we emulate another model so that it won't be using the problematic >> driver / firmware? > > Definitely agreed -- before we start changing QEMU code we need > to identify clearly (a) what the real hardware does and (b) what > the situation was we were originally trying to fix. Real SD and MMC cards do not have power-of-two constraints in the number of blocks. None of the SD/MMC bridges I’ve ever dealt with have a power-of-two constraint on the size of the card. The only constraint on the size related to the card is the block size. If non-power-of-2 sized cards fail, that’s a cat-1 sev-1 bug that needs to be fixed, rather than a warning be generated. Warner