Re: [Qemu-devel] Re: [PATCH 0/2] fix virtio_blk serial pci config breakage

[Jamie Lokier]

Rusty Russell wrote:
> On Wed, 30 Sep 2009 11:47:00 am Anthony Liguori wrote:
> > Rusty Russell wrote:
> > > On Wed, 30 Sep 2009 06:25:39 am Anthony Liguori wrote:
> > >   
> > >> virtio-blk isn't an ATA device so why pretend like it is?
> ... 
> > That's an argument to implement the HDIO_GET_IDENTITY ioctl in the Linux 
> > virtio-blk driver.  That's a totally reasonable thing to do.
> 
> Your second sentence contradicts your first here.  If it's reasonable to
> imitate ATA in Linux, it's reasonable to imitate ATA in virtio.
> 
> Using an existing standard should always be the default; one should need a
> compelling reason *not* to do so.  In practice, (1) that code already exists
> in kvm, and (2) it makes the Linux implementation trivial.
> 
> So, what are the real arguments?
> (1) Some fields are redundant (eg. geometry) with existing fields already.
> (2) Future fields will have to decide whether to use ATA IDENTIFY or normal
>     features,
> (3) We don't know enough about ATA IDENTIFY to do a decent job of filling
>     it in.
> 
> I can buy (1), but I still have to deal with (2) and (3) if they're inside
> the virtio_blk driver anyway.
> 
> Anything else?

(4) Putting it into the virtio_blk driver means another duplicate
implementation, and it might have to be duplicated another time in the
Windows virtio_blk driver too, if there's a Windows generic equivalent
to HDIO_GET_IDENTITY (I don't know if there is though).

(5) When the host's backing driver is itself a disk implementing the
ATA command, would you ever want the guest to see all details of the
identity page as close as possible to the host device sometimes?
I.e. is virtio_blk a way to accelerate block I/O to a host device, or
a way to abstract it to the bare minimum?

(6) Why don't we use the SCSI identity page instead?  Presumably
that's already in qemu/kvm too, for SCSI and USB disks :-)

-- Jamie