linux-kernel - RE: [PATCH v2 4/4] vdpa/octeon_ep: add interrupt handler for virtio crypto device

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PH0PR18MB4425117E2D92C46980DBF4D1D93C2@PH0PR18MB4425.namprd18.prod.outlook.com>
Date: Mon, 9 Dec 2024 09:29:55 +0000
From: Shijith Thotton <sthotton@...vell.com>
To: Jason Wang <jasowang@...hat.com>
CC: "virtualization@...ts.linux.dev" <virtualization@...ts.linux.dev>,
        "mst@...hat.com" <mst@...hat.com>,
        "dan.carpenter@...aro.org"
	<dan.carpenter@...aro.org>,
        Srujana Challa <schalla@...vell.com>,
        Vamsi
 Krishna Attunuru <vattunuru@...vell.com>,
        Nithin Kumar Dabilpuram
	<ndabilpuram@...vell.com>,
        Jerin Jacob <jerinj@...vell.com>,
        Xuan Zhuo
	<xuanzhuo@...ux.alibaba.com>,
        Eugenio Pérez
	<eperezma@...hat.com>,
        Satha Koteswara Rao Kottidi <skoteshwar@...vell.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 4/4] vdpa/octeon_ep: add interrupt handler for virtio
 crypto device

>>> Introduced an interrupt handler for the virtio crypto device, as its
>>> queue usage differs from that of network devices. While virtio network
>>> device receives packets only on even-indexed queues, virtio crypto
>>> device utilize all available queues for processing data.
>>
>>I'm not sure I will get here but the recent kernel depends heavily on
>>the tx interrupt for skb post processing as well.
>>
>
>Currently, the device does not support TX interrupts.
>This behavior may change in the future.
>
>>>
>>> Signed-off-by: Shijith Thotton <sthotton@...vell.com>
>>> ---
>>>  drivers/vdpa/octeon_ep/octep_vdpa_main.c | 52
>>+++++++++++++++++++++++-
>>>  1 file changed, 50 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/vdpa/octeon_ep/octep_vdpa_main.c
>>b/drivers/vdpa/octeon_ep/octep_vdpa_main.c
>>> index d674b9678428..1bdf7a8111ce 100644
>>> --- a/drivers/vdpa/octeon_ep/octep_vdpa_main.c
>>> +++ b/drivers/vdpa/octeon_ep/octep_vdpa_main.c
>>> @@ -44,7 +44,35 @@ static struct octep_hw *vdpa_to_octep_hw(struct
>>vdpa_device *vdpa_dev)
>>>         return oct_vdpa->oct_hw;
>>>  }
>>>
>>> -static irqreturn_t octep_vdpa_intr_handler(int irq, void *data)
>>> +static irqreturn_t octep_vdpa_crypto_irq_handler(int irq, void *data)
>>> +{
>>> +       struct octep_hw *oct_hw = data;
>>> +       int i;
>>> +
>>> +       /* Each device interrupt (nb_irqs) maps to specific receive rings
>>> +        * (nr_vring) in a round-robin fashion.
>>> +        *
>>> +        * For example, if nb_irqs = 8 and nr_vring = 64:
>>> +        * 0 -> 0, 8, 16, 24, 32, 40, 48, 56;
>>> +        * 1 -> 1, 9, 17, 25, 33, 41, 49, 57;
>>> +        * ...
>>> +        * 7 -> 7, 15, 23, 31, 39, 47, 55, 63;
>>> +        */
>>
>>So this algorithm is mandated by the device?
>>
>
>Yes.
>
>>I'm asking since it's better to not have type specific policy in the
>>vDPA layer. As the behaviour of the guest might change.
>>
>
>This logic is closely linked to the device's behavior. I will check if it is
>possible to avoid the device-type-based logic.
>

I will drop this patch and update the interrupt handler in the first patch of
the series to manage both devices.

>>For example, for networking devices, in the future we may switch to
>>use a single interrupt/NAPI to handle both RX and TX. And note that
>>this is only the behaviour of Linux, not other drivers like DPDK or
>>other OSes.
>>
>>> +       for (i = irq - oct_hw->irqs[0]; i < oct_hw->nr_vring; i += oct_hw-
>>nb_irqs)
>>{
>>> +               if (ioread32(oct_hw->vqs[i].cb_notify_addr)) {
>>> +                       /* Acknowledge the per ring notification to the device */
>>> +                       iowrite32(0, oct_hw->vqs[i].cb_notify_addr);
>>> +
>>> +                       if (likely(oct_hw->vqs[i].cb.callback))
>>> +                               oct_hw->vqs[i].cb.callback(oct_hw->vqs[i].cb.private);
>>> +                       break;
>>> +               }
>>> +       }
>>