Arm CPUs have a "debug communications channel" which on real hardware is basically a way to talk to the debugger on the other end of a JTAG connection; Linux supports using this as a console. This patchseries: https://patchew.org/QEMU/20240614093026.328271-1-sai.pavan.bo...@amd.com/ proposes implementing this in QEMU by wiring it up to a QEMU chardev.
I think this is useful (among other things, it lets the user sidestep the "where is my UART?" question). But I'm not sure what the right way to let the user enable it and pick the chardev on the command line is. Do we have any relevant existing precedent? The patchseries has the CPU look for a chardev by ID, so if the user creates a chardev with id=dcc0 the first CPU will use that, if there's a chardev with id=dcc1 the second CPU will use that, and so on. I don't think we really want to make some ID string values be magic, but maybe we do that already somewhere, and so it's OK to do here? I thought also of having the CPU take a chardev property, but then the question is how to specify that on the command line. AFAICT the -cpu option (a) requires a CPU type first, which is a pain for cases where otherwise the user has no need to care about the exact type of CPU because the machine model creates the right one for them, and (b) for the key=value properties in a -cpu option string it will set the same property value for every CPU in the system (which obviously isn't what we want for this chardev). We could make it a machine property (so you would say eg -M xlnx-zcu102,dcc0=mychardev -chardev stdio,id=mychardev) but then that would require plumbing code in every machine model to create the property and set the value on the right CPU. Do we have a neat way to specify per-cpu CPU properties that I'm missing? thanks -- PMM
