On Mon, Jan 28, 2019 at 11:26:57AM +0000, Daniel P. Berrangé wrote:
> On Mon, Jan 28, 2019 at 12:19:36PM +0100, Andrea Bolognani wrote:
> > On Mon, 2019-01-28 at 10:36 +0000, Daniel P. Berrangé wrote:
> > > On Mon, Jan 28, 2019 at 11:24:38AM +0100, Andrea Bolognani wrote:
> > > > Should this be a <channel> at all?
> > > >
> > > > We generally use <serial> for native emulated devices such as
> > > > isa-serial, which isa-debugcon seems very closely related to...
> > >
> > > <channel> is aiming to expose application specific guest data channels.
> > >
> > > <serial> is aiming to expose general purpose guest data channels.
> > >
> > > To me isa-debugcon is an application specific data channels, so
> > > <channel> feels a better fit.
> >
> > Maybe I have misunderstood what isa-debugcon is, but it looks more
> > of a general purpose channel in the vein of isa-serial rather than
> > something application specific like the qemu-guest-agent or SPICE
> > channels for example.
>
> My understanding is that isa-debugcon is a special device just
> for usage by SeaBIOS to emit debug messages.
I'm not sure if it's that simple, if you look at the QEMU commit
<c9f398e53fedb88df243e32eb9bc50fda4ec44d0> that introduced isa-debugcon
there are also changes notes and apparently there are other non-ISA
variants of the debugcon which are not implemented in QEMU but they
exists.
From what I understand it's a special device to gather debug messages
from various firmwares, not only SeaBIOS, but also OVMF for example.
According to our documentation:
========================================================================
Due to hystorical reasons, the serial and console elements have
partially overlapping scopes.
In general, both elements are used to configure one or more serial
consoles to be used for interacting with the guest. The main difference
between the two is that serial is used for emulated, usually native,
serial consoles, whereas console is used for paravirtualized ones.
Both emulated and paravirtualized serial consoles have advantages
and disadvantages:
- emulated serial consoles are usually initialized much earlier than
paravirtualized ones, so they can be used to control the bootloader
and display both firmware and early boot messages;
- on several platforms, there can only be a single emulated serial
console per guest but paravirtualized consoles don't suffer from
the same limitation.
========================================================================
Based on that and the fact that this is a debug console for firmwares
I'm more inclined to model it as <serial>.
I would suggest something like this:
<serial type='...'>
<target type='isa-serial'>
<model type='debugcon'/> or <model type='isa-debugcon'/>
</serial>
As Dan mentioned first 'isa-serial' is duplicated as <channel> no matter
the model of the 'isa-serial' target. In order to use 'isa-serial'
target we would have add some code to make sure that we duplicate the
<serial> device only if the 'mode' is not set or is set to 'isa-serial'.
Or if we would go with the channel:
<channel type='...'>
<target type='debugcon'>
</channel>
In case of channel we don't have to model the BUS into the type since we
can pick the address type based on architecture unless the isa-debugcon
works also on other architectures and not only on x86.
Pavel
>
> 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 :|
>
> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
