[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] xen: Allow platform PCI interrupt to be shared
On Wed, 2023-01-18 at 14:22 +0000, Andrew Cooper wrote: > 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@xxxxxxxxxxxx> > > > > --- > > > > 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... Perhaps so. Even CONFIG_XEN_PVHVM in the kernel is a nonsense, because it's just automatically set based on (XEN && X86_LOCAL_APIC). And CONFIG_XEN depends on X86_LOCAL_APIC anyway. Which is why isn't never mattered that the vector callback handling was under #ifdef CONFIG_XEN_PVHVM not just CONFIG_XEN. > 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. But don't we want to refrain from providing the legacy PC platform devices? Attachment:
smime.p7s
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |