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]
Date:   Fri, 26 Oct 2018 16:04:44 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Sunil Kovvuri <sunil.kovvuri@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        linux-soc@...r.kernel.org, Sunil Goutham <sgoutham@...vell.com>
Subject: Re: [PATCH v2 00/17] octeontx2-af: NPC parser and NIX blocks initialization

On 10/26/18, Sunil Kovvuri <sunil.kovvuri@...il.com> wrote:
> On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann <arnd@...db.de> wrote:
>>
>> I see this has been applied, but I'd still like to understand better how
>> the
>> configuration interface is expected to work once the driver is complete.
>>
>> In particular, so far the interfaces all assume that configuration is
>> done through the mailbox between PCI devices, which could be done
>> from a virtual machine kernel with access to PCI, or through the use
>> of VFIO from a user application.
>>
>> Is that the only method of configuring it that you support, or will there
>> also be a devlink based interface or something like that to configure
>> the aspects of a virtual device that should not be accessible to the
>> VF itself?
>>
>
>
> As of now it's only mbox based configuration that is supported.

Ok, thanks for the clarification.

Does this mean that you intend to have user space tools that use
the mbox based interface on VFIO devices to perform configuration
for virtual network devices, or just that the configuration interface
is something that needs to be designed later?

I fear that setting a precedent of using the mbox for user-level
configuration management would mean that we would have to
treat each of these interfaces as an ABI, which in turn requires
much deeper review as well as raising the fundamental question
on how this should be done across drivers. The mailbox interface
seem inherently nonportable to other hardware here, which is
a significant downside.

       Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