All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Alex Velazquez <alex.j.velazquez@gmail.com>,
	xen-users@lists.xen.org, wei.liu2@citrix.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [Xen-users] DomU fails to reboot with storage driver domain
Date: Fri, 1 Apr 2016 13:07:07 +0100	[thread overview]
Message-ID: <20160401120707.GA26629@citrix.com> (raw)
In-Reply-To: <alpine.OSX.2.20.1604011304340.9476@mac>

On Fri, Apr 01, 2016 at 01:04:42PM +0200, Roger Pau Monné wrote:
> Hello,
> 
> I've been able to reproduce this locally using the latest Xen unstable, 
> and it is indeed a bug. The issue happens because libxl compares the JSON 
> status with the list of backends it fetches from Domain 0 only, and then 
> if the domain is using backends from a driver domain, it is not able to 
> find those entries on Domain 0 and discards them. As an example 
> libxl__append_disk_list_of_type hardcodes the backend path of Domain 0 as 
> the only search path.

This is the real bug. I think libxl__append_disk_list_of_type should not
hardcode 0 since we support backend domain other than 0.  The problem
you discovered is not specific to disk device. Nic and channel have the
same problem, too.

> 
> TBH, I don't see an easy way to solve this, I've thought about fetching 
> the "backend" node from the xenstore frontend path of each device, but 
> that's not safe since the guest can modify those entries.
> 

Interrogating frontend  is not entirely unsafe because we can validate
that path before reading from it. There is also a backend-id field that
we can use if that make validation easier -- no need to parse a frontend
provided string.

Another fix is to fetch all backend domain name / domid from JSON, then
fetch all xenstore backend entries. This is safe because JSON is not
controlled by guest. This might require adding locks to multiple APIs,
but luckily that wouldn't change their semantics.

Ian, do you have better ideas?

> Since it's not clear to me, why do we need to check the JSON internal data 
> against the devices on xenstore? Is there a possibility that they became 
> out of sync?
> 

The possibility that they go out of sync is exactly why we need to have
primary reference. In this case, the primary reference is xenstore.

Wei.

> Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-04-01 12:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CALhSYYRek3PeJyJEVNSLFE6WCbkDc3n+Qj6L5XYwQKkMgthqPw@mail.gmail.com>
     [not found] ` <alpine.OSX.2.20.1603231152520.753@mac>
     [not found]   ` <CALhSYYQLPdEZ-pSBdUjKDWnNsmF95zu9t=T7zGZ69Vb1S1hwWg@mail.gmail.com>
2016-04-01 11:04     ` [Xen-users] DomU fails to reboot with storage driver domain Roger Pau Monné
2016-04-01 12:07       ` Wei Liu [this message]
2016-04-01 13:43         ` Ian Jackson
2016-04-01 13:54           ` Wei Liu
2016-04-12 20:05             ` Alex Velazquez

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=20160401120707.GA26629@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=alex.j.velazquez@gmail.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xen-users@lists.xen.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 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.