[Cyborg][Ironic][Nova][Neutron][TripleO][Cinder] accelerators management

Nadathur, Sundar sundar.nadathur at intel.com
Mon Jan 13 18:26:23 UTC 2020



> -----Original Message-----
> From: Jeremy Stanley <fungi at yuggoth.org>
> Sent: Monday, January 13, 2020 8:54 AM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: [Cyborg][Ironic][Nova][Neutron][TripleO][Cinder] accelerators
> management
> 
> On 2020-01-13 07:16:30 -0800 (-0800), Dan Smith wrote:
> [...]
> > What does this matter though? If you're talking about firmware for an
> > FPGA card, that's what you need to know in order to apply the correct
> > firmware to it, independent of whatever application-level bitstream is
> > going to go in there right?
> [...]
> > Either way, I'm not sure how the firmware for accelerator cards is any
> > different from the firmware for other devices on the system. Maybe the
> > confusion is just that Cyborg does "programming" which seems similar
> > to "updating firmware"?
> [...]
> 
> FPGA configuration is a compiled binary blob written into non-volatile
> memory through a hardware interface. These similarities to firmware also
> result in many people actually calling it "firmware" even though, you're right,
> technically it's a mapping of gate interconnections and not really firmware in
> the conventional sense. 

+1

> I wouldn't be surprised, though, if there *are* NFV-related cases where the
> users of the virtual machines into which some network hardware is mapped
> need access to alter parts of, say, an interface controller's firmware. The Linux
> kernel has for years incorporated features to write or rewrite firmware and
> other microcode for certain devices at boot time for similar reasons, after all.

This aspect does come up for discussion a lot. Generally, operators and device vendors get alarmed at the prospect of letting a user/VNF/instance program an image/bitstream into a device directly -- we wouldn't know what image it is, etc. Cyborg doesn't support that. But Cyborg could program an image/bitstream on behalf of the user/VNF.

That said, the VNF or VM (in  a non-networking context) can configure a device by reading from registers/DDR on the card or writing to them. They can be handled using standard access permissions, Linux capabilities, etc. For example, the VM may memory-map a region of the device's address space using the mmap system call, and that access can be controlled. 

> --
> Jeremy Stanley

Regards,
Sundar



More information about the openstack-discuss mailing list