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.