lkml.org 
[lkml]   [2023]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] xen: Allow platform PCI interrupt to be shared
From
Date
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@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...

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?

[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2023-03-26 23:46    [W:0.209 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site