Messages in this thread | | | From | Andrew Cooper <> | Subject | Re: [PATCH] xen: Allow platform PCI interrupt to be shared | Date | Wed, 18 Jan 2023 14:22:41 +0000 |
| |
On 18/01/2023 2:06 pm, David Woodhouse wrote: > 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 <dwmw@amazon.co.uk> >>> --- >>> 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?
There is no actual thing called PVHVM. That diagram has caused far more damage than good...
There's HVM (and by this, I mean the hypervisor's interpretation meaning VT-x or SVM), and a spectrum of things the guest kernel can do if it desires.
I'm pretty sure Linux knows all of them.
~Andrew
| |