qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 16/24] hw/xen: handle soft reset for primary console


From: David Woodhouse
Subject: Re: [PATCH v2 16/24] hw/xen: handle soft reset for primary console
Date: Tue, 24 Oct 2023 19:38:16 +0100
User-agent: Evolution 3.44.4-0ubuntu2

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@amazon.co.uk>
> > > > 
> > > > 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]