From 27d551c00d5458d1deda33508dab7453959ca2c6 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Fri, 11 Sep 2020 13:12:11 +0200 Subject: meson: clean up build_by_default Build all executables by default except for the known-broken ones. This also allows running qemu-iotests without manually building socket_scm_helper. Reported-by: Max Reitz Tested-by: Max Reitz Signed-off-by: Paolo Bonzini --- docs/devel/build-system.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'docs') diff --git a/docs/devel/build-system.rst b/docs/devel/build-system.rst index 08e85c69e1..2ee368fad6 100644 --- a/docs/devel/build-system.rst +++ b/docs/devel/build-system.rst @@ -193,6 +193,11 @@ compilation as possible. The Meson "sourceset" functionality is used to list the files and their dependency on various configuration symbols. +All executables are built by default, except for some `contrib/` +binaries that are known to fail to build on some platforms (for example +32-bit or big-endian platforms). Tests are also built by default, +though that might change in the future. + Various subsystems that are common to both tools and emulators have their own sourceset, for example `block_ss` for the block device subsystem, `chardev_ss` for the character device subsystem, etc. These sourcesets -- cgit v1.2.3-55-g7522 From b21aa7e01eb82f94ccdd7afdbe299a242d215272 Mon Sep 17 00:00:00 2001 From: Igor Mammedov Date: Fri, 11 Sep 2020 04:44:08 -0400 Subject: numa: drop support for '-numa node' (without memory specified) it was deprecated since 4.1 commit 4bb4a2732e (numa: deprecate implict memory distribution between nodes) Users of existing VMs, wishing to preserve the same RAM distribution, should configure it explicitly using ``-numa node,memdev`` options. Current RAM distribution can be retrieved using HMP command `info numa` and if separate memory devices (pc|nv-dimm) are present use `info memory-device` and subtract device memory from output of `info numa`. Signed-off-by: Igor Mammedov Message-Id: <20200911084410.788171-2-imammedo@redhat.com> Signed-off-by: Paolo Bonzini --- docs/system/deprecated.rst | 23 +++++++++++-------- hw/core/machine.c | 1 - hw/core/numa.c | 55 ---------------------------------------------- hw/i386/pc_piix.c | 1 - hw/i386/pc_q35.c | 1 - hw/ppc/spapr.c | 1 - include/hw/boards.h | 2 -- include/sysemu/numa.h | 4 ---- 8 files changed, 14 insertions(+), 74 deletions(-) (limited to 'docs') diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 5326141cee..827482a8f7 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -92,15 +92,6 @@ error in the future. The ``-realtime mlock=on|off`` argument has been replaced by the ``-overcommit mem-lock=on|off`` argument. -``-numa`` node (without memory specified) (since 4.1) -''''''''''''''''''''''''''''''''''''''''''''''''''''' - -Splitting RAM by default between NUMA nodes has the same issues as ``mem`` -parameter described above with the difference that the role of the user plays -QEMU using implicit generic or board specific splitting rule. -Use ``memdev`` with *memory-backend-ram* backend or ``mem`` (if -it's supported by used machine type) to define mapping explicitly instead. - ``-mem-path`` fallback to RAM (since 4.1) ''''''''''''''''''''''''''''''''''''''''' @@ -612,6 +603,20 @@ error when ``-u`` is not used. Command line options -------------------- +``-numa`` node (without memory specified) (removed 5.2) +''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +Splitting RAM by default between NUMA nodes had the same issues as ``mem`` +parameter with the difference that the role of the user plays QEMU using +implicit generic or board specific splitting rule. +Use ``memdev`` with *memory-backend-ram* backend or ``mem`` (if +it's supported by used machine type) to define mapping explictly instead. +Users of existing VMs, wishing to preserve the same RAM distribution, should +configure it explicitly using ``-numa node,memdev`` options. Current RAM +distribution can be retrieved using HMP command ``info numa`` and if separate +memory devices (pc|nv-dimm) are present use ``info memory-device`` and subtract +device memory from output of ``info numa``. + ``-numa node,mem=``\ *size* (removed in 5.1) '''''''''''''''''''''''''''''''''''''''''''' diff --git a/hw/core/machine.c b/hw/core/machine.c index d7f4a0d259..7e2f4ec08e 100644 --- a/hw/core/machine.c +++ b/hw/core/machine.c @@ -790,7 +790,6 @@ static void machine_class_init(ObjectClass *oc, void *data) * On Linux, each node's border has to be 8MB aligned */ mc->numa_mem_align_shift = 23; - mc->numa_auto_assign_ram = numa_default_auto_assign_ram; object_class_property_add_str(oc, "kernel", machine_get_kernel, machine_set_kernel); diff --git a/hw/core/numa.c b/hw/core/numa.c index f9593ec716..706c1e84c6 100644 --- a/hw/core/numa.c +++ b/hw/core/numa.c @@ -611,42 +611,6 @@ static void complete_init_numa_distance(MachineState *ms) } } -void numa_legacy_auto_assign_ram(MachineClass *mc, NodeInfo *nodes, - int nb_nodes, ram_addr_t size) -{ - int i; - uint64_t usedmem = 0; - - /* Align each node according to the alignment - * requirements of the machine class - */ - - for (i = 0; i < nb_nodes - 1; i++) { - nodes[i].node_mem = (size / nb_nodes) & - ~((1 << mc->numa_mem_align_shift) - 1); - usedmem += nodes[i].node_mem; - } - nodes[i].node_mem = size - usedmem; -} - -void numa_default_auto_assign_ram(MachineClass *mc, NodeInfo *nodes, - int nb_nodes, ram_addr_t size) -{ - int i; - uint64_t usedmem = 0, node_mem; - uint64_t granularity = size / nb_nodes; - uint64_t propagate = 0; - - for (i = 0; i < nb_nodes - 1; i++) { - node_mem = (granularity + propagate) & - ~((1 << mc->numa_mem_align_shift) - 1); - propagate = granularity + propagate - node_mem; - nodes[i].node_mem = node_mem; - usedmem += node_mem; - } - nodes[i].node_mem = size - usedmem; -} - static void numa_init_memdev_container(MachineState *ms, MemoryRegion *ram) { int i; @@ -717,25 +681,6 @@ void numa_complete_configuration(MachineState *ms) ms->numa_state->num_nodes = MAX_NODES; } - /* If no memory size is given for any node, assume the default case - * and distribute the available memory equally across all nodes - */ - for (i = 0; i < ms->numa_state->num_nodes; i++) { - if (numa_info[i].node_mem != 0) { - break; - } - } - if (i == ms->numa_state->num_nodes) { - assert(mc->numa_auto_assign_ram); - mc->numa_auto_assign_ram(mc, numa_info, - ms->numa_state->num_nodes, ram_size); - if (!qtest_enabled()) { - warn_report("Default splitting of RAM between nodes is deprecated," - " Use '-numa node,memdev' to explictly define RAM" - " allocation per node"); - } - } - numa_total = 0; for (i = 0; i < ms->numa_state->num_nodes; i++) { numa_total += numa_info[i].node_mem; diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 2d8413a0ce..32c5d95762 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -565,7 +565,6 @@ static void pc_i440fx_2_9_machine_options(MachineClass *m) pc_i440fx_2_10_machine_options(m); compat_props_add(m->compat_props, hw_compat_2_9, hw_compat_2_9_len); compat_props_add(m->compat_props, pc_compat_2_9, pc_compat_2_9_len); - m->numa_auto_assign_ram = numa_legacy_auto_assign_ram; } DEFINE_I440FX_MACHINE(v2_9, "pc-i440fx-2.9", NULL, diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c index e1c415f57d..e14d1446be 100644 --- a/hw/i386/pc_q35.c +++ b/hw/i386/pc_q35.c @@ -494,7 +494,6 @@ static void pc_q35_2_10_machine_options(MachineClass *m) pc_q35_2_11_machine_options(m); compat_props_add(m->compat_props, hw_compat_2_10, hw_compat_2_10_len); compat_props_add(m->compat_props, pc_compat_2_10, pc_compat_2_10_len); - m->numa_auto_assign_ram = numa_legacy_auto_assign_ram; m->auto_enable_numa_with_memhp = false; } diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index cbcd93b406..2db810f73a 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -4734,7 +4734,6 @@ static void spapr_machine_2_9_class_options(MachineClass *mc) spapr_machine_2_10_class_options(mc); compat_props_add(mc->compat_props, hw_compat_2_9, hw_compat_2_9_len); compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat)); - mc->numa_auto_assign_ram = numa_legacy_auto_assign_ram; smc->pre_2_10_has_unused_icps = true; smc->resize_hpt_default = SPAPR_RESIZE_HPT_DISABLED; } diff --git a/include/hw/boards.h b/include/hw/boards.h index 482d2833f6..bf53e8a16e 100644 --- a/include/hw/boards.h +++ b/include/hw/boards.h @@ -202,8 +202,6 @@ struct MachineClass { strList *allowed_dynamic_sysbus_devices; bool auto_enable_numa_with_memhp; bool auto_enable_numa_with_memdev; - void (*numa_auto_assign_ram)(MachineClass *mc, NodeInfo *nodes, - int nb_nodes, ram_addr_t size); bool ignore_boot_device_suffixes; bool smbus_no_migration_support; bool nvdimm_supported; diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h index ad58ee88f7..4173ef2afa 100644 --- a/include/sysemu/numa.h +++ b/include/sysemu/numa.h @@ -106,10 +106,6 @@ void parse_numa_hmat_cache(MachineState *ms, NumaHmatCacheOptions *node, void numa_complete_configuration(MachineState *ms); void query_numa_node_mem(NumaNodeMem node_mem[], MachineState *ms); extern QemuOptsList qemu_numa_opts; -void numa_legacy_auto_assign_ram(MachineClass *mc, NodeInfo *nodes, - int nb_nodes, ram_addr_t size); -void numa_default_auto_assign_ram(MachineClass *mc, NodeInfo *nodes, - int nb_nodes, ram_addr_t size); void numa_cpu_pre_plug(const struct CPUArchId *slot, DeviceState *dev, Error **errp); bool numa_uses_legacy_mem(void); -- cgit v1.2.3-55-g7522 From c01f250cb86cde926dbee4337317ccd58261fa1b Mon Sep 17 00:00:00 2001 From: Igor Mammedov Date: Fri, 11 Sep 2020 04:44:09 -0400 Subject: doc: Cleanup "'-mem-path' fallback to RAM" deprecation text it was actually removed in 5.0, commit 68a86dc15c (numa: remove deprecated -mem-path fallback to anonymous RAM) clean up forgotten remnants in docs. Signed-off-by: Igor Mammedov Message-Id: <20200911084410.788171-3-imammedo@redhat.com> Signed-off-by: Paolo Bonzini --- docs/system/deprecated.rst | 43 +++++++++++++++++++++---------------------- 1 file changed, 21 insertions(+), 22 deletions(-) (limited to 'docs') diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 827482a8f7..716f6aa315 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -92,17 +92,6 @@ error in the future. The ``-realtime mlock=on|off`` argument has been replaced by the ``-overcommit mem-lock=on|off`` argument. -``-mem-path`` fallback to RAM (since 4.1) -''''''''''''''''''''''''''''''''''''''''' - -Currently if guest RAM allocation from file pointed by ``mem-path`` -fails, QEMU falls back to allocating from RAM, which might result -in unpredictable behavior since the backing file specified by the user -is ignored. In the future, users will be responsible for making sure -the backing storage specified with ``-mem-path`` can actually provide -the guest RAM configured with ``-m`` and QEMU will fail to start up if -RAM allocation is unsuccessful. - RISC-V ``-bios`` (since 5.1) '''''''''''''''''''''''''''' @@ -603,6 +592,19 @@ error when ``-u`` is not used. Command line options -------------------- +``-smp`` (invalid topologies) (removed 5.2) +''''''''''''''''''''''''''''''''''''''''''' + +CPU topology properties should describe whole machine topology including +possible CPUs. + +However, historically it was possible to start QEMU with an incorrect topology +where *n* <= *sockets* * *cores* * *threads* < *maxcpus*, +which could lead to an incorrect topology enumeration by the guest. +Support for invalid topologies is removed, the user must ensure +topologies described with -smp include all possible cpus, i.e. +*sockets* * *cores* * *threads* = *maxcpus*. + ``-numa`` node (without memory specified) (removed 5.2) ''''''''''''''''''''''''''''''''''''''''''''''''''''''' @@ -634,18 +636,15 @@ New machine versions (since 5.1) will not accept the option but it will still work with old machine types. User can check the QAPI schema to see if the legacy option is supported by looking at MachineInfo::numa-mem-supported property. -``-smp`` (invalid topologies) (removed 5.2) -''''''''''''''''''''''''''''''''''''''''''' - -CPU topology properties should describe whole machine topology including -possible CPUs. +``-mem-path`` fallback to RAM (removed in 5.0) +'''''''''''''''''''''''''''''''''''''''''''''' -However, historically it was possible to start QEMU with an incorrect topology -where *n* <= *sockets* * *cores* * *threads* < *maxcpus*, -which could lead to an incorrect topology enumeration by the guest. -Support for invalid topologies is removed, the user must ensure -topologies described with -smp include all possible cpus, i.e. -*sockets* * *cores* * *threads* = *maxcpus*. +If guest RAM allocation from file pointed by ``mem-path`` failed, +QEMU was falling back to allocating from RAM, which might have resulted +in unpredictable behavior since the backing file specified by the user +as ignored. Currently, users are responsible for making sure the backing storage +specified with ``-mem-path`` can actually provide the guest RAM configured with +``-m`` and QEMU fails to start up if RAM allocation is unsuccessful. Block devices ------------- -- cgit v1.2.3-55-g7522 From b057f0961b10a5b052a81047d887a95ce206e00c Mon Sep 17 00:00:00 2001 From: Igor Mammedov Date: Fri, 11 Sep 2020 09:32:02 -0400 Subject: smp: drop support for deprecated (invalid topologies) it's was deprecated since 3.1 Support for invalid topologies is removed, the user must ensure that topologies described with -smp include all possible cpus, i.e. (sockets * cores * threads) == maxcpus or QEMU will exit with error. Signed-off-by: Igor Mammedov Acked-by: Message-Id: <20200911133202.938754-1-imammedo@redhat.com> Signed-off-by: Paolo Bonzini --- docs/system/deprecated.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'docs') diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 716f6aa315..da862201ba 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -646,6 +646,19 @@ as ignored. Currently, users are responsible for making sure the backing storage specified with ``-mem-path`` can actually provide the guest RAM configured with ``-m`` and QEMU fails to start up if RAM allocation is unsuccessful. +``-smp`` (invalid topologies) (removed 5.2) +''''''''''''''''''''''''''''''''''''''''''' + +CPU topology properties should describe whole machine topology including +possible CPUs. + +However, historically it was possible to start QEMU with an incorrect topology +where *n* <= *sockets* * *cores* * *threads* < *maxcpus*, +which could lead to an incorrect topology enumeration by the guest. +Support for invalid topologies is removed, the user must ensure +topologies described with -smp include all possible cpus, i.e. +*sockets* * *cores* * *threads* = *maxcpus*. + Block devices ------------- -- cgit v1.2.3-55-g7522 From cd442a45db60a1a72fcf980c24bd1227f13f8a87 Mon Sep 17 00:00:00 2001 From: Eduardo Habkost Date: Thu, 10 Sep 2020 18:15:25 -0400 Subject: docs: Create docs/devel/qom.rst Signed-off-by: Eduardo Habkost Message-Id: <20200910221526.10041-9-ehabkost@redhat.com> Signed-off-by: Paolo Bonzini --- docs/devel/index.rst | 1 + docs/devel/qom.rst | 5 +++++ 2 files changed, 6 insertions(+) create mode 100644 docs/devel/qom.rst (limited to 'docs') diff --git a/docs/devel/index.rst b/docs/devel/index.rst index 04773ce076..c34b43ec28 100644 --- a/docs/devel/index.rst +++ b/docs/devel/index.rst @@ -31,3 +31,4 @@ Contents: reset s390-dasd-ipl clocks + qom diff --git a/docs/devel/qom.rst b/docs/devel/qom.rst new file mode 100644 index 0000000000..dc5be79a4a --- /dev/null +++ b/docs/devel/qom.rst @@ -0,0 +1,5 @@ +=========================== +The QEMU Object Model (QOM) +=========================== + +.. kernel-doc:: include/qom/object.h -- cgit v1.2.3-55-g7522 From 9cb54b18e8b9814899adb7a58a6e561eae3b1913 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Wed, 23 Sep 2020 12:21:39 -0400 Subject: docs: Move object.h overview doc comment to qom.rst Move the whole contents of the overview doc comment from object.h to qom.rst. This makes the documentation source easier to read and edit, and also solves the backslash escaping issue at the typecasting macro examples. Signed-off-by: Eduardo Habkost Message-Id: <20200910221526.10041-10-ehabkost@redhat.com> Signed-off-by: Paolo Bonzini --- docs/devel/qom.rst | 373 ++++++++++++++++++++++++++++++++++++++++++++++++++ include/qom/object.h | 377 --------------------------------------------------- 2 files changed, 373 insertions(+), 377 deletions(-) (limited to 'docs') diff --git a/docs/devel/qom.rst b/docs/devel/qom.rst index dc5be79a4a..0b943b2a1a 100644 --- a/docs/devel/qom.rst +++ b/docs/devel/qom.rst @@ -2,4 +2,377 @@ The QEMU Object Model (QOM) =========================== +.. highlight:: c + +The QEMU Object Model provides a framework for registering user creatable +types and instantiating objects from those types. QOM provides the following +features: + + - System for dynamically registering types + - Support for single-inheritance of types + - Multiple inheritance of stateless interfaces + +.. code-block:: c + :caption: Creating a minimal type + + #include "qdev.h" + + #define TYPE_MY_DEVICE "my-device" + + // No new virtual functions: we can reuse the typedef for the + // superclass. + typedef DeviceClass MyDeviceClass; + typedef struct MyDevice + { + DeviceState parent; + + int reg0, reg1, reg2; + } MyDevice; + + static const TypeInfo my_device_info = { + .name = TYPE_MY_DEVICE, + .parent = TYPE_DEVICE, + .instance_size = sizeof(MyDevice), + }; + + static void my_device_register_types(void) + { + type_register_static(&my_device_info); + } + + type_init(my_device_register_types) + +In the above example, we create a simple type that is described by #TypeInfo. +#TypeInfo describes information about the type including what it inherits +from, the instance and class size, and constructor/destructor hooks. + +Alternatively several static types could be registered using helper macro +DEFINE_TYPES() + +.. code-block:: c + + static const TypeInfo device_types_info[] = { + { + .name = TYPE_MY_DEVICE_A, + .parent = TYPE_DEVICE, + .instance_size = sizeof(MyDeviceA), + }, + { + .name = TYPE_MY_DEVICE_B, + .parent = TYPE_DEVICE, + .instance_size = sizeof(MyDeviceB), + }, + }; + + DEFINE_TYPES(device_types_info) + +Every type has an #ObjectClass associated with it. #ObjectClass derivatives +are instantiated dynamically but there is only ever one instance for any +given type. The #ObjectClass typically holds a table of function pointers +for the virtual methods implemented by this type. + +Using object_new(), a new #Object derivative will be instantiated. You can +cast an #Object to a subclass (or base-class) type using +object_dynamic_cast(). You typically want to define macro wrappers around +OBJECT_CHECK() and OBJECT_CLASS_CHECK() to make it easier to convert to a +specific type: + +.. code-block:: c + :caption: Typecasting macros + + #define MY_DEVICE_GET_CLASS(obj) \ + OBJECT_GET_CLASS(MyDeviceClass, obj, TYPE_MY_DEVICE) + #define MY_DEVICE_CLASS(klass) \ + OBJECT_CLASS_CHECK(MyDeviceClass, klass, TYPE_MY_DEVICE) + #define MY_DEVICE(obj) \ + OBJECT_CHECK(MyDevice, obj, TYPE_MY_DEVICE) + +Class Initialization +==================== + +Before an object is initialized, the class for the object must be +initialized. There is only one class object for all instance objects +that is created lazily. + +Classes are initialized by first initializing any parent classes (if +necessary). After the parent class object has initialized, it will be +copied into the current class object and any additional storage in the +class object is zero filled. + +The effect of this is that classes automatically inherit any virtual +function pointers that the parent class has already initialized. All +other fields will be zero filled. + +Once all of the parent classes have been initialized, #TypeInfo::class_init +is called to let the class being instantiated provide default initialize for +its virtual functions. Here is how the above example might be modified +to introduce an overridden virtual function: + +.. code-block:: c + :caption: Overriding a virtual function + + #include "qdev.h" + + void my_device_class_init(ObjectClass *klass, void *class_data) + { + DeviceClass *dc = DEVICE_CLASS(klass); + dc->reset = my_device_reset; + } + + static const TypeInfo my_device_info = { + .name = TYPE_MY_DEVICE, + .parent = TYPE_DEVICE, + .instance_size = sizeof(MyDevice), + .class_init = my_device_class_init, + }; + +Introducing new virtual methods requires a class to define its own +struct and to add a .class_size member to the #TypeInfo. Each method +will also have a wrapper function to call it easily: + +.. code-block:: c + :caption: Defining an abstract class + + #include "qdev.h" + + typedef struct MyDeviceClass + { + DeviceClass parent; + + void (*frobnicate) (MyDevice *obj); + } MyDeviceClass; + + static const TypeInfo my_device_info = { + .name = TYPE_MY_DEVICE, + .parent = TYPE_DEVICE, + .instance_size = sizeof(MyDevice), + .abstract = true, // or set a default in my_device_class_init + .class_size = sizeof(MyDeviceClass), + }; + + void my_device_frobnicate(MyDevice *obj) + { + MyDeviceClass *klass = MY_DEVICE_GET_CLASS(obj); + + klass->frobnicate(obj); + } + +Interfaces +========== + +Interfaces allow a limited form of multiple inheritance. Instances are +similar to normal types except for the fact that are only defined by +their classes and never carry any state. As a consequence, a pointer to +an interface instance should always be of incomplete type in order to be +sure it cannot be dereferenced. That is, you should define the +'typedef struct SomethingIf SomethingIf' so that you can pass around +``SomethingIf *si`` arguments, but not define a ``struct SomethingIf { ... }``. +The only things you can validly do with a ``SomethingIf *`` are to pass it as +an argument to a method on its corresponding SomethingIfClass, or to +dynamically cast it to an object that implements the interface. + +Methods +======= + +A method is a function within the namespace scope of +a class. It usually operates on the object instance by passing it as a +strongly-typed first argument. +If it does not operate on an object instance, it is dubbed +class method. + +Methods cannot be overloaded. That is, the #ObjectClass and method name +uniquely identity the function to be called; the signature does not vary +except for trailing varargs. + +Methods are always virtual. Overriding a method in +#TypeInfo.class_init of a subclass leads to any user of the class obtained +via OBJECT_GET_CLASS() accessing the overridden function. +The original function is not automatically invoked. It is the responsibility +of the overriding class to determine whether and when to invoke the method +being overridden. + +To invoke the method being overridden, the preferred solution is to store +the original value in the overriding class before overriding the method. +This corresponds to ``{super,base}.method(...)`` in Java and C# +respectively; this frees the overriding class from hardcoding its parent +class, which someone might choose to change at some point. + +.. code-block:: c + :caption: Overriding a virtual method + + typedef struct MyState MyState; + + typedef void (*MyDoSomething)(MyState *obj); + + typedef struct MyClass { + ObjectClass parent_class; + + MyDoSomething do_something; + } MyClass; + + static void my_do_something(MyState *obj) + { + // do something + } + + static void my_class_init(ObjectClass *oc, void *data) + { + MyClass *mc = MY_CLASS(oc); + + mc->do_something = my_do_something; + } + + static const TypeInfo my_type_info = { + .name = TYPE_MY, + .parent = TYPE_OBJECT, + .instance_size = sizeof(MyState), + .class_size = sizeof(MyClass), + .class_init = my_class_init, + }; + + typedef struct DerivedClass { + MyClass parent_class; + + MyDoSomething parent_do_something; + } DerivedClass; + + static void derived_do_something(MyState *obj) + { + DerivedClass *dc = DERIVED_GET_CLASS(obj); + + // do something here + dc->parent_do_something(obj); + // do something else here + } + + static void derived_class_init(ObjectClass *oc, void *data) + { + MyClass *mc = MY_CLASS(oc); + DerivedClass *dc = DERIVED_CLASS(oc); + + dc->parent_do_something = mc->do_something; + mc->do_something = derived_do_something; + } + + static const TypeInfo derived_type_info = { + .name = TYPE_DERIVED, + .parent = TYPE_MY, + .class_size = sizeof(DerivedClass), + .class_init = derived_class_init, + }; + +Alternatively, object_class_by_name() can be used to obtain the class and +its non-overridden methods for a specific type. This would correspond to +``MyClass::method(...)`` in C++. + +The first example of such a QOM method was #CPUClass.reset, +another example is #DeviceClass.realize. + +Standard type declaration and definition macros +=============================================== + +A lot of the code outlined above follows a standard pattern and naming +convention. To reduce the amount of boilerplate code that needs to be +written for a new type there are two sets of macros to generate the +common parts in a standard format. + +A type is declared using the OBJECT_DECLARE macro family. In types +which do not require any virtual functions in the class, the +OBJECT_DECLARE_SIMPLE_TYPE macro is suitable, and is commonly placed +in the header file: + +.. code-block:: c + :caption: Declaring a simple type + + OBJECT_DECLARE_SIMPLE_TYPE(MyDevice, my_device, MY_DEVICE, DEVICE) + +This is equivalent to the following: + +.. code-block:: c + :caption: Expansion from declaring a simple type + + typedef struct MyDevice MyDevice; + typedef struct MyDeviceClass MyDeviceClass; + + G_DEFINE_AUTOPTR_CLEANUP_FUNC(MyDeviceClass, object_unref) + + #define MY_DEVICE_GET_CLASS(void *obj) \ + OBJECT_GET_CLASS(MyDeviceClass, obj, TYPE_MY_DEVICE) + #define MY_DEVICE_CLASS(void *klass) \ + OBJECT_CLASS_CHECK(MyDeviceClass, klass, TYPE_MY_DEVICE) + #define MY_DEVICE(void *obj) + OBJECT_CHECK(MyDevice, obj, TYPE_MY_DEVICE) + + struct MyDeviceClass { + DeviceClass parent_class; + }; + +The 'struct MyDevice' needs to be declared separately. +If the type requires virtual functions to be declared in the class +struct, then the alternative OBJECT_DECLARE_TYPE() macro can be +used. This does the same as OBJECT_DECLARE_SIMPLE_TYPE(), but without +the 'struct MyDeviceClass' definition. + +To implement the type, the OBJECT_DEFINE macro family is available. +In the simple case the OBJECT_DEFINE_TYPE macro is suitable: + +.. code-block:: c + :caption: Defining a simple type + + OBJECT_DEFINE_TYPE(MyDevice, my_device, MY_DEVICE, DEVICE) + +This is equivalent to the following: + +.. code-block:: c + :caption: Expansion from defining a simple type + + static void my_device_finalize(Object *obj); + static void my_device_class_init(ObjectClass *oc, void *data); + static void my_device_init(Object *obj); + + static const TypeInfo my_device_info = { + .parent = TYPE_DEVICE, + .name = TYPE_MY_DEVICE, + .instance_size = sizeof(MyDevice), + .instance_init = my_device_init, + .instance_finalize = my_device_finalize, + .class_size = sizeof(MyDeviceClass), + .class_init = my_device_class_init, + }; + + static void + my_device_register_types(void) + { + type_register_static(&my_device_info); + } + type_init(my_device_register_types); + +This is sufficient to get the type registered with the type +system, and the three standard methods now need to be implemented +along with any other logic required for the type. + +If the type needs to implement one or more interfaces, then the +OBJECT_DEFINE_TYPE_WITH_INTERFACES() macro can be used instead. +This accepts an array of interface type names. + +.. code-block:: c + :caption: Defining a simple type implementing interfaces + + OBJECT_DEFINE_TYPE_WITH_INTERFACES(MyDevice, my_device, + MY_DEVICE, DEVICE, + { TYPE_USER_CREATABLE }, { NULL }) + +If the type is not intended to be instantiated, then then +the OBJECT_DEFINE_ABSTRACT_TYPE() macro can be used instead: + +.. code-block:: c + :caption: Defining a simple abstract type + + OBJECT_DEFINE_ABSTRACT_TYPE(MyDevice, my_device, MY_DEVICE, DEVICE) + + + +API Reference +------------- + .. kernel-doc:: include/qom/object.h diff --git a/include/qom/object.h b/include/qom/object.h index fec78cbb67..27aaa67e63 100644 --- a/include/qom/object.h +++ b/include/qom/object.h @@ -28,383 +28,6 @@ typedef struct InterfaceInfo InterfaceInfo; #define TYPE_OBJECT "object" -/** - * DOC: - * - * .. highlight:: c - * - * The QEMU Object Model provides a framework for registering user creatable - * types and instantiating objects from those types. QOM provides the following - * features: - * - * - System for dynamically registering types - * - Support for single-inheritance of types - * - Multiple inheritance of stateless interfaces - * - * .. code-block:: c - * :caption: Creating a minimal type - * - * #include "qdev.h" - * - * #define TYPE_MY_DEVICE "my-device" - * - * // No new virtual functions: we can reuse the typedef for the - * // superclass. - * typedef DeviceClass MyDeviceClass; - * typedef struct MyDevice - * { - * DeviceState parent; - * - * int reg0, reg1, reg2; - * } MyDevice; - * - * static const TypeInfo my_device_info = { - * .name = TYPE_MY_DEVICE, - * .parent = TYPE_DEVICE, - * .instance_size = sizeof(MyDevice), - * }; - * - * static void my_device_register_types(void) - * { - * type_register_static(&my_device_info); - * } - * - * type_init(my_device_register_types) - * - * In the above example, we create a simple type that is described by #TypeInfo. - * #TypeInfo describes information about the type including what it inherits - * from, the instance and class size, and constructor/destructor hooks. - * - * Alternatively several static types could be registered using helper macro - * DEFINE_TYPES() - * - * .. code-block:: c - * - * static const TypeInfo device_types_info[] = { - * { - * .name = TYPE_MY_DEVICE_A, - * .parent = TYPE_DEVICE, - * .instance_size = sizeof(MyDeviceA), - * }, - * { - * .name = TYPE_MY_DEVICE_B, - * .parent = TYPE_DEVICE, - * .instance_size = sizeof(MyDeviceB), - * }, - * }; - * - * DEFINE_TYPES(device_types_info) - * - * Every type has an #ObjectClass associated with it. #ObjectClass derivatives - * are instantiated dynamically but there is only ever one instance for any - * given type. The #ObjectClass typically holds a table of function pointers - * for the virtual methods implemented by this type. - * - * Using object_new(), a new #Object derivative will be instantiated. You can - * cast an #Object to a subclass (or base-class) type using - * object_dynamic_cast(). You typically want to define macro wrappers around - * OBJECT_CHECK() and OBJECT_CLASS_CHECK() to make it easier to convert to a - * specific type: - * - * .. kernel-doc messes up with the code block below because of the - * backslash at the end of lines. This will be fixes if we move this - * content to qom.rst. - * - * .. code-block:: c - * :caption: Typecasting macros - * - * #define MY_DEVICE_GET_CLASS(obj) \ - * OBJECT_GET_CLASS(MyDeviceClass, obj, TYPE_MY_DEVICE) - * #define MY_DEVICE_CLASS(klass) \ - * OBJECT_CLASS_CHECK(MyDeviceClass, klass, TYPE_MY_DEVICE) - * #define MY_DEVICE(obj) \ - * OBJECT_CHECK(MyDevice, obj, TYPE_MY_DEVICE) - * - * Class Initialization - * ==================== - * - * Before an object is initialized, the class for the object must be - * initialized. There is only one class object for all instance objects - * that is created lazily. - * - * Classes are initialized by first initializing any parent classes (if - * necessary). After the parent class object has initialized, it will be - * copied into the current class object and any additional storage in the - * class object is zero filled. - * - * The effect of this is that classes automatically inherit any virtual - * function pointers that the parent class has already initialized. All - * other fields will be zero filled. - * - * Once all of the parent classes have been initialized, #TypeInfo::class_init - * is called to let the class being instantiated provide default initialize for - * its virtual functions. Here is how the above example might be modified - * to introduce an overridden virtual function: - * - * .. code-block:: c - * :caption: Overriding a virtual function - * - * #include "qdev.h" - * - * void my_device_class_init(ObjectClass *klass, void *class_data) - * { - * DeviceClass *dc = DEVICE_CLASS(klass); - * dc->reset = my_device_reset; - * } - * - * static const TypeInfo my_device_info = { - * .name = TYPE_MY_DEVICE, - * .parent = TYPE_DEVICE, - * .instance_size = sizeof(MyDevice), - * .class_init = my_device_class_init, - * }; - * - * Introducing new virtual methods requires a class to define its own - * struct and to add a .class_size member to the #TypeInfo. Each method - * will also have a wrapper function to call it easily: - * - * .. code-block:: c - * :caption: Defining an abstract class - * - * #include "qdev.h" - * - * typedef struct MyDeviceClass - * { - * DeviceClass parent; - * - * void (*frobnicate) (MyDevice *obj); - * } MyDeviceClass; - * - * static const TypeInfo my_device_info = { - * .name = TYPE_MY_DEVICE, - * .parent = TYPE_DEVICE, - * .instance_size = sizeof(MyDevice), - * .abstract = true, // or set a default in my_device_class_init - * .class_size = sizeof(MyDeviceClass), - * }; - * - * void my_device_frobnicate(MyDevice *obj) - * { - * MyDeviceClass *klass = MY_DEVICE_GET_CLASS(obj); - * - * klass->frobnicate(obj); - * } - * - * Interfaces - * ========== - * - * Interfaces allow a limited form of multiple inheritance. Instances are - * similar to normal types except for the fact that are only defined by - * their classes and never carry any state. As a consequence, a pointer to - * an interface instance should always be of incomplete type in order to be - * sure it cannot be dereferenced. That is, you should define the - * 'typedef struct SomethingIf SomethingIf' so that you can pass around - * ``SomethingIf *si`` arguments, but not define a ``struct SomethingIf { ... }``. - * The only things you can validly do with a ``SomethingIf *`` are to pass it as - * an argument to a method on its corresponding SomethingIfClass, or to - * dynamically cast it to an object that implements the interface. - * - * Methods - * ======= - * - * A method is a function within the namespace scope of - * a class. It usually operates on the object instance by passing it as a - * strongly-typed first argument. - * If it does not operate on an object instance, it is dubbed - * class method. - * - * Methods cannot be overloaded. That is, the #ObjectClass and method name - * uniquely identity the function to be called; the signature does not vary - * except for trailing varargs. - * - * Methods are always virtual. Overriding a method in - * #TypeInfo.class_init of a subclass leads to any user of the class obtained - * via OBJECT_GET_CLASS() accessing the overridden function. - * The original function is not automatically invoked. It is the responsibility - * of the overriding class to determine whether and when to invoke the method - * being overridden. - * - * To invoke the method being overridden, the preferred solution is to store - * the original value in the overriding class before overriding the method. - * This corresponds to ``{super,base}.method(...)`` in Java and C# - * respectively; this frees the overriding class from hardcoding its parent - * class, which someone might choose to change at some point. - * - * .. code-block:: c - * :caption: Overriding a virtual method - * - * typedef struct MyState MyState; - * - * typedef void (*MyDoSomething)(MyState *obj); - * - * typedef struct MyClass { - * ObjectClass parent_class; - * - * MyDoSomething do_something; - * } MyClass; - * - * static void my_do_something(MyState *obj) - * { - * // do something - * } - * - * static void my_class_init(ObjectClass *oc, void *data) - * { - * MyClass *mc = MY_CLASS(oc); - * - * mc->do_something = my_do_something; - * } - * - * static const TypeInfo my_type_info = { - * .name = TYPE_MY, - * .parent = TYPE_OBJECT, - * .instance_size = sizeof(MyState), - * .class_size = sizeof(MyClass), - * .class_init = my_class_init, - * }; - * - * typedef struct DerivedClass { - * MyClass parent_class; - * - * MyDoSomething parent_do_something; - * } DerivedClass; - * - * static void derived_do_something(MyState *obj) - * { - * DerivedClass *dc = DERIVED_GET_CLASS(obj); - * - * // do something here - * dc->parent_do_something(obj); - * // do something else here - * } - * - * static void derived_class_init(ObjectClass *oc, void *data) - * { - * MyClass *mc = MY_CLASS(oc); - * DerivedClass *dc = DERIVED_CLASS(oc); - * - * dc->parent_do_something = mc->do_something; - * mc->do_something = derived_do_something; - * } - * - * static const TypeInfo derived_type_info = { - * .name = TYPE_DERIVED, - * .parent = TYPE_MY, - * .class_size = sizeof(DerivedClass), - * .class_init = derived_class_init, - * }; - * - * Alternatively, object_class_by_name() can be used to obtain the class and - * its non-overridden methods for a specific type. This would correspond to - * ``MyClass::method(...)`` in C++. - * - * The first example of such a QOM method was #CPUClass.reset, - * another example is #DeviceClass.realize. - * - * Standard type declaration and definition macros - * =============================================== - * - * A lot of the code outlined above follows a standard pattern and naming - * convention. To reduce the amount of boilerplate code that needs to be - * written for a new type there are two sets of macros to generate the - * common parts in a standard format. - * - * A type is declared using the OBJECT_DECLARE macro family. In types - * which do not require any virtual functions in the class, the - * OBJECT_DECLARE_SIMPLE_TYPE macro is suitable, and is commonly placed - * in the header file: - * - * .. code-block:: c - * :caption: Declaring a simple type - * - * OBJECT_DECLARE_SIMPLE_TYPE(MyDevice, my_device, MY_DEVICE, DEVICE) - * - * This is equivalent to the following: - * - * .. code-block:: c - * :caption: Expansion from declaring a simple type - * - * typedef struct MyDevice MyDevice; - * typedef struct MyDeviceClass MyDeviceClass; - * - * G_DEFINE_AUTOPTR_CLEANUP_FUNC(MyDeviceClass, object_unref) - * - * #define MY_DEVICE_GET_CLASS(void *obj) \ - * OBJECT_GET_CLASS(MyDeviceClass, obj, TYPE_MY_DEVICE) - * #define MY_DEVICE_CLASS(void *klass) \ - * OBJECT_CLASS_CHECK(MyDeviceClass, klass, TYPE_MY_DEVICE) - * #define MY_DEVICE(void *obj) - * OBJECT_CHECK(MyDevice, obj, TYPE_MY_DEVICE) - * - * struct MyDeviceClass { - * DeviceClass parent_class; - * }; - * - * The 'struct MyDevice' needs to be declared separately. - * If the type requires virtual functions to be declared in the class - * struct, then the alternative OBJECT_DECLARE_TYPE() macro can be - * used. This does the same as OBJECT_DECLARE_SIMPLE_TYPE(), but without - * the 'struct MyDeviceClass' definition. - * - * To implement the type, the OBJECT_DEFINE macro family is available. - * In the simple case the OBJECT_DEFINE_TYPE macro is suitable: - * - * .. code-block:: c - * :caption: Defining a simple type - * - * OBJECT_DEFINE_TYPE(MyDevice, my_device, MY_DEVICE, DEVICE) - * - * This is equivalent to the following: - * - * .. code-block:: c - * :caption: Expansion from defining a simple type - * - * static void my_device_finalize(Object *obj); - * static void my_device_class_init(ObjectClass *oc, void *data); - * static void my_device_init(Object *obj); - * - * static const TypeInfo my_device_info = { - * .parent = TYPE_DEVICE, - * .name = TYPE_MY_DEVICE, - * .instance_size = sizeof(MyDevice), - * .instance_init = my_device_init, - * .instance_finalize = my_device_finalize, - * .class_size = sizeof(MyDeviceClass), - * .class_init = my_device_class_init, - * }; - * - * static void - * my_device_register_types(void) - * { - * type_register_static(&my_device_info); - * } - * type_init(my_device_register_types); - * - * This is sufficient to get the type registered with the type - * system, and the three standard methods now need to be implemented - * along with any other logic required for the type. - * - * If the type needs to implement one or more interfaces, then the - * OBJECT_DEFINE_TYPE_WITH_INTERFACES() macro can be used instead. - * This accepts an array of interface type names. - * - * .. code-block:: c - * :caption: Defining a simple type implementing interfaces - * - * OBJECT_DEFINE_TYPE_WITH_INTERFACES(MyDevice, my_device, - * MY_DEVICE, DEVICE, - * { TYPE_USER_CREATABLE }, { NULL }) - * - * If the type is not intended to be instantiated, then then - * the OBJECT_DEFINE_ABSTRACT_TYPE() macro can be used instead: - * - * .. code-block:: c - * :caption: Defining a simple abstract type - * - * OBJECT_DEFINE_ABSTRACT_TYPE(MyDevice, my_device, MY_DEVICE, DEVICE) - */ - - typedef struct ObjectProperty ObjectProperty; /** -- cgit v1.2.3-55-g7522 From de4d4adb5875482756396f24b959b03fe3ce8575 Mon Sep 17 00:00:00 2001 From: Pavel Pisa Date: Mon, 14 Sep 2020 10:13:41 +0200 Subject: hw/net/can: Documentation for CTU CAN FD IP open hardware core emulation. Updated MAINTAINERS for CAN bus related emulation as well. Signed-off-by: Pavel Pisa Message-Id: <6d1b8db69efc4e5cfad702d2150e1960e8f63572.1600069689.git.pisa@cmp.felk.cvut.cz> Signed-off-by: Paolo Bonzini --- MAINTAINERS | 9 +++++ docs/can.txt | 113 +++++++++++++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 111 insertions(+), 11 deletions(-) (limited to 'docs') diff --git a/MAINTAINERS b/MAINTAINERS index ffcf222243..ade1100202 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2091,6 +2091,15 @@ F: hw/rx/ F: include/hw/intc/rx_icu.h F: include/hw/rx/ +CAN bus subsystem and hardware +M: Pavel Pisa +M: Vikram Garhwal +S: Maintained +W: https://canbus.pages.fel.cvut.cz/ +F: net/can/* +F: hw/net/can/* +F: include/net/can_*.h + Subsystems ---------- Audio diff --git a/docs/can.txt b/docs/can.txt index 11ed8f2d68..5838f6620c 100644 --- a/docs/can.txt +++ b/docs/can.txt @@ -8,13 +8,22 @@ can be connected to host system CAN API (at this time only Linux SocketCAN is supported). The concept of busses is generic and different CAN controllers -can be implemented for it but at this time only SJA1000 chip -controller is implemented. +can be implemented. + +The initial submission implemented SJA1000 controller which +is common and well supported by by drivers for the most operating +systems. The PCI addon card hardware has been selected as the first CAN interface to implement because such device can be easily connected to systems with different CPU architectures (x86, PowerPC, Arm, etc.). +In 2020, CTU CAN FD controller model has been added as part +of the bachelor theses of Jan Charvat. This controller is complete +open-source/design/hardware solution. The core designer +of the project is Ondrej Ille, the financial support has been +provided by CTU, and more companies including Volkswagen subsidiaries. + The project has been initially started in frame of RTEMS GSoC 2013 slot by Jin Yang under our mentoring The initial idea was to provide generic CAN subsystem for RTEMS. But lack of common environment for code and RTEMS @@ -22,8 +31,8 @@ testing lead to goal change to provide environment which provides complete emulated environment for testing and RTEMS GSoC slot has been donated to work on CAN hardware emulation on QEMU. -Examples how to use CAN emulation -================================= +Examples how to use CAN emulation for SJA1000 based borads +========================================================== When QEMU with CAN PCI support is compiled then one of the next CAN boards can be selected @@ -90,18 +99,100 @@ traffic with "candump" command which is included in "can-utils". candump can0 +CTU CAN FD support examples +=========================== + +This open-source core provides CAN FD support. CAN FD drames are +delivered even to the host systems when SocketCAN interface is found +CAN FD capable. + +The PCIe borad emulation is provided for now (the device identifier is +ctucan_pci). The defauld build defines two CTU CAN FD cores +on the board. + +Example how to connect the canbus0-bus (virtual wire) to the host +Linux system (SocketCAN used) and to both CTU CAN FD cores emulated +on the corresponding PCI card expects that host system CAN bus +is setup according to the previous SJA1000 section. + + qemu-system-x86_64 -enable-kvm -kernel /boot/vmlinuz-4.19.52+ \ + -initrd ramdisk.cpio \ + -virtfs local,path=shareddir,security_model=none,mount_tag=shareddir \ + -vga cirrus \ + -append "console=ttyS0" \ + -object can-bus,id=canbus0-bus \ + -object can-host-socketcan,if=can0,canbus=canbus0-bus,id=canbus0-socketcan \ + -device ctucan_pci,canbus0=canbus0-bus,canbus1=canbus0-bus \ + -nographic + +Setup of CTU CAN FD controller in a guest Linux system + + insmod ctucanfd.ko || modprobe ctucanfd + insmod ctucanfd_pci.ko || modprobe ctucanfd_pci + + for ifc in /sys/class/net/can* ; do + if [ -e $ifc/device/vendor ] ; then + if ! grep -q 0x1760 $ifc/device/vendor ; then + continue; + fi + else + continue; + fi + if [ -e $ifc/device/device ] ; then + if ! grep -q 0xff00 $ifc/device/device ; then + continue; + fi + else + continue; + fi + ifc=$(basename $ifc) + /bin/ip link set $ifc type can bitrate 1000000 dbitrate 10000000 fd on + /bin/ip link set $ifc up + done + +The test can run for example + + candump can1 + +in the guest system and next commands in the host system for basic CAN + + cangen can0 + +for CAN FD without bitrate switch + + cangen can0 -f + +and with bitrate switch + + cangen can0 -b + +The test can be run viceversa, generate messages in the guest system and capture them +in the host one and much more combinations. + Links to other resources ======================== - (1) Repository with development branch can-pci at Czech Technical University - https://gitlab.fel.cvut.cz/canbus/qemu-canbus - (2) GitHub repository with can-pci and our other changes included + (1) CAN related projects at Czech Technical University, Faculty of Electrical Engineering + http://canbus.pages.fel.cvut.cz/ + (2) Repository with development can-pci branch at Czech Technical University https://gitlab.fel.cvut.cz/canbus/qemu-canbus (3) RTEMS page describing project https://devel.rtems.org/wiki/Developer/Simulators/QEMU/CANEmulation (4) RTLWS 2015 article about the project and its use with CANopen emulation - http://rtime.felk.cvut.cz/publications/public/rtlws2015-qemu-can.pdf - Slides - http://rtime.felk.cvut.cz/publications/public/rtlws2015-qemu-can-slides.pdf - (5) Linux SocketCAN utilities + http://cmp.felk.cvut.cz/~pisa/can/doc/rtlws-17-pisa-qemu-can.pdf + (5) GNU/Linux, CAN and CANopen in Real-time Control Applications + Slides from LinuxDays 2017 (include updated RTLWS 2015 content) + https://www.linuxdays.cz/2017/video/Pavel_Pisa-CAN_canopen.pdf + (6) Linux SocketCAN utilities https://github.com/linux-can/can-utils/ + (7) CTU CAN FD project including core VHDL design, Linux driver, + test utilities etc. + https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core + (8) CTU CAN FD Core Datasheet Documentation + http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/Progdokum.pdf + (9) CTU CAN FD Core System Architecture Documentation + http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/ctu_can_fd_architecture.pdf + (10) CTU CAN FD Driver Documentation + http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/driver_doc/ctucanfd-driver.html + (11) Integration with PCIe interfacing for Intel/Altera Cyclone IV based board + https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd -- cgit v1.2.3-55-g7522