[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/vcpu: Sanitise VCPUOP_initialise call hierachy


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Julien Grall <Julien.Grall@xxxxxxx>
  • Date: Thu, 31 Oct 2019 21:25:23 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qtijWd1TxBAcoE9iGkUpm6wBjxyTh9jt8dz1vRibbIw=; b=BfjYwKo2z4sc2GK1Om4RCFAZc0322mOCTBpHgZSawvr7nbEcCFKF3lrLNRU+vvBmylECPdN/7JVYmdy3KQjuMCWPWbTb0D/LwEhLp8r8Gt5+xQ6CgW4UWh6ZwE/x+EuDVQHCCnBek4LzRjGEW7U/Jt9gb1bS2rzYcMnvEOaun7OEtOzfC4NBCu5zexf2uEJunyRUiOrKwq6r+MUEccyqFTbp+DwVBSUvJB3dOy+dnIg5BnwR7vRuJ4kJPGvPP6WvVH/KTR4y0nEOhq01KHfLETfNlJBhqJ0Lz56OQ3et0D26yrgPdSkEE12nRkRydCUdWP9OXGfHXM1iSiItlN6Xcw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H6BmvO6uY3YHFJF0W72z1YFUSIN91zCZzDAa+NNB6Rfu3z+HQOAoo0dTi8+LRxjv6vFNCMEYvcfnHR5E7Kq2BnJRDSNuBSDHFCx1+aUHSEwGmSy+6/1FD6kBoRWBGbhIRtHdVST6cKnMlDXAA/qBPBrD4QdScFF7vXHrlmD83AsjzXaBaxl8nbP7InOMRlzGQ1PEiLy5uPObEgh37kWoH8siKKPivsrwUx+8PMd9NIqyab6QhMJ0MggEVhaSWGbzzUhSppYfrsoX4EU79nx8X2rIhF6hvBigEdX1t619RpOTFSVtdGFzvkBWntCvkglMnujoVHYnX/e2goyB/bH1YQ==
  • Authentication-results: spf=fail (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=none action=none header.from=arm.com;
  • Authentication-results-original: spf=none (sender IP is ) smtp.mailfrom=Julien.Grall@xxxxxxx;
  • Cc: Juergen Gross <jgross@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, nd <nd@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 31 Oct 2019 21:25:47 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: True
  • Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Julien.Grall@xxxxxxx;
  • Thread-index: AQHVkCF8KTaPg/jFk0KydVsCruQGrKd1QyQA
  • Thread-topic: [Xen-devel] [PATCH] xen/vcpu: Sanitise VCPUOP_initialise call hierachy

Hi,

On 31/10/2019 19:28, Andrew Cooper wrote:
> This code is especially tangled.  VCPUOP_initialise calls into
> arch_initialise_vcpu() which calls back into default_initialise_vcpu() which
> is common code.
> 
> This path is actually dead code on ARM, because VCPUOP_initialise is filtered
> out by do_arm_vcpu_op().
> 
> The only valid way to start a secondary CPU on ARM is via the PSCI interface.
> The same could in principle be said about INIT-SIPI-SIPI for x86 HVM, if HVM
> guests hadn't already interited a paravirt way of starting CPUs.
> 
> Either way, it is quite likely that no future architectures implemented in Xen
> are going to want to use a PV interface, as some standardised (v)CPU bringup
> mechanism will already exist.

I am not sure I agree here. Looking at Linux RISCv code (see [1] and 
[2]), it looks like the kernel has to deal with selecting one "lucky" 
CPU/hart to deal with the boot and park all the others.

So it looks like to me there are nothing at the moment on RISCv to do 
(v)CPU bring-up. We might be able to use PSCI (although this is an ARM 
specific way), but would rather wait and see what RISCv folks come up 
with before deciding PV is never going to be used.

Cheers,

[1] 
https://elixir.bootlin.com/linux/v5.4-rc5/source/arch/riscv/kernel/head.S
[2] 
https://elixir.bootlin.com/linux/v5.4-rc5/source/arch/riscv/kernel/smpboot.c

-- 
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.