Peter Maydell <peter.mayd...@linaro.org> writes: > 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,
Neither do I. > but maybe we do that already somewhere, and so it's OK to do here? I'm not aware of such existing (ab)use of chardev IDs. > 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). Looks like an instance of the old "how to set properties of onboard devices" problem. Still no good solution. > 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. Machine properties that are aliases of the to onboard device properties we want to set is a solution we used in places. Requires plumbing, as you wrote. > Do we have a neat way to specify per-cpu CPU properties that I'm missing? I'm not aware of a better solution.
