From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmRKu-0004JG-S7 for qemu-devel@nongnu.org; Wed, 04 Jul 2012 11:17:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmRKq-00051C-0R for qemu-devel@nongnu.org; Wed, 04 Jul 2012 11:17:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmRKp-00050z-OI for qemu-devel@nongnu.org; Wed, 04 Jul 2012 11:17:43 -0400 Message-ID: <4FF45E87.8060100@redhat.com> Date: Wed, 04 Jul 2012 17:17:27 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1340984094-5451-1-git-send-email-armbru@redhat.com> <1340984094-5451-4-git-send-email-armbru@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 03/32] vvfat: Fix partition table List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: pbonzini@redhat.com, aliguori@us.ibm.com, Markus Armbruster , stefanha@linux.vnet.ibm.com, qemu-devel@nongnu.org Am 29.06.2012 22:33, schrieb Blue Swirl: > On Fri, Jun 29, 2012 at 3:34 PM, Markus Armbruster wrote: >> Unless parameter ":floppy:" is given, vvfat creates a virtual image >> with DOS MBR defining a single partition which holds the FAT file >> system. The size of the virtual image depends on the width of the >> FAT: 32 MiB (CHS 64, 16, 63) for 12 bit FAT, 504 MiB (CHS 1024, 16, >> 63) for 16 and 32 bit FAT, leaving (64*16-1)*63 = 64449 and >> (1024*16-1)*64 = 1032129 sectors for the partition. >> >> However, it screws up the end of the partition in the MBR: >> >> FAT width param. start CHS end CHS start LBA size >> :32: 0,1,1 1023,14,63 63 1032065 >> :16: 0,1,1 1023,14,55 63 1032057 >> :12: 0,1,1 63,14,55 63 64377 >> >> The actual FAT file system nevertheless assumes the partition has >> 1032129 or 64449 sectors. Oops. >> >> Signed-off-by: Markus Armbruster >> --- >> block/vvfat.c | 7 ++++--- >> 1 files changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/block/vvfat.c b/block/vvfat.c >> index 0fd3367..62745b5 100644 >> --- a/block/vvfat.c >> +++ b/block/vvfat.c >> @@ -394,11 +394,12 @@ static void init_mbr(BDRVVVFATState* s) >> >> /* LBA is used when partition is outside the CHS geometry */ >> lba = sector2CHS(s->bs, &partition->start_CHS, s->first_sectors_number-1); >> - lba|= sector2CHS(s->bs, &partition->end_CHS, s->sector_count); >> + lba |= sector2CHS(s->bs, &partition->end_CHS, s->bs->total_sectors - 1); >> >> /*LBA partitions are identified only by start/length_sector_long not by CHS*/ >> - partition->start_sector_long =cpu_to_le32(s->first_sectors_number-1); >> - partition->length_sector_long=cpu_to_le32(s->sector_count - s->first_sectors_number+1); >> + partition->start_sector_long = cpu_to_le32(s->first_sectors_number-1); > > Spaces around '-'. Thanks for fixing the other cases, BTW. For compensation there's an extra space before the '='. >> + partition->length_sector_long = cpu_to_le32(s->bs->total_sectors >> + - s->first_sectors_number + 1); Just wondering... This should be the same as s->sector_count, right? This whole geometry calculation code in vvfat is way too convoluted to understand when you haven't looked at it for some months... Kevin