command line syntax for connecting a chardev to a CPU

command line syntax for connecting a chardev to a CPU

[Peter Maydell]

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?

thanks
-- PMM

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

[Daniel P. Berrangé]

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 :|

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

[Markus Armbruster]

Peter Maydell <peter.maydell@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.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,

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.