All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Fehlig <jfehlig@novell.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: PV console bug in 4.0 / unstable
Date: Thu, 21 Jan 2010 17:51:04 -0700	[thread overview]
Message-ID: <4B58F678.5060608@novell.com> (raw)

I'm chasing a console bug in Xen 4.0 that only appears with managed PV
domains - and even then only after an initial start-->stop sequence.

Legacy PV domain config files generally do not specify a console device
explicitly but instead get one via qemu with

vfb=['type=vnc,vncunused=1']

When starting a PV domain, xend will create a console device if one is
not specified in the domain's config.  Details of the device are added
to the domain's config and, if the domain is managed, written to xend's
internal "db".  All of this occurs after the console details are written
to xenstore, so life is good for qemu backend reading xenstore.  If the
managed domain is subsequently stopped and started again, the console
device, now included in the domain's device refs, is created before
console info is written to xenstore.  The console backend in qemu fails
to read xenstore, causing con_init() to fail.  Meanwhile the frontend in
domU is waiting for backend and booting does not progress.  In
pseudo-operations

create_domain
for each device in device_refs: # no console device in device_refs
  create_device
write_device_info_to_xenstore
update_consoles
  # Console device found in xenstore.  If it does not exist in
  # domain device refs, add it and call DevController.createDevice
..
shutdown_domain
create_domain
for each device in device_refs: # now contains console device
  create_device # device created before info written to xenstore
write_device_info_to_xenstore

As a workaround, I've patched con_init() in
tools/ioemu-dir/hw/xen_console.c to retry xenstore read.  I suspect xend
could be patched to write required console details to xenstore before
creating the console device.  But the current behavior in xend has not
changed since Xen 3.3, the last version I found that doesn't exhibit
this issue.  The console code in qemu did change significantly between
3.3 and 3.4 however.

Any comments regarding a fix in xend vs qemu?  Perhaps alternate
solutions to this race?

Also noteworthy is that the issue does not appear when using 'ol
xenconsoled, i.e. removing vfb entry in domain config.

Regards,
Jim

                 reply	other threads:[~2010-01-22  0:51 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4B58F678.5060608@novell.com \
    --to=jfehlig@novell.com \
    --cc=xen-devel@lists.xensource.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.