debugcon: support for debugging consoles (e.g. Bochs port 0xe9)

Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs and Qemu.

There is no vm state associated with the debugging port, simply
because it has none -- the entire interface is a single, stateless,
write-only port.

Most of the code was cribbed from the serial port driver.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
 Makefile.target |    2 +-
 hw/debugcon.c   |  189 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/pc.c         |    6 ++
 hw/pc.h         |    4 +
 qemu-common.h   |    1 +
 qemu-options.hx |   11 +++
 sysemu.h        |    6 ++
 vl.c            |   40 ++++++++++++
 8 files changed, 258 insertions(+), 1 deletions(-)
 create mode 100644 hw/debugcon.c

H. Peter Anvin wrote:
> Add generic support for debugging consoles (simple I/O ports which
> when written to cause debugging output to be written to a target.)
> The current implementation matches Bochs' port 0xe9, allowing the same
> debugging code to be used for both Bochs and Qemu.

Your implementation seems to miss the read part, unless you don't want to be
compatible with Bochs. user.dbk says:
"Reading from port 0xE9 will will return 0xe9 to let you know if the feature is available."

- Sebastian

Sebastian Herbszt wrote:
> H. Peter Anvin wrote:
>> Add generic support for debugging consoles (simple I/O ports which
>> when written to cause debugging output to be written to a target.)
>> The current implementation matches Bochs' port 0xe9, allowing the same
>> debugging code to be used for both Bochs and Qemu.
> 
> Your implementation seems to miss the read part, unless you don't want 
> to be
> compatible with Bochs. user.dbk says:
> "Reading from port 0xE9 will will return 0xe9 to let you know if the 
> feature is available."
> 

I had actually missed that part... it seems somewhat pointless to me, 
but if that's the way Bochs does it it probably would indeed be better 
to be compatible.

	-hpa

On 11/20/09 22:33, H. Peter Anvin wrote:

> +static const uint16_t isa_debugcon_iobase[MAX_DEBUGCON_PORTS] = { 0xe9 };

Not needed here.

> +    if (isa->index == -1)
> +        isa->index = index;
> +    if (isa->index>= MAX_DEBUGCON_PORTS)
> +        return -1;
> +    if (isa->iobase == -1)
> +	isa->iobase = isa_debugcon_iobase[isa->index];
> +    index++;

Also not needed.

> +    debugcon_init_core(s);
> +    register_ioport_write(isa->iobase, 1, 1, debugcon_ioport_write, s);
> +    return 0;
> +}
> +
> +DebugconState *debugcon_isa_init(int index, CharDriverState *chr)
> +{
> +    ISADevice *dev;
> +
> +    dev = isa_create("isa-debugcon");
> +    qdev_prop_set_chr(&dev->qdev, "chardev", chr);
> +    if (qdev_init(&dev->qdev)<  0)
> +        return NULL;
> +    return&DO_UPCAST(ISADebugconState, dev, dev)->state;
> +}

Can be dropped too.

> +static ISADeviceInfo debugcon_isa_info = {
> +    .qdev.name  = "isa-debugcon",
> +    .qdev.size  = sizeof(ISADebugconState),
> +    .init       = debugcon_isa_initfn,
> +    .qdev.props = (Property[]) {
> +        DEFINE_PROP_HEX32("index",  ISADebugconState, index,   -1),

Drop index property.

> +        DEFINE_PROP_HEX32("iobase", ISADebugconState, iobase,  -1),

Last arg is the default value, simply place 0xe9 there.

> +        DEFINE_PROP_CHR("chardev",  ISADebugconState, state.chr),
> +        DEFINE_PROP_END_OF_LIST(),
> +    },
> +};
> +
> +static void debugcon_register_devices(void)
> +{
> +    isa_qdev_register(&debugcon_isa_info);
> +}

> diff --git a/hw/pc.c b/hw/pc.c
> diff --git a/hw/pc.h b/hw/pc.h
> diff --git a/qemu-common.h b/qemu-common.h
> diff --git a/qemu-options.hx b/qemu-options.hx
> diff --git a/sysemu.h b/sysemu.h
> diff --git a/vl.c b/vl.c

All not needed.  Simply registering as qdev device is enougth.  You can 
then add a debug port like this, without adding new cmd line options:

   -chardev vc,id=debug -device isa-debugcon,chardev=debug

Adding a second one on a non-default port works this way:

   -chardev vc,id=d2 -device isa-debugcon,iobase=0xea,chardev=d2

cheers,
   Gerd

On 11/23/2009 02:52 AM, Gerd Hoffmann wrote:
> 
> All not needed.  Simply registering as qdev device is enougth.  You can 
> then add a debug port like this, without adding new cmd line options:
> 
>    -chardev vc,id=debug -device isa-debugcon,chardev=debug
> 
> Adding a second one on a non-default port works this way:
> 
>    -chardev vc,id=d2 -device isa-debugcon,iobase=0xea,chardev=d2
> 

