All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: boris.ostrovsky@oracle.com, x86@kernel.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	 Paul Durrant <pdurrant@amazon.com>,
	jgrall@amazon.com, karahmed@amazon.de,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 5/5] x86/xen: Don't register PV spinlock IPI when it isn't going to be used
Date: Tue, 05 Jan 2021 01:41:43 +0000	[thread overview]
Message-ID: <575e71c6f0bb672770390d45a0218d3064ce4860.camel@infradead.org> (raw)
In-Reply-To: <1cf261fd-0062-8bc5-c3de-53b281accb82@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]

On Mon, 2021-01-04 at 18:44 -0500, boris.ostrovsky@oracle.com wrote:
> On 1/4/21 6:19 PM, David Woodhouse wrote:
> > On Mon, 2021-01-04 at 18:04 -0500, boris.ostrovsky@oracle.com
> > wrote:
> > > Why not xen_hvm_cpu_die too? common_cpu_die() sounds like something
> > > we should do, and the other three we call there will be nops.
> > 
> > native_cpu_die() calls that, and isn't that the function that gets
> > installed if we don't install our own?
> 
> 
> True.
> 
> 
> Still, a Xen guest should call Xen-specific cpu_die() routine if
> possible. Especially since (now) other cpu (i.e. non-IPI) ops will
> call Xen versions.

But as you said, the other three things that xen_hvm_cpu_die() does are
all no-ops (or at least we'd have to make them no-ops; I haven't
checked). I don't see the point in calling it, only for it to do
nothing.

> 
> > 
> > > >  	smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi;
> > > >  	smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi;
> > > > -	smp_ops.smp_prepare_boot_cpu = xen_hvm_smp_prepare_boot_cpu;
> > > > -	smp_ops.smp_cpus_done = xen_smp_cpus_done;
> > > >  }
> > > > 
> > > > > Also, for the spinlock changes specifically --- I wonder whether it
> > > > > would be better to reverse initial value of xen_pvspin and set it to
> > > > > 'true' only if initialization succeeds.
> > > > 
> > > > I looked at that but it would need to be tristate, since the
> > > > 'xen_nopvspin' command line option clears it from its default of being
> > > > enabled.
> > > 
> > > Ah, right. How about setting nopvspin in xen_parse_nopvspin()?
> > 
> > That would make the xen_nopvspin command line option disable PV
> > spinlocks even under KVM.
> 
> 
> xen_nopvspin is deprecated and nopvspin is recommended anyway so I think it should be OK, no?

They do different things. If someone has an image (which might run on
both Xen and KVM) which has xen_nopvspin, we don't suddenly want that
to start disabling PV spinlocks on KVM too.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

  reply	other threads:[~2021-01-05  1:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-24 11:53 [PATCH 0/5] Xen INTX/GSI event channel delivery fixes David Woodhouse
2020-12-24 11:53 ` [PATCH 1/5] xen: Fix event channel callback via INTX/GSI David Woodhouse
2021-01-04 16:35   ` boris.ostrovsky
2020-12-24 11:53 ` [PATCH 2/5] xen: Set platform PCI device INTX affinity to CPU0 David Woodhouse
2021-01-04 16:42   ` boris.ostrovsky
2020-12-24 11:53 ` [PATCH 3/5] x86/xen: Add a no_vector_callback option to test PCI INTX delivery David Woodhouse
2021-01-04 16:44   ` boris.ostrovsky
2020-12-24 11:53 ` [PATCH 4/5] x86/xen: Don't register Xen IPIs when they aren't going to be used David Woodhouse
2021-01-04 16:50   ` boris.ostrovsky
2021-01-04 17:29     ` David Woodhouse
2020-12-24 11:53 ` [PATCH 5/5] x86/xen: Don't register PV spinlock IPI when it isn't " David Woodhouse
2021-01-04 17:06   ` boris.ostrovsky
2021-01-04 17:32     ` David Woodhouse
2021-01-04 19:06       ` boris.ostrovsky
2021-01-04 20:51         ` David Woodhouse
2021-01-04 22:09           ` boris.ostrovsky
2021-01-04 22:37             ` David Woodhouse
2021-01-04 23:04               ` boris.ostrovsky
2021-01-04 23:19                 ` David Woodhouse
2021-01-04 23:44                   ` boris.ostrovsky
2021-01-05  1:41                     ` David Woodhouse [this message]
2021-01-05 14:45                       ` boris.ostrovsky
2021-01-05 15:29                         ` David Woodhouse

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=575e71c6f0bb672770390d45a0218d3064ce4860.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jgrall@amazon.com \
    --cc=jgross@suse.com \
    --cc=karahmed@amazon.de \
    --cc=pdurrant@amazon.com \
    --cc=sstabellini@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.