Re: command line syntax for connecting a chardev to a CPU

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Jun 21, 2024 at 06:43:57PM +0100, Peter Maydell wrote:
> 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.boddu@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?


Partially relevant context is that on x86 we have the "isa-debugcon"
device, that effectively just creates a output only serial port
for firmware to use for debugging. That's an actual device though.

The problem with CPUs is that we don't have a -device <cpu-type>
for each CPU that's created, instead -cpu creates the devices
implicitly.

This might suggest using an object type instead, eg

  -object arm-ddc,cpu=0,chardev=cdev0
  -chardev pty,id=cdev0
  -object arm-ddc,cpu=1,chardev=cdev1
  -chardev pty,id=cdev2
  -object arm-ddc,cpu=2,chardev=cdev2
  -chardev pty,id=cdev2
  -object arm-ddc,cpu=3,chardev=cdev3
  -chardev pty,id=cdev3

And the CPU impl would just have to access some internal global API
from the 'arm-ddc' object type, to find its chardev, if any.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|