All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Kouya Shimura <kouya@jp.fujitsu.com>
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: [PATCH] xend: notify xenpv device model that console info is ready
Date: Tue, 23 Feb 2010 10:02:46 -0500	[thread overview]
Message-ID: <20100223150246.GE25741@phenom.dumpdata.com> (raw)
In-Reply-To: <7k7hq4ph63.fsf@pingu.sky.yk.fujitsu.co.jp>

On Tue, Feb 23, 2010 at 04:03:48PM +0900, Kouya Shimura wrote:
Content-Description: message body text
> Sometimes PV domain with vfb doesn't boot up. /sbin/kudzu is stuck.
> After investigation, I've found that the evtchn for console is not
> bound at all.
> 
> Normal sequence of evtchn initialization in qemu-dm for xenpv is:
> 1) watch xenstore backpath (/local/domain/0/backend/console/<domid>/0)
> 2) read console info (/local/domain/<domid>/console/{type, ring-ref, port..})
> 3) bind the evtchn to the port.
> 
> But in some case, xend writes to the backpath before the console info

Would it be better to fix the race condition?

> is prepared, and never write to the backpath again. So the qemu-dm fails
> at 2) and never reach to 3).
> 
> When this happens, manually xenstore-write command on Domain-0
> resumes the guest.
> 
> Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
> 

> diff -r 4ba4323889b9 tools/python/xen/xend/XendDomainInfo.py
> --- a/tools/python/xen/xend/XendDomainInfo.py	Mon Feb 22 18:47:22 2010 +0000
> +++ b/tools/python/xen/xend/XendDomainInfo.py	Tue Feb 23 14:50:40 2010 +0900
> @@ -1642,6 +1642,11 @@ class XendDomainInfo:
>                  console_uuid = serial_consoles[0].get('uuid')
>                  self.info.console_update(console_uuid, 'location',
>                                           self.console_port)
> +                # Notify xenpv device model that console info is ready
> +                if not self.info.is_hvm() and self.info.has_rfb():
> +                    console_ctrl = self.getDeviceController('console')
> +                    # The value is unchanged. Just for xenstore watcher
> +                    console_ctrl.writeBackend(0, 'uuid', console_uuid)
>                  
>  
>          # Update VNC port if it exists and write to xenstore

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

  reply	other threads:[~2010-02-23 15:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-23  7:03 [PATCH] xend: notify xenpv device model that console info is ready Kouya Shimura
2010-02-23 15:02 ` Konrad Rzeszutek Wilk [this message]
2010-02-24  3:59   ` Kouya Shimura

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=20100223150246.GE25741@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=kouya@jp.fujitsu.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.