On Tue, 2023-10-24 at 17:22 +0100, Paul Durrant wrote: > On 24/10/2023 16:48, David Woodhouse wrote: > > On Tue, 2023-10-24 at 16:44 +0100, Paul Durrant wrote: > > > On 19/10/2023 16:40, David Woodhouse wrote: > > > > From: David Woodhouse <dwmw@xxxxxxxxxxxx> > > > > > > > > On soft reset, the prinary console event channel needs to be rebound to > > > > the backend port (in the xen-console driver). We could put that into the > > > > xen-console driver itself, but it's slightly less ugly to keep it within > > > > the KVM/Xen code, by stashing the backend port# on event channel reset > > > > and then rebinding in the primary console reset when it has to recreate > > > > the guest port anyway. > > > > > > Does Xen re-bind the primary console on EVTCHNOP_reset? That's news to > > > me. I go check. > > > > I spent an unhapp hour trying to work out how Xen actually does any of > > this :) > > > > In the short term I'm more interested in having soft reset work, than > > an explicit EVTCHNOP_reset. And I can't work out *how*, but we do seem > > to have console again after a kexec in real Xen. > > *Soft* reset may do it, but not the EVTCHNOP_reset hypercall itself, > because there's a bunch of impenetrable toolstack magic involved the > former. Perhaps you could just push the re-bind code up a layer into > kvm_xen_soft_reset(). Actually, all we're doing here is *storing* the be_port so that the *console* reset code can later connect to it. So the actual reconnect is already called separately from a layer up in kvm_xen_soft_reset(). If the guest just calls EVTCHNOP_reset then it'll just get the event channels reset and the console *won't* reconnect. Actually.. if the guest just calls EVTCHNOP_reset I think they'll just hit the assert(qemu_mutex_iothread_locked()) at line 1109. We need a QEMU_IOTHREAD_LOCK_GUARD() in the penultimate line of xen_evtchn_reset_op(). I'll fix that separately.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
