Re: [Xen-devel] [Xen-users] DomU fails to reboot with storage driver domain

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel