mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Jane Malalane <Jane.Malalane@citrix.com>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Juergen Gross <jgross@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Maximilian Heyne <mheyne@amazon.de>,
	Jan Beulich <jbeulich@suse.com>,
	Colin Ian King <colin.king@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86/xen: Add support for HVMOP_set_evtchn_upcall_vector
Date: Fri, 15 Jul 2022 09:10:58 -0400	[thread overview]
Message-ID: <3be61417-6e58-1d9f-dd3c-7de00daa8d0a@oracle.com> (raw)
In-Reply-To: <01cc9e39-242a-3cbf-13b3-cb3ecccd5737@citrix.com>


On 7/15/22 5:50 AM, Andrew Cooper wrote:
> On 15/07/2022 09:18, Jane Malalane wrote:
>> On 14/07/2022 00:27, Boris Ostrovsky wrote:
>>>>        xen_hvm_smp_init();
>>>>        WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_hvm, xen_cpu_dead_hvm));
>>>> diff --git a/arch/x86/xen/suspend_hvm.c b/arch/x86/xen/suspend_hvm.c
>>>> index 9d548b0c772f..be66e027ef28 100644
>>>> --- a/arch/x86/xen/suspend_hvm.c
>>>> +++ b/arch/x86/xen/suspend_hvm.c
>>>> @@ -5,6 +5,7 @@
>>>>    #include <xen/hvm.h>
>>>>    #include <xen/features.h>
>>>>    #include <xen/interface/features.h>
>>>> +#include <xen/events.h>
>>>>    #include "xen-ops.h"
>>>> @@ -14,6 +15,23 @@ void xen_hvm_post_suspend(int suspend_cancelled)
>>>>            xen_hvm_init_shared_info();
>>>>            xen_vcpu_restore();
>>>>        }
>>>> -    xen_setup_callback_vector();
>>>> +    if (xen_ack_upcall) {
>>>> +        unsigned int cpu;
>>>> +
>>>> +        for_each_online_cpu(cpu) {
>>>> +            xen_hvm_evtchn_upcall_vector_t op = {
>>>> +                    .vector = HYPERVISOR_CALLBACK_VECTOR,
>>>> +                    .vcpu = per_cpu(xen_vcpu_id, cpu),
>>>> +            };
>>>> +
>>>> +            BUG_ON(HYPERVISOR_hvm_op(HVMOP_set_evtchn_upcall_vector,
>>>> +                         &op));
>>>> +            /* Trick toolstack to think we are enlightened. */
>>>> +            if (!cpu)
>>>> +                BUG_ON(xen_set_callback_via(1));
>>> What are you trying to make the toolstack aware of? That we have *a*
>>> callback (either global or percpu)?
>> Yes, specifically for the check in libxl__domain_pvcontrol_available.
> And others.
>
> This is all a giant bodge, but basically a lot of tooling uses the
> non-zero-ness of the CALLBACK_VIA param to determine whether the VM has
> Xen-aware drivers loaded or not.
>
> The value 1 is a CALLBACK_VIA value which encodes GSI 1, and the only
> reason this doesn't explode everywhere is because the
> evtchn_upcall_vector registration takes priority over GSI delivery.
>
> This is decades of tech debt piled on top of tech debt.


Feels like it (setting the callback parameter) is something that the hypervisor should do --- no need to expose guests to this.


-boris


  reply	other threads:[~2022-07-15 13:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-11 15:22 Jane Malalane
2022-07-13 23:27 ` Boris Ostrovsky
2022-07-15  8:18   ` Jane Malalane
2022-07-15  9:50     ` Andrew Cooper
2022-07-15 13:10       ` Boris Ostrovsky [this message]
2022-07-18  8:56         ` Andrew Cooper
2022-07-18 13:59           ` Boris Ostrovsky
2022-07-25 10:03             ` Jane Malalane
2022-07-25 20:46               ` Boris Ostrovsky
2022-07-26 12:54                 ` Jane Malalane
2022-07-25 10:08             ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3be61417-6e58-1d9f-dd3c-7de00daa8d0a@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=Jane.Malalane@citrix.com \
    --cc=bp@alien8.de \
    --cc=colin.king@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mheyne@amazon.de \
    --cc=mingo@redhat.com \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=sstabellini@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®