[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <82e6a68f3cb8c0e440f7dc848fa3444725b3f893.camel@infradead.org>
Date: Wed, 18 Jan 2023 14:06:40 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Andrew Cooper <Andrew.Cooper3@...rix.com>,
Juergen Gross <jgross@...e.com>,
Stefano Stabellini <sstabellini@...nel.org>,
xen-devel <xen-devel@...ts.xenproject.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Paul Durrant <paul@....org>
Subject: Re: [PATCH] xen: Allow platform PCI interrupt to be shared
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@...zon.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?
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)
Powered by blists - more mailing lists