linux-kernel - Re: [PATCH] xen: Allow platform PCI interrupt to be shared

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <973f9ebd-173e-6753-7799-a660994e38de@citrix.com>
Date:   Wed, 18 Jan 2023 14:22:41 +0000
From:   Andrew Cooper <Andrew.Cooper3@...rix.com>
To:     David Woodhouse <dwmw2@...radead.org>,
        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 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@...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?

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