Am 21.11.2019 um 11:30 hat Stefan Hajnoczi geschrieben: > On Thu, Nov 14, 2019 at 09:47:48AM -0600, Tony Asleson wrote: > > On 9/20/19 12:28 PM, Tony Asleson wrote: > > > 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. > > > > > > > I would like to get some additional clarification on this point. Should > > I be investing more time integrating my proposed functionality into > > blkdebug or other? > > > > Sorry for the long response time, got sidetracked with other stuff. > > blkdebug can inject EIO when a specific LBA is accessed. Is that > enough for what you want to do? Then you can reuse and maybe extend > blkdebug.
And if we need something more device specific, maybe a common core can be extracted that can be used by both blkdebug and the devices. All of the logic of managing error injection rules and checking whether something needs to be done at the current event should be common between both. Kevin
signature.asc
Description: PGP signature
