Re: [Qemu-devel] [PATCH 04/32] vvfat: Do not clobber the user's geometry

[Markus Armbruster]

Kevin Wolf <address@hidden> writes:

> Am 04.07.2012 18:25, schrieb Paolo Bonzini:
>> Il 04/07/2012 17:23, Kevin Wolf ha scritto:
>>>>>     opts        LCHS        def. PCHS
>>>>>        :floppy:   80, 2,36  5,16,63
>>>>>     :32:floppy:   80, 2,36  5,16,63
>>>>>     :16:floppy:   80, 2,36  5,16,63
>>>>>     :12:floppy:   80, 2,18  2,16,63
>>>>>
>>>>> Silly thing to do for use with a hard disk.
>>>>>
>>>>> However, the "raw" format can be suppressed by adding an
>>>>> redundant-looking "format=vvfat" to "file=fat:FOO".  Then, vvfat's
>>>>> hint clobbers the user's geometry, i.e. -drive options cyls, heads,
>>>>> secs get silently ignored.  Don't do that.
>>>>>
>>>>> No change without format=vvfat.  With it, the user's hard disk
>>>>> geometry (-drive options cyls, heads, secs) is now obeyed, and the
>>>>> default hard disk geometry with :floppy: now matches the one without
>>>>> format=vvfat.
>>>>>
>>>>> Signed-off-by: Markus Armbruster <address@hidden>
>>> For some values of "obeyed". If I understand correctly, the user defined
>>> geometry will indeed by visible for the device emulation now, but this
>>> still doesn't mean that vvfat also provides an image that matches this
>>> geometry. Not sure if it is a good idea to allow such mismatches.

This patch doesn't let the user do anything he couldn't do before.  It
only makes the special case "vvfat without raw on top" consistent with
all other block backend configurations.  With "raw over vvfat" in
particular.

So, if anything needs additional user parameter validation, it's the
common case.  Note that any other image type could contain the very same
FAT filesystem as a vvfat one, with the very same impact on a guest
vulnerable to mismatches between geometry and block device contents.

To avoid confusion, let me recap geometry.

Physical geometry is a property of the disk.  Or rather, a property of
the disk's legacy CHS command interface; it ceased to have any useful
relation to platters and heads long ago.  Non-legacy commands use LBA to
address blocks.

Logical geometry is a property of the PC BIOS legacy CHS interface (int
13h).  It was invented when disks outgrew the BIOS's CHS limits.  It
need not match physical geometry (*not* matching is its purpose).  The
BIOS translates logical geometry to something the disk understands.
Long ago, this meant translating to physical CHS.  Nowadays, it means
translating to LBA.  As far as I can tell, SeaBIOS always translates to
LBA.  SeaBIOS picks a logical geometry based on what it finds in CMOS.

Logical geometry matters only for software that uses legacy int 13h.
DOS, basically.

Physical geometry matters only for software that talks to the disk
directly, using legacy CHS commands.  Sufficently old versions of Unix,
perhaps?

The choice of geometry isn't really important, as long as:

1. The mapping to LBA is sane: lba = ((c * #h) + h * #s) + (s-1)

   where c, h, s is the address, and #c, #h, #s is the geometry.
   Increasing first s, then h, then c runs through the lbas in order,
   regardless of what you picked for geometry.

   For physical geometry, the device model maps.  As far as I can tell,
   they all map sanely.

   For logical geometry, SeaBIOS maps.  As far as I can tell, it maps
   sanely.

   Actually, even an insane mapping would work for block drivers that
   only schlep blocks, as long as it doesn't change.  Same as with
   physical disks.

2. The OS is happy with the partition table.

   Some OSs want each partition to start and end on a cylinder boundary.
   For them, whatever geometry they use should be consistent with the
   partition table.

   Note that before PATCH 03/32, vvfat's partition end was screwed up,
   and nobody noticed.

>> Does this only matter if you declare an image with :floppy: and pass it
>> as a hard disk?  Then we can honestly say we don't care...
>
> As I understand it, the patch has two effect:
>
> 1. the user's hard disk geometry (-drive options cyls, heads, secs) is
> now obeyed

... even when the user suppresses raw by specifying format=vvfat with
file=fat:...  Consistent with how all other block drivers work.

> 2. the default hard disk geometry with :floppy: now matches the one
> without format=vvfat

Yes.

> I don't care about 2. indeed, but doing 1. right would be nice.