qemu-devel
[Top][All Lists]
Advanced

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

Re: virtio: why no full reset on virtio_set_status 0 ?


From: Claudio Fontana
Subject: Re: virtio: why no full reset on virtio_set_status 0 ?
Date: Fri, 29 Jul 2022 16:00:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0

On 7/29/22 15:21, Alex Bennée wrote:
> 
> Claudio Fontana <cfontana@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





reply via email to

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