On Wed, 2023-01-18 at 13:53 +0000, Andrew Cooper wrote: > On 18/01/2023 12:22 pm, David Woodhouse wrote: > > Signed-off-by: David Woodhouse <[email protected]> > > --- > > What does xen_evtchn_do_upcall() exist for? Can we delete it? I don't > > see it being called anywhere. > > Seems the caller was dropped by > cb09ea2924cbf1a42da59bd30a59cc1836240bcb, but the CONFIG_PVHVM looks > bogus because the precondition to setting it up was being in a Xen HVM > guest, and the guest is taking evtchns by vector either way. > > PV guests use the entrypoint called exc_xen_hypervisor_callback which > really ought to gain a PV in its name somewhere. Also the comments look > distinctly suspect.
Yeah. I couldn't *see* any asm or macro magic which would reference xen_evtchn_do_upcall, and removing it from my build (with CONFIG_XEN_PV enabled) also didn't break anything. > Some tidying in this area would be valuable. Indeed. I just need Paul or myself to throw in a basic XenStore implementation so we can provide a PV disk, and I should be able to do quickfire testing of PV guests too with 'qemu -kernel' and a PV shim. PVHVM would be an entertaining thing to support too; I suppose that's mostly a case of basing it on the microvm qemu platform, or perhaps even *more* minimal x86-based platform?
smime.p7s
Description: S/MIME cryptographic signature
