Re: [Xen-devel] [PATCH xen v2] xen: arm: fully implement multicall interface.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-04-08 at 12:29 +0100, Jan Beulich wrote:
> >>> On 08.04.14 at 13:18, <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Tue, 2014-04-08 at 08:13 +0100, Jan Beulich wrote:
> >> But then again - is there anything wrong with actually carrying
> >> out the multicall (with truncated arguments), resulting in the
> >> domain dying only slightly later?
> > 
> > My concern was that this truncation happens naturally when running on a
> > 32-bit hypervisor (since the actual hypercall implementations take
> > 32-bit arguments internally). Meaning that the issue would be hidden
> > until you move that kernel to a 64-bit hypervisor (with 64-bit hypercall
> > arguments internally) at which point it mysteriously starts failing
> > because some previously unnoticed garbage shows up in the top half of
> > the argument.
> 
> Right - I understand all that. I wasn't suggesting to remove the
> domain_crash(), just that by using the non-synchronous variant
> you'd get the crash at the end of the multicall (or when it gets
> preempted) instead of at the beginning. The effect to the guest
> and programmer should be the same - the guest is dead and the
> programmer (hopefully) goes looking for the problem.

My concern here was that the rest of the multicall might have relied on
the op which we failed and there might be a tonne of log spew which
would obscure the original failure.

On the other hand if that can happen then the guest could deliberately
trigger log spew, which would be bad anyway...

It does seem like it would be reasonably simple to add a success/abort
return value to {do,compat}_multicall_call (probably by making into
static inline on x86) and have do_multicall just abort the rest of the
multicall in that case.

Actually, you mentioned preempt. Does calling domain_crash() cause
hypercall_preempt_check to return true? In that case do_multicall
already does the right thing. That would involve domain_crash either
causing a softirq or an evtchn upcall, which I don't see it doing
though. Perhaps just adding a d->is_shutting_down check alongside the
preempt check in the multicall would do the trick.

Ian.


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