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


Reply via email to