qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, s


From: Amit Shah
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
User-agent: Mutt/1.5.19 (2009-01-05)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]