Re: [PATCH 0/2] Xen/mem_event: Do not rely on the toolstack being bug-free

[Andrew Cooper <andrew.cooper3@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1605 bytes --]

On 17/07/2014 23:17, Tamas Lengyel wrote:
> I've also tested the patch with LibVMI and everything works fine. The
> pause/unpause reference count now does take effect, so the previous
> issue I reported (a paused domain getting unpaused by
> mem_event_enable) is fixed by this patch.
>
> One question I have, what if the toolstack wants to unconditionally
> (force) unpause a domain? Right now with this patch if someone runs
> 'xl pause domain' a couple times he has no other recourse then to
> issue 'xl unpause domain' at least the same number of times, or to
> restart the entire domain. Might be user-friendlier if there was an
> override provided in case a domain got paused a million times by accident.
>
> Cheers,
> Tamas

I don't think that would be a good idea.  The entire point of the proper
refcounting is so bits of toolstack subsystems can guarentee that the
domain stays paused during a critical set of operations.  Providing a
"DOMCTL_unpausedomain --force" would undermine the whole purpose of this.

As already expressed, there are plenty of ways a buggy/dumb toolstack
can shoot itself in the foot with regards to a domain.  I include in
this users with dom0 root access and `xl`.

The two key points are that:

1) a buggy toolstack can't cause Xen perform an unintentional action
(e.g. walking off the end of an array, as demonstrated in patch 1 of
this series) and
2) several non-buggy parts of a toolstack can operate safely together
with respect to a Xen resource.

Any attempt to work around a buggy bit of a toolstack in Xen is effort
better spent fixing the toolstack.

~Andrew

[-- Attachment #1.2: Type: text/html, Size: 2455 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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