Claudio Fontana <cfont...@suse.de> writes:
> On 7/29/22 12:13, Michael S. Tsirkin wrote:
>> On Fri, Jul 29, 2022 at 11:46:05AM +0200, Claudio Fontana wrote:
>>>>> @@ -2025,7 +2031,6 @@ void virtio_reset(void *opaque)
>>>>> VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
>>>>> int i;
>>>>>
>>>>> - virtio_set_status(vdev, 0);
>>>>> if (current_cpu) {
>>>>> /* Guest initiated reset */
>>>>> vdev->device_endian = virtio_current_cpu_endian();
>>>>> --
>>>>> 2.26.2
>>>>
>>>> As you say this is incomplete ... bout could you share a bit more
>>>> of what issue does this address?
>>>>
>>>
>>> Hi, the problem I am trying to address is a segfault in OVS/dpdk that looks
>>> like this:
>>
>> Sorry I was not clear. What I mean is, you don't yet know why does removing
>> virtio_set_status call here prevent the crash in ovs, do you?
>>
>
> I have no idea. Trying to collect logs to figure things out, but as
> mentioned the logs easily hide the issue.
> Likely there is just more to study here.
Given the OVS is going off on a NULL ptr deref could it just be it's not
handling the disabling/reenabling of the virtqueues as you pause and
restart properly? I could certainly imagine a backend jumping the gun to
read a queue going very wrong if the current queue state is disabled.
--
Alex Bennée
