Re: [PATCH v5 8/8] hw/mem/cxl_type3: Add CXL RAS Error Injection Support.

[Markus Armbruster]

Philippe Mathieu-Daudé <philmd@linaro.org> writes:

> On 23/2/23 15:27, Jonathan Cameron wrote:
>> On Thu, 23 Feb 2023 08:37:46 +0100
>> Markus Armbruster <armbru@redhat.com> wrote:
>>> Whenever you use a poisoned macro in a conditional, all the code
>>> generated for this .json file (we call it a "QAPI schema module")
>>> becomes target-dependent.  The QAPI code generator itself is blissfully
>>> unaware of this.
>>>
>>> Since target-dependent code needs to be compiled differently, the build
>>> process needs to be know which modules are target-dependent.  We do this
>>> in one of the stupidest ways that could possibly work: a module is
>>> target-dependent if its name ends with "-target".  There are just two
>>> right now: qapi/machine-target.json and qapi/misc-target.json.
>>>
>>> The logic resides in qapi/meson.build.  Look for
>>>
>>>      if module.endswith('-target')
>>
>> Thanks for all the pointers.
>>
>>> Questions?
>>>
>> Is it sensible to make the cxl stuff all target dependent and do the 
>> following?
>> I like that we can get rid of the stubs if we do this but I'm sure there are
>> disadvantages. Only alternative I can currently see is continue to have
>> stubs and not make the qmp commands conditional on them doing anything 
>> useful.
>
> I still don't understand what is the target-dependent part of CXL.
>
> IIUC CXL depends on PCIe which isn't target dependent.

As far as I can tell, the target-dependent part of CXL is the macro
CONFIG_CXL :)

Consider a device model implemented in perfectly target-independent
code, to be linked only into some qemu-system-TARGET.  How do we do
that?

We put a 'config FOO' section in the appropriate Kconfig, and select it
from the target's Kconfig for the targets that want it.  We add device
model sources to Meson source set softmmu_ss when CONFIG_FOO.

This puts CONFIG_FOO=y into the TARGET-softmmu-config-devices.mak, and
#define CONFIG_FOO 1 into TARGET-softmmu-config-devices.h.  It also puts
#pragma GCC poison CONFIG_FOO into config-poison.h.

Note the two CONFIG_FOO have subtly different meaning:

* The make variable means "there is an enabled target that has FOO
  enabled".  It gets propagated to Meson.

* The C macro means "the current target has FOO enabled".  It therefore
  must not be used in target-independent code.  That's why we poison it
  in config-poison.h.

Note that the device model code has no use for C macro CONFIG_FOO.  It
remains target-independent as it should.

Now consider how to have the QAPI schema provide something for FOO.

If we make it a QAPI schema module of its own, we can arrange for it to
be linked only into the qemu-system-TARGET that have the device model,
just like the device model code.  We haven't tried this for individual
devices, only for whole subsystems like PCI.

If we don't make it a module of its own, we have two choices:

* We use 'if': 'CONFIG_FOO'.  This is actually the C macro.  The module
  becomes target-dependent.  We compile the code generated for the
  module separately for each target.

* We make it unconditional.  The module can remain target-independent.
  The code generated for FOO's QAPI schema is linked unconditionally,
  even when the target doesn't need it.  Any references to handwritten
  FOO code need to be satisfied with stubs.

I dislike both.  Existing usage seems to prefer "unconditional schema".
Sticking to that is okay.