[v4] net/gve: check driver compatibility
Ferruh Yigit
ferruh.yigit at amd.com
Tue May 23 12:20:17 CEST 2023
On 5/22/2023 4:45 PM, Rushil Gupta wrote:
> 1. This is the excerpt from the google's virtual nic spec:
> "In addition to the device-owned register file, vector table, and
> doorbells, the gVNIC device uses *DMA* (which in most cases amounts to
> ordinary memory access by host software since we're dealing with a
> virtual device, but guests must assume the device could be backed by
> actual hardware) to access physical memory. The following are all
> located in physical memory: Admin queue - 4096-byte command queue used
> for configuring gVNIC.
> Some commands require an additional dma memory region to be passed to
> the device. These memory regions are allocated to execute the command
> and freed when the command completes."
> The calloc by default doesn't allow memory to be shared between the dpdk
> process and hypervisor (where virtual device lives); so that's the
> reason it doesn't work.
>
Thanks Rushil for the info.
So, I expect gVNIC requires physical address to be passed in the admin
command, as 'driver_info_mem.iova'.
What confuses me is, latest version passes another virtual address
'driver_info' ('driver_info_mem->addr').
> 2. I also have a query: RHEL8 compilation in ci/Intel-compilation
> context fails due to; is this because of if `not is_linux`
>
> meson.build:67:0: ERROR: Include dir lib/eal/linux/include does not exist.
>
This error shouldn't be related with `not is_linux`, but I am not sure
about its root case, if it still exists in next version we can
communicate with CI team for details. For now I assume this is an
infrastructure issue.
> Passes:
> http://patchwork.dpdk.org/project/dpdk/patch/20230508191552.104540-1-rushilg@google.com/ <http://patchwork.dpdk.org/project/dpdk/patch/20230508191552.104540-1-rushilg@google.com/>
>
> Fails:
> http://patchwork.dpdk.org/project/dpdk/patch/20230519204618.1507956-1-rushilg@google.com/ <http://patchwork.dpdk.org/project/dpdk/patch/20230519204618.1507956-1-rushilg@google.com/>
>
>
> On Mon, May 22, 2023 at 1:52 AM Ferruh Yigit <ferruh.yigit at amd.com
> <mailto:ferruh.yigit at amd.com>> wrote:
>
> On 5/19/2023 9:46 PM, Rushil Gupta wrote:
> > +static int
> > +gve_verify_driver_compatibility(struct gve_priv *priv)
> > +{
> > + const struct rte_memzone *driver_info_mem;
> > + struct gve_driver_info *driver_info;
> > + int err;
> > +
> > + driver_info_mem =
> rte_memzone_reserve_aligned("verify_driver_compatibility",
> > + sizeof(struct gve_driver_info),
> > + rte_socket_id(),
> > + RTE_MEMZONE_IOVA_CONTIG, PAGE_SIZE);
> > +
> > + if (driver_info_mem == NULL) {
> > + PMD_DRV_LOG(ERR,
> > + "Could not alloc memzone for driver
> compatibility");
> > + return -ENOMEM;
> > + }
> > + driver_info = (struct gve_driver_info *)driver_info_mem->addr;
> > +
> > + *driver_info = (struct gve_driver_info) {
> > + .os_type = 5, /* DPDK */
> > + .driver_major = GVE_VERSION_MAJOR,
> > + .driver_minor = GVE_VERSION_MINOR,
> > + .driver_sub = GVE_VERSION_SUB,
> > + .os_version_major = cpu_to_be32(DPDK_VERSION_MAJOR),
> > + .os_version_minor = cpu_to_be32(DPDK_VERSION_MINOR),
> > + .os_version_sub = cpu_to_be32(DPDK_VERSION_SUB),
> > + .driver_capability_flags = {
> > + cpu_to_be64(GVE_DRIVER_CAPABILITY_FLAGS1),
> > + cpu_to_be64(GVE_DRIVER_CAPABILITY_FLAGS2),
> > + cpu_to_be64(GVE_DRIVER_CAPABILITY_FLAGS3),
> > + cpu_to_be64(GVE_DRIVER_CAPABILITY_FLAGS4),
> > + },
> > + };
> > +
> > + populate_driver_version_strings((char
> *)driver_info->os_version_str1,
> > + (char *)driver_info->os_version_str2);
> > +
> > + err = gve_adminq_verify_driver_compatibility(priv,
> > + sizeof(struct gve_driver_info),
> (dma_addr_t)driver_info);
>
> Back to previous discussion, other commands pass physical address to the
> admin command, but this pass virtual address.
> To follow the same semantic, shouldn't above be 'driver_info_mem.iova'?
>
> I asked before but not able to get an answer, what is the memory type
> requirement for device?
> Why virtual address obtained via 'calloc()' is not working, but virtual
> address from hugepages are working?
>
More information about the dev
mailing list