On 7/29/22 15:21, Alex Bennée wrote:
>
> 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.
>
In this case both the ovs buf_addr and buf_iova are NULL, which is a nice case
as they are more detectable,
however I also have segfaults where the addresses are just garbage.
I wonder whether it's possible that given the fact that the guest is going away
without notification (SIGKILL),
as the guest driver resets the device and communicates with QEMU, QEMU adapts
the state without notifying ovs,
so ovs happily tries to dequeue data from memory that isn't there. But I am
just guessing.
I am still studying the qemu vhost user side and ovs/dpdk side to try to
understand how this whole thing works.
Thanks,
CLaudio
