qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v5 8/8] hw/mem/cxl_type3: Add CXL RAS Error Injection Support.
Date: Fri, 24 Feb 2023 20:02:59 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

On 23/2/23 15:27, Jonathan Cameron wrote:
On Thu, 23 Feb 2023 08:37:46 +0100
Markus Armbruster <armbru@redhat.com> wrote:

Thomas Huth <thuth@redhat.com> writes:

On 22/02/2023 19.16, Philippe Mathieu-Daudé wrote:
+Thomas (meson) & Marc-André (conditional QAPI)

+ Markus
On 22/2/23 17:49, Jonathan Cameron wrote:

[...]

Doesn't these need

         'if': 'CONFIG_CXL_MEM_DEVICE',

?

If I make this change I get a bunch of

./qapi/qapi-types-cxl.h:18:13: error: attempt to use poisoned 
"CONFIG_CXL_MEM_DEVICE"
      18 | #if defined(CONFIG_CXL_MEM_DEVICE)

Err, I meant the generic CONFIG_CXL, not CONFIG_CXL_MEM_DEVICE.
It's a target specific define (I think) as built alongside PCI_EXPRESS
Only CXL_ACPI is specifically included by x86 and arm64 (out of tree)

To be honest though I don't fully understand the QEMU build system so the reason
for the error might be wrong.

You need to restrict to system emulation (the 'have_system' check):

This doesn't help - still have
attempt to used poisoned "CONFIG_CXL"

Not sure how the QAPI generator works, but target specific config switches can only be 
used in target specific json files there, so that's machine-target.json and 
misc-target.json currently, as far as I know. Not sure how the QAPI generator 
distinguishes between common and target specific code, though ... just by the 
"-target" suffix? Maybe Markus or Marc-André can comment on that.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]