[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.
smime.p7s
Description: S/MIME cryptographic signature
- Re: [PATCH v2 05/24] hw/xen: fix XenStore watch delivery to guest, (continued)
[PATCH v2 19/24] hw/i386/pc: support '-nic' for xen-net-device, David Woodhouse, 2023/10/19
[PATCH v2 11/24] hw/xen: automatically assign device index to block devices, David Woodhouse, 2023/10/19
[PATCH v2 15/24] hw/xen: add support for Xen primary console in emulated mode, David Woodhouse, 2023/10/19
[PATCH v2 03/24] hw/xen: select kernel mode for per-vCPU event channel upcall vector, David Woodhouse, 2023/10/19
[PATCH v2 12/24] hw/xen: add get_frontend_path() method to XenDeviceClass, David Woodhouse, 2023/10/19
[PATCH v2 07/24] hw/xen: Clean up event channel 'type_val' handling to use union, David Woodhouse, 2023/10/19
[PATCH v2 04/24] hw/xen: don't clear map_track[] in xen_gnttab_reset(), David Woodhouse, 2023/10/19
[PATCH v2 08/24] include: update Xen public headers to Xen 4.17.2 release, David Woodhouse, 2023/10/19