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

[Wei Liu <wei.liu2@citrix.com>]

On Fri, Apr 01, 2016 at 02:43:32PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-users] DomU fails to reboot with storage driver domain"):
> > On Fri, Apr 01, 2016 at 01:04:42PM +0200, Roger Pau Monné wrote:
> > > 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?
> 
> Either of these two approaches sound good.
> 
> I'm not sure why using the JSON domid would need any additional
> locking.  The code here already has the JSON in its hand, doesn't it ?
> But using the domain _name_ rather than the domid is wrong, and I
> think the JSON might have only the name.
> 

The APIs that retrieve lists of devices will need to lock JSON config
as well, which they don't currently do because they only reference
xenstore.

> I think the xenstore approach is probably better.  I think it may be
> best to use (with checking) the frontend's backend path, since ideally
> we would find the corresponding device entry directly.
> 
> But I am happy with whatever is most convenient.
> 

Interrogating frontend is more convenient.

> I think we should fix this for 4.7 and the fix is a bugfix so OK to go
> in after the freeze.
> 

Yes, it's a bug that should be fixed. I can give it a stab next week
when I'm back in office unless someone else beats me to it.

Wei.

> Ian.

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