Il 19/08/2013 18:51, James Bottomley ha scritto:
>> No, it cannot. First of all, it only works for virtio-blk devices
>> backed by a physical disk (not a logical volume, not a partition, not a
>> file). That's a feature, not a bug, since we do not want virtio-blk
>> devices to carry a SCSI target implementation (QEMU's is 2.5 kSLOC).
>
> The unstated assumption above is that SCSI emulators are huge. This is
> bogus. The tiny USB key you probably have in your pocket at the moment
> that you bought for a tenner has a minimal SCSI emulator inside its rom.
And you know how many off-by-one errors or "liberal" implementations of
the standards they contain, and how much code is in sd.c (or in USB
quirks) to handle those problems.
A simple virtio-scsi implementation could use a small SCSI emulator.
But it could still be twice the size of virtio-blk, perhaps.
> You don't need to emulate every command. Just those that provide the
> features you want.
>
>> Second, any change you make through SCSI requests is not visible to the
>> host. For example, if the guest kernel used SCSI requests to enable
>> writeback caching, the host would not know about it and will not send
>> flushes (thus a power loss will eat data).
>
> I'm a bit lost here. If you mean the native case, so host passes
> commands directly to underlying SCSI, then, of course, you're correct,
> the host driver doesn't snoop. But the command chain is unbroken from
> guest to physical device, so there's no data loss on power failure. If
> you mean the emulated case, then the host has to intercept the command.
VIRTIO_BLK_F_SCSI is not meant to do emulation, since you can perfectly
use virtio-scsi for that usecase.
Paolo