Sure, but is that user friendly?

	-hpa

On 11/23/2009 12:11 PM, H. Peter Anvin wrote:
> On 11/23/2009 02:52 AM, Gerd Hoffmann wrote:
>>
>> All not needed.  Simply registering as qdev device is enougth.  You can 
>> then add a debug port like this, without adding new cmd line options:
>>
>>    -chardev vc,id=debug -device isa-debugcon,chardev=debug
>>
>> Adding a second one on a non-default port works this way:
>>
>>    -chardev vc,id=d2 -device isa-debugcon,iobase=0xea,chardev=d2
>>
> 
> Sure, but is that user friendly?
> 

Question still stands... if this is The Way It Is Done, then I'll do it
that way, but I will personally never be able to remember to type the
above stuff without looking it up every time, whereas "-debugcon stdio"
is something I can remember in my sleep.

	-hpa

On 25.11.2009, at 00:05, H. Peter Anvin wrote:

> On 11/23/2009 12:11 PM, H. Peter Anvin wrote:
>> On 11/23/2009 02:52 AM, Gerd Hoffmann wrote:
>>> 
>>> All not needed.  Simply registering as qdev device is enougth.  You can 
>>> then add a debug port like this, without adding new cmd line options:
>>> 
>>>   -chardev vc,id=debug -device isa-debugcon,chardev=debug
>>> 
>>> Adding a second one on a non-default port works this way:
>>> 
>>>   -chardev vc,id=d2 -device isa-debugcon,iobase=0xea,chardev=d2
>>> 
>> 
>> Sure, but is that user friendly?
>> 
> 
> Question still stands... if this is The Way It Is Done, then I'll do it
> that way, but I will personally never be able to remember to type the
> above stuff without looking it up every time, whereas "-debugcon stdio"
> is something I can remember in my sleep.

I agree with hpa here. While the -device syntax is nice for development and hacky stuff, let's please not force any user to use it!

Alex

On 11/25/09 00:05, H. Peter Anvin wrote:
> On 11/23/2009 12:11 PM, H. Peter Anvin wrote:
>> On 11/23/2009 02:52 AM, Gerd Hoffmann wrote:
>>>
>>> All not needed.  Simply registering as qdev device is enougth.  You can
>>> then add a debug port like this, without adding new cmd line options:
>>>
>>>     -chardev vc,id=debug -device isa-debugcon,chardev=debug
>>>
>>> Adding a second one on a non-default port works this way:
>>>
>>>     -chardev vc,id=d2 -device isa-debugcon,iobase=0xea,chardev=d2
>>>
>>
>> Sure, but is that user friendly?
>>
>
> Question still stands... if this is The Way It Is Done, then I'll do it
> that way, but I will personally never be able to remember to type the
> above stuff without looking it up every time, whereas "-debugcon stdio"
> is something I can remember in my sleep.

You can stick it into a config file[1] like this:

[chardev "debuglog"]
   backend = "file"
   path = "/path/to/debug.log"

[device]
   driver = "isa-debugcon"
   chardev = "debuglog"

Then use "qemu -readconfig $file".

cheers,
   Gerd

[1] Well, almost, fix to make this actually work went to the list today.

Gerd Hoffmann wrote:
> 
> You can stick it into a config file[1] like this:
> 
> [chardev "debuglog"]
>   backend = "file"
>   path = "/path/to/debug.log"
> 
> [device]
>   driver = "isa-debugcon"
>   chardev = "debuglog"
> 
> Then use "qemu -readconfig $file".
> 

Great... at least in my opinion, one of the things that makes Qemu so 
much easier to use than Bochs is that one has a comprehensive (and 
comprehensable) command line and don't have to set up a configuration 
file for every trivial little thing.  It's a good thing for long-living 
virtualization instances, but I would be sad if the command line will 
end up being neglected.

	-hpa

On 11/25/09 19:01, H. Peter Anvin wrote:
> Gerd Hoffmann wrote:
>>
>> You can stick it into a config file[1] like this:
>>
>> [chardev "debuglog"]
>> backend = "file"
>> path = "/path/to/debug.log"
>>
>> [device]
>> driver = "isa-debugcon"
>> chardev = "debuglog"
>>
>> Then use "qemu -readconfig $file".
>>
>
> Great... at least in my opinion, one of the things that makes Qemu so
> much easier to use than Bochs is that one has a comprehensive (and
> comprehensable) command line and don't have to set up a configuration
> file for every trivial little thing. It's a good thing for long-living
> virtualization instances, but I would be sad if the command line will
> end up being neglected.

You can happily mixup things as you like.  Use pure command line.  Use 
pure config file (well, at least is that the plan, it doesn't fully work 
yet).  Mix cmd line switches and config file.  Reading multiple config 
files works just fine too, so you can split your vm config into multiple 
parts and enable/disable parts by reading/not reading the file in 
question ...

