From: Amit Shah <amit.shah@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports
Date: Thu, 1 Oct 2009 16:18:43 +0530 [thread overview]
Message-ID: <20091001104843.GA12334@amit-x200.redhat.com> (raw)
In-Reply-To: <20091001085620.GB8385@amit-x200.redhat.com>
On (Thu) Oct 01 2009 [14:26:20], Amit Shah wrote:
> >>> If you do '-device virtio-console-pci -device virtio-port' (i.e. no
> >>> console) and boot a old guest kernel which expects a (single) console
> >>> being there, what will happen?
> >>
> >> OK -- I get what you're saying now. However, I don't see any problem
> >> here. If there is no virtioconsole specified to qemu, there's no reason
> >> to expect a console in the guest. That was the case in the past and is
> >> the case now as well. The difference is earlier, when probe() in the
> >> guest was called, it definitely meant the existence of a console. Now,
> >> even if probe() is invoked, it doesn't mean a console was found. But
> >> this hardly is a concern.
> >
> > True for new guest kernels, they simply don't create a hvc.
> > Question is what *old* guest kernels will do in that case.
>
> If the guest kernel doesn't support the new virtio feature
> VIRTIO_F_MULTIPORT, then we disable all this functionality and only
> allow one port. That one port has to be the console port. I've tested
> this combination, btw.
>
> However, it's possible that some of the checks got lost in the latest
> rework and that port 0 isn't actually a console port. I'll go through
> init code again to ensure this. Thanks for explaining the scenario!
There are a couple of problems with what I said:
- I had to make some changes in the kernel driver because hvc didn't
work as I expected. If initial consoles were spawned (currently only
on s390 and powerpc), new ports have to arrive in the same order as
init consoles were spawned.
This means /dev/console will be bound to the first console port that
gets initialised. It's desirable to always have port0 get that
distinction.
- We won't know if the guest supports multiple ports till the guest
driver does a probe(). That's much much later than when port drivers
in qemu are initialised.
So we will have to spawn a console port at id 0 when the bus is
initialised.
There are a couple of problems though:
- How to identify which chardev to associate the port#0 with?
- If there is a virtioconsole device specified on the command line,
should that be used as port0? Or should that mean we spawn two
consoles?
I guess for both these cases, some special command line tweaks will be
needed? Or keep the old '-virtioconsole' parameter and put that up as
port0?
Amit
next prev parent reply other threads:[~2009-10-01 10:49 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-29 12:04 [Qemu-devel] virtio-console-bus, multiport, virtio-console-port Amit Shah
2009-09-29 12:04 ` [Qemu-devel] [PATCH 1/6] char: Emit 'OPENED' events on char device open Amit Shah
2009-09-29 12:04 ` [Qemu-devel] [PATCH 2/6] qdev: add string property Amit Shah
2009-09-29 12:04 ` [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports Amit Shah
2009-09-29 12:04 ` [Qemu-devel] [PATCH 4/6] virtio-console-port: Add a new device on the virtio-console-bus for generic host-guest communication Amit Shah
2009-09-29 12:04 ` [Qemu-devel] [PATCH 5/6] vnc: add a is_vnc_active() helper Amit Shah
2009-09-29 12:04 ` [Qemu-devel] [PATCH 6/6] vnc: Add a virtio-console-bus device to send / receive guest clipboard Amit Shah
2009-09-29 18:13 ` Gerd Hoffmann
2009-09-30 4:50 ` Amit Shah
2009-09-29 18:08 ` [Qemu-devel] [PATCH 4/6] virtio-console-port: Add a new device on the virtio-console-bus for generic host-guest communication Gerd Hoffmann
2009-09-30 8:09 ` Nathan Baum
2009-09-29 18:04 ` [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports Gerd Hoffmann
2009-09-30 4:47 ` Amit Shah
2009-09-30 8:59 ` Gerd Hoffmann
2009-09-30 15:55 ` Amit Shah
2009-09-30 18:39 ` Gerd Hoffmann
2009-10-01 4:54 ` Amit Shah
2009-10-01 8:38 ` Gerd Hoffmann
2009-10-01 8:56 ` Amit Shah
2009-10-01 10:48 ` Amit Shah [this message]
2009-10-01 12:15 ` Gerd Hoffmann
2009-10-07 9:25 ` Amit Shah
2009-10-07 9:51 ` Gerd Hoffmann
2009-10-07 10:06 ` Amit Shah
2009-10-07 11:33 ` Gerd Hoffmann
2009-10-07 11:42 ` Amit Shah
2009-10-07 13:06 ` Gerd Hoffmann
2009-10-07 13:53 ` Amit Shah
2009-10-07 14:03 ` Gerd Hoffmann
2009-10-07 14:00 ` Anthony Liguori
2009-09-30 21:13 ` [Qemu-devel] [PATCH 1/6] char: Emit 'OPENED' events on char device open Anthony Liguori
2009-10-01 4:56 ` Amit Shah
2009-10-01 6:02 ` Amit Shah
2009-10-01 12:54 ` Anthony Liguori
2009-10-01 13:43 ` Gerd Hoffmann
2009-10-01 13:48 ` Anthony Liguori
2009-10-01 15:18 ` Gerd Hoffmann
2009-09-29 14:53 ` [Qemu-devel] virtio-console-bus, multiport, virtio-console-port Amit Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091001104843.GA12334@amit-x200.redhat.com \
--to=amit.shah@redhat.com \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).