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

[Alex Velazquez <alex.j.velazquez@xxxxxxxxx>]

On Fri, Apr 1, 2016 at 9:54 AM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> 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.

Hi all,

Not sure that there's any further information I can provide to help
with this, as it sounds like a viable solution has been proposed.
However, if/when there is a patch available, I am happy to test it out
on my end.

Thanks,
Alex

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