cheers,
   Gerd

On 11/25/2009 02:21 PM, Gerd Hoffmann wrote:
> 
> You can happily mixup things as you like.  Use pure command line.  Use 
> pure config file (well, at least is that the plan, it doesn't fully work 
> yet).  Mix cmd line switches and config file.  Reading multiple config 
> files works just fine too, so you can split your vm config into multiple 
> parts and enable/disable parts by reading/not reading the file in 
> question ...
> 

Right, of course; I didn't mean to imply that your config file would
make the command line be unavailable, nor did I mean to imply that it
isn't useful (quite on the contrary.)

What I meant was that the presence of config file does not avoid the
user-hostility of options like "-chardev stdio,id=debug -device
isa-debugcon,chardev=debug" ... for a command line user, the situation
is still the same, and when using Qemu for debugging and testing, this
is one case when you would be likely to run into the command line.

As such, I think there is still a place for the simple command line
options like "-hda", "-serial" and my proposed "-debugcon", in addition
to the full-featured connect-anything options and configuration files.
That's all.

	-hpa

On 11/25/2009 02:26 PM, H. Peter Anvin wrote:
> 
> As such, I think there is still a place for the simple command line
> options like "-hda", "-serial" and my proposed "-debugcon", in addition
> to the full-featured connect-anything options and configuration files.
> That's all.
> 

I guess one question is if the simplified options could be better
implemented via some kind of builtin macros or translation submodule
rather than being treated as first-class options which they basically
are now.  Still, that's a future development task.

	-hpa

On 11/25/09 23:31, H. Peter Anvin wrote:
> On 11/25/2009 02:26 PM, H. Peter Anvin wrote:
>>
>> As such, I think there is still a place for the simple command line
>> options like "-hda", "-serial" and my proposed "-debugcon", in addition
>> to the full-featured connect-anything options and configuration files.
>> That's all.
>>
>
> I guess one question is if the simplified options could be better
> implemented via some kind of builtin macros or translation submodule
> rather than being treated as first-class options which they basically
> are now.  Still, that's a future development task.

Wouldn't be that hard I think.  Something along the lines of

     case QEMU_OPTION_debugcon:
          opts = qemu_chr_parse_compat("debugcon", optarg);
          if (NULL == opts) {
               fprintf(stderr, "already have a debugcon chardev\");
               exit(1);
          }
          opts = qemu_opts_create(&qemu_device_opts, "debugcon", 1);
          if (NULL == opts) {
               fprintf(stderr, "already have a debugcon device\");
               exit(1);
          }
          qemu_opt_set(opts, "driver", isa-debugcon);
          qemu_opt_set(opts, "chardev", "debugcon");
          break;

should do the trick.  Depends on the chardev fix mentioned in this 
thread too.  Allows to define a single device with the default port via 
shortcut.

I tend to not add new command line switches for every little new device. 
  For this one it might be reasonable nevertheless given the use cases.

cheers,
   Gerd

Gerd Hoffmann <kraxel@redhat.com> writes:

> On 11/25/09 23:31, H. Peter Anvin wrote:
>> On 11/25/2009 02:26 PM, H. Peter Anvin wrote:
>>>
>>> As such, I think there is still a place for the simple command line
>>> options like "-hda", "-serial" and my proposed "-debugcon", in addition
>>> to the full-featured connect-anything options and configuration files.
>>> That's all.
>>>
>>
>> I guess one question is if the simplified options could be better
>> implemented via some kind of builtin macros or translation submodule
>> rather than being treated as first-class options which they basically
>> are now.  Still, that's a future development task.
>
> Wouldn't be that hard I think.  Something along the lines of
>
>     case QEMU_OPTION_debugcon:
>          opts = qemu_chr_parse_compat("debugcon", optarg);
>          if (NULL == opts) {
>               fprintf(stderr, "already have a debugcon chardev\");
>               exit(1);
>          }
>          opts = qemu_opts_create(&qemu_device_opts, "debugcon", 1);
>          if (NULL == opts) {
>               fprintf(stderr, "already have a debugcon device\");
>               exit(1);
>          }
>          qemu_opt_set(opts, "driver", isa-debugcon);
>          qemu_opt_set(opts, "chardev", "debugcon");
>          break;
>
> should do the trick.  Depends on the chardev fix mentioned in this
> thread too.  Allows to define a single device with the default port
> via shortcut.

There's precedence for this method to implement convenience options;
look for uses of qemu_opts_create() / qemu_opt_set().  Expanding the
convenience option into longhand that way saves code and avoids subtle
differences between the two.  Just avoid NULL == opts kraxelism ;)

[...]

On 11/25/2009 11:54 PM, Gerd Hoffmann wrote:
>
> Wouldn't be that hard I think.

Cool.  I had thought of a similar exercise to wet my feet with 
qdev/qemuopts, I may actually do it when I have some time...

Paolo