Il 12/12/2012 22:32, Michael S. Tsirkin ha scritto: > > i.e. just implement a method on the bus to do the hard-reset, and let > > generic infrastructure call it. > > I dislike this approach. > A specific function call is easier to follow.
"I dislike reading documentation, so I prefer to have ugly code than good documentation". The right way to fix it is to document the reset semantics, and use them. > > No, because that would also reset the virtio-pci bits (ioeventfd etc.) which > > virtio-scsi has no business with. What I could do is to call > > qbus_reset_all, > > but it makes no sense to me when there is a generic solution. > > > > The virtio reset just resets virtio registers and stops DMA > and interrupts. That is all. If it's not clear from spec > we should make it clear. > > The fact that virtio scsi needs to do something special > with qdev or whatever for this to happen is it's own business. Same for virtio-console. If you don't call qemu_chr_fe_close, the char device layer ends up calling chr_read in virtio-console.c which ultimately does DMA. It's how most qdev buses work. The bus callbacks includes a parent->child interface to submit request and a child->parent interface to DMA. If you do not reset the children, you do not reset DMA. Period. > E.g. -net does it differently it checks state > before processing packets. > Generic virtio core does not care. Generic qdev core cares. virtio is a qdev device and it should use services provided by the generic framework, as much as you hate it. Paolo