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

[Andrew Cooper]

On 18/01/2023 2:26 pm, David Woodhouse wrote:
> 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?

That also exists and works fine (and is one slice on the spectrum).  KVM
even borrowed our PVH boot API because we'd already done the hard work
in Linux.

~Andrew