Re: Regarding commit a9bcedd (SD card size has to be power of 2)

[Daniel P . Berrangé]

On Mon, Jun 07, 2021 at 04:29:54PM +0800, Tom Yan wrote:
> Hi philmd (and others),
> 
> So I just noticed your commit of requiring the size of an emulated SD
> card to be a power of 2, when I was trying to emulate one for an
> actual one (well, it's a microSD, but still), as it errored out.
> 
> You claim that the kernel will consider it to be a firmware bug and
> "correct" the capacity by rounding it up. Could you provide a concrete
> reference to the code that does such a thing? I'm not ruling out that
> some crazy code could have gone upstream because some reviewers might
> not be doing their job right, but if that really happened, it's a
> kernel bug/regression and qemu should not do an equally-crazy thing to
> "fix" it.

I looked back at the original threads for details, but didn't
find any aside from this short message saying it broke Linux:

  https://www.mail-archive.com/qemu-devel@nongnu.org/msg720737.html

Philippe, do you have more details on the problem hit, or pointer
to where the power-of-2 restriction is in Linux ?

> No offense but what you claimed really sounds absurd and ridiculous.
> Although I don't have hundreds of SD cards in hand, I owned quite a
> few at least, like most people do, with capacities ranging from ~2G to
> ~128G, and I don't even recall seeing a single one that has the
> capacity being a power of 2. (Just like vendors of HDDs and SSDs, they
> literally never do that AFAICT, for whatever reasons.)

Yes, this does feel pretty odd to me too, based on the real physical
SD cards I've used with Linux non-power-2 sizes.

Also in general QEMU shouldn't be enforcing restrictions based on
guest behaviour, it should follow the hardware specs. If the
hardware spec doesn't mandate power-of-2 sizes, then QEMU shoud
not require that, even if some guest OS has added an artificial
restriction of its own.

> Besides, even if there's a proper reason for the kernel to "fix" the
> capacity, there's no reason for it to round it up either, because
> obviously there will never be actual storage for the "virtual blocks".
> I've never seen such a behavior so far either with the "mmcblk" hosts
> I've used so far.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|