@@ -154,7 +154,8 @@ typedef struct FDrive {
FDCtrl *fdctrl;
BlockBackend *blk;
/* Drive status */
- FDriveType drive;
+ FDriveType drive; /* CMOS drive type */
+ FDriveType disk; /* Current disk type */
uint8_t perpendicular; /* 2.88 MB access mode */
/* Position */
uint8_t head;
@@ -174,6 +175,7 @@ static void fd_init(FDrive *drv)
{
/* Drive */
drv->drive = FDRIVE_DRV_NONE;
+ drv->disk = FDRIVE_DRV_NONE;
drv->perpendicular = 0;
/* Disk */
drv->last_sect = 0;
@@ -316,7 +318,10 @@ static void pick_geometry(FDrive *drv, int *nb_heads)
*nb_heads = parse->max_head + 1;
drv->max_track = parse->max_track;
drv->last_sect = parse->last_sect;
- drv->drive = parse->drive;
+ if (drv->drive == FDRIVE_DRV_NONE) {
+ drv->drive = parse->drive;
+ }
+ drv->disk = parse->drive;
drv->media_rate = parse->rate;
}
Allows us to distinguish between the current DISK type and the current DRIVE type. The DRIVE is what's reported to CMOS, the DISK is whatever the revalidate function suspects has been inserted into the drive. The 'drive' field maintains the same meaning as it did previously, however, the revalidate function will no longer update the "drive" field once it has been changed away from FDRIVE_DRV_NONE, opting to only update the "disk" field instead. This should have no impact on the current pick_geometry algorithm, because it is already incapable of choosing a new drive type after initial setup. Thus, as of this patch, disk and drive will always be the same. Disk does not need to be migrated because it is not user-visible state nor is it currently used for any calculations. It is purely informative, and will be rebuilt automatically via fd_revalidate on the new host. Signed-off-by: John Snow <jsnow@redhat.com> --- hw/block/fdc.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)