qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices
Date: Tue, 18 Dec 2012 12:40:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

Il 18/12/2012 10:49, Michael S. Tsirkin ha scritto:
>>>> +/* Device-specific reset through virtio config space.
>>>> + * Reset virtio config and backend child devices if any.
>>>> + */
>>>> +void virtio_config_reset(VirtIODevice *vdev)
>>>> +{
>>>> +    qdev_reset_all(vdev->binding_opaque);
>>>> +}
>>>
>>> Yes, I had understood.  As I said, this is the wrong direction.
>>> Resetting happens from vdev->binding_opaque, it can just do
>>> qdev_reset_all(myself).
> 
> It can but it's the wrong thing for transport to know about.

The transport provides an implementation of dc->reset, not virtio.c
(e.g. virtio_pci_reset).  Sure it knows what the effect of
qdev_reset_all are on itself.

> Let PCI worry about PCI things. This is not
> a transport specific thing so belongs in virtio.c

This _is_ a transport specific thing.  Sure it will reset the virtio
device (virtio_reset), but it will also reset things such as MSI-X
vectors and VIRTIO_PCI_FLAG_BUS_MASTER_BUG.  It doesn't belong in virtio.c.

>> ... besides, this only works if the reset callback of
>> vdev->binding_opaque remembers to call virtio_reset (in the s390
>> bindings, it doesn't and this series fixes it).
> 
> That's a separate bug I think.

Yes, I agree.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]