On 9/20/19 4:22 AM, Stefan Hajnoczi wrote: > blkdebug is purely at the QEMU block layer level. It is not aware of > storage controller-specific error information or features. If you want > to inject NVMe- or SCSI-specific errors that make no sense in QEMU's > block layer, then trying to do it in blkdebug becomes a layering > violation. This justifies adding a new error injection feature directly > into AHCI, virtio-scsi, NVMe, etc devices.
Good discussion point... In my opening use case for this POC I'm generically trying to create an unrecoverable media error for a specific sector. For each of the different device types it's different on how that error is conveyed and the associated data in transfer. If we return EIO on a read_aio, that must be translated into transport specific error right? I really need to try out blkdebug and see what is seen in the guest. Maybe I'm upside down on the layering too :-) > What I like about blkdebug is the state machine and relatively powerful > tests that this enables. It makes sense to reuse those for storage > controller-specific error injection too. In the future we may wish to > reuse it for network cards and other emulated devices too! > > Perhaps the error injection "engine" (the core blkdebug code) can be > extracted and reused? I think VMs are a great way to test all different error paths, just not those specific to storage so if we could make this generic that would be great. I also elaborated about this a bit in one of my other responses, but I'll reiterate here a bit too. If we could design a suitable callback interface utilizing qapi I think we could move the state machine/logic out of QEMU all together. So that the test code could contain this logic which would allow all types of behavior that we haven't even thought of to exist outside of QEMU and not require changes to QEMU to exploit. -Tony
