Re: [Xen-devel] [PATCH v4 1/3] xen/pt: fix some pass-thru devices don't work across reboot

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Dec 21, 2018 at 03:32:47AM -0700, Jan Beulich wrote:
> >>> On 21.12.18 at 11:26, <roger.pau@xxxxxxxxxx> wrote:
> > On Fri, Dec 21, 2018 at 03:13:50AM -0700, Jan Beulich wrote:
> >> But then again I'm still not fully convinced that a hypervisor
> >> change is the right course of action here in the first place. It
> >> would be better if the hypervisor had to just verify that all
> >> IRQ mappings are gone, or else fail the de-assignment of the
> >> device.
> > 
> > The only component (except the hypervisor) that knows about such
> > assignments is QEMU, and in the case of a QEMU crash the host would be
> > left with a device that cannot be de-assigned, because the information
> > about the PIRQ bindings in lost due to the QEMU crash.
> > 
> > IMO Xen needs to be capable of cleaning any bindings and mappings done
> > by the toolstack or the device model in order to be able to correctly
> > recover from a device model or toolstack crash.
> 
> But possibly with tool stack assistance: Rather than doing it (in a
> potentially fragile way, as per my other comments) as an integral
> part of deassign-device, it could be a separate domctl to be
> issued first.

I don't have a strong opinion whether a new hypercall would be better
than just hooking this logic into the current deassign hypercall, as
long as it's robust.

> Or otherwise failure here ought to lead to failure of
> deassign-device, rather than (e.g.) an infinite loop.

Yes, I fully agree it needs to be robust, ideally the
unbinding/unmapping should always succeed, or at least don't get stuck
into an infinite loop.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel