lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 15 Jul 2020 19:09:41 +0800
From:   "Zhu, Lingshan" <lingshan.zhu@...el.com>
To:     Jason Wang <jasowang@...hat.com>, mst@...hat.com,
        alex.williamson@...hat.com, pbonzini@...hat.com,
        sean.j.christopherson@...el.com, wanpengli@...cent.com
Cc:     virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org,
        netdev@...r.kernel.org, dan.daly@...el.com
Subject: Re: [PATCH 3/7] vhost_vdpa: implement IRQ offloading functions in
 vhost_vdpa


On 7/15/2020 5:42 PM, Jason Wang wrote:
>
> On 2020/7/15 下午5:20, Zhu, Lingshan wrote:
>>>>>
>>>>> I meant something like:
>>>>>
>>>>> unregister();
>>>>> vq->call_ctx.producer.token = ctx;
>>>>> register();
>>>> This is what we are doing now, or I must missed somethig:
>>>> if (ctx && ctx != token) {
>>>>     irq_bypass_unregister_producer(&vq->call_ctx.producer);
>>>>     vq->call_ctx.producer.token = ctx;
>>>>     irq_bypass_register_producer(&vq->call_ctx.producer);
>>>>
>>>> }
>>>>
>>>> It just unregister and register.
>>>
>>>
>>> I meant there's probably no need for the check and another check and 
>>> unregister before. The whole function is as simple as I suggested 
>>> above.
>>>
>>> Thanks
>> IMHO we still need the checks, this function handles three cases:
>> (1)if the ctx == token, we do nothing. For this unregister and 
>> register can work, but waste of time.
>
>
> But we have a more simple code and we don't care about the performance 
> here since the operations is rare.
>
>
>> (2)if token exists but ctx is NULL, this means user space issued an 
>> unbind, so we need to only unregister the producer.
>
>
> Note that the register/unregister have a graceful check of whether or 
> not there's a token.
>
>
>> (3)if ctx exists and ctx!=token, this means there is a new ctx, we 
>> need to update producer by unregister and register.
>>
>> I think we can not simply handle all these cases by "unregister and 
>> register".
>
>
> So it looks to me the functions are equivalent.
>
> Thanks
Sounds reasonable, thanks!
>
>
>>
>> Thanks,
>> BR
>> Zhu Lingshan
>

Powered by blists - more mailing lists