>>> On 21.12.18 at 11:26, <[email protected]> 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. Or otherwise failure here ought to lead to failure of deassign-device, rather than (e.g.) an infinite loop. Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
