From: Will Deacon <hidden> Date: 2012-12-17 16:35:35
Hello again,
This is version two of the patches originally posted here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/135870.html
Given the lively discussion sparked in that thread, there have been a
fair number of changes since the RFC:
* A client-side implementation of PSCI and proposed DT binding
* Use of PSCI for SMP boot
* Removal of the SMP pen code
* Dropped the RFC tag
Marc hacked up the KVM side separately and this has been tested
successfully with his code using a magic build of kvmtool.
As usual, all feedback welcome.
Cheers,
Will
Marc Zyngier (1):
ARM: Dummy Virtual Machine platform support
Will Deacon (5):
ARM: opcodes: add missing include of linux/linkage.h
ARM: opcodes: add opcodes definitions for ARM security extensions
ARM: psci: add devicetree binding for describing PSCI firmware
ARM: psci: add support for PSCI invocations from the kernel
ARM: mach-virt: add SMP support using PSCI
Documentation/devicetree/bindings/arm/psci.txt | 58 +++++++
arch/arm/Kconfig | 12 ++
arch/arm/Makefile | 1 +
arch/arm/include/asm/opcodes-sec.h | 24 +++
arch/arm/include/asm/opcodes.h | 1 +
arch/arm/include/asm/psci.h | 36 +++++
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/psci.c | 214 +++++++++++++++++++++++++
arch/arm/mach-virt/Kconfig | 10 ++
arch/arm/mach-virt/Makefile | 6 +
arch/arm/mach-virt/platsmp.c | 76 +++++++++
arch/arm/mach-virt/virt.c | 71 ++++++++
12 files changed, 510 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/psci.txt
create mode 100644 arch/arm/include/asm/opcodes-sec.h
create mode 100644 arch/arm/include/asm/psci.h
create mode 100644 arch/arm/kernel/psci.c
create mode 100644 arch/arm/mach-virt/Kconfig
create mode 100644 arch/arm/mach-virt/Makefile
create mode 100644 arch/arm/mach-virt/platsmp.c
create mode 100644 arch/arm/mach-virt/virt.c
--
1.8.0
From: Will Deacon <hidden> Date: 2012-12-17 16:35:36
opcodes.h wants to declare an asmlinkage function, so we need to include
linux/linkage.h
Acked-by: Dave Martin <redacted>
Signed-off-by: Will Deacon <redacted>
---
arch/arm/include/asm/opcodes.h | 1 +
1 file changed, 1 insertion(+)
From: Will Deacon <hidden> Date: 2012-12-17 16:35:37
The ARM security extensions introduced the smc instruction, which is not
supported by all versions of GAS.
This patch introduces opcodes-sec.h, so that smc is made available in a
similar manner to hvc.
Acked-by: Dave Martin <redacted>
Signed-off-by: Will Deacon <redacted>
---
arch/arm/include/asm/opcodes-sec.h | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 arch/arm/include/asm/opcodes-sec.h
@@ -0,0 +1,58 @@+* Power State Coordination Interface (PSCI)++Firmware implementing the PSCI functions described in ARM document number+ARM DEN 0022A ("Power State Coordination Interface System Software on ARM+processors") can be used by Linux to initiate various CPU-centric power+operations.++Issue A of the specification describes functions for CPU suspend, hotplug+and migration of secure software.++Functions are invoked by trapping to the privilege level of the PSCI+firmware (specified as part of the binding below) and passing arguments+in a manner similar to that specified by AAPCS:++ r0 => 32-bit Function ID / return value+ {r1 - r3} => Parameters++Note that the immediate field of the trapping instruction must be set+to #0.+++Main node required properties:++ - compatible : Must be "arm,psci"++ - method : The method of calling the PSCI firmware. Permitted+ values are:++ "smc" : SMC #0, with the register assignments specified+ in this binding.++ "hvc" : HVC #0, with the register assignments specified+ in this binding.++ - function-base : The base ID from which the functions are offset.++Main node optional properties:++ - cpu_suspend : Offset of CPU_SUSPEND ID from function-base++ - cpu_off : Offset of CPU_OFF ID from function-base++ - cpu_on : Offset of CPU_ON ID from function-base++ - migrate : Offset of MIGRATE ID from function-base+++Example:++ psci {+ compatible = "arm,psci";+ method = "smc";+ function-base = <0x95c1ba5e>;+ cpu_suspend = <0>;+ cpu_off = <1>;+ cpu_on = <2>;+ migrate = <3>;+ };
From: Will Deacon <hidden> Date: 2012-12-17 16:35:39
This patch adds support for the Power State Coordination Interface
defined by ARM, allowing Linux to request CPU-centric power-management
operations from firmware implementing the PSCI protocol.
Signed-off-by: Will Deacon <redacted>
---
arch/arm/Kconfig | 10 +++
arch/arm/include/asm/psci.h | 36 ++++++++
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/psci.c | 214 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 261 insertions(+)
create mode 100644 arch/arm/include/asm/psci.h
create mode 100644 arch/arm/kernel/psci.c
@@ -1611,6 +1611,16 @@ config HOTPLUG_CPUSayYheretoexperimentwithturningCPUsoffandon.CPUscanbecontrolledthrough/sys/devices/system/cpu.+configARM_PSCI+bool"Support for the ARM Power State Coordination Interface (PSCI)"+depends onCPU_V7+help+SayYhereifyouwantLinuxtocommunicatewithsystemfirmware+implementingthePSCIspecificationforCPU-centricpower+managementoperationsdescribedinARMdocumentnumberARMDEN+0022A("PowerStateCoordinationInterfaceSystemSoftwareon+ARMprocessors").+configLOCAL_TIMERSbool"Use local timer interrupts"depends onSMP
From: Will Deacon <hidden> Date: 2012-12-17 16:35:40
From: Marc Zyngier <redacted>
Add support for the smallest, dumbest possible platform, to be
used as a guest for KVM or other hypervisors.
It only mandates a GIC and architected timers. Fits nicely with
a multiplatform zImage. Uses very little silicon area.
Signed-off-by: Marc Zyngier <redacted>
Signed-off-by: Will Deacon <redacted>
---
arch/arm/Kconfig | 2 ++
arch/arm/Makefile | 1 +
arch/arm/mach-virt/Kconfig | 9 +++++++
arch/arm/mach-virt/Makefile | 5 ++++
arch/arm/mach-virt/virt.c | 65 +++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 82 insertions(+)
create mode 100644 arch/arm/mach-virt/Kconfig
create mode 100644 arch/arm/mach-virt/Makefile
create mode 100644 arch/arm/mach-virt/virt.c
@@ -1127,6 +1127,8 @@ source "arch/arm/mach-versatile/Kconfig"source"arch/arm/mach-vexpress/Kconfig"source"arch/arm/plat-versatile/Kconfig"+source"arch/arm/mach-virt/Kconfig"+source"arch/arm/mach-w90x900/Kconfig"# Definitions to make life easier
@@ -192,6 +192,7 @@ machine-$(CONFIG_ARCH_SOCFPGA) += socfpgamachine-$(CONFIG_ARCH_SPEAR13XX)+=spear13xxmachine-$(CONFIG_ARCH_SPEAR3XX)+=spear3xxmachine-$(CONFIG_MACH_SPEAR600)+=spear6xx+machine-$(CONFIG_ARCH_VIRT)+=virtmachine-$(CONFIG_ARCH_ZYNQ)+=zynq# Platform directory name. This list is sorted alphanumerically
+
+ - function-base : The base ID from which the functions are offset.
+
+Main node optional properties:
+
+ - cpu_suspend : Offset of CPU_SUSPEND ID from function-base
+
+ - cpu_off : Offset of CPU_OFF ID from function-base
+
+ - cpu_on : Offset of CPU_ON ID from function-base
+
+ - migrate : Offset of MIGRATE ID from function-base
What is the benefit of the "function-base" property over just having
32 bit IDs for each function. For all I can tell, the interface does
not rely on the numbers to be consecutive, so removing the function-base
attribute would make the binding simpler as well as more flexible.
Arnd
From: Nicolas Pitre <hidden> Date: 2012-12-17 20:51:27
On Mon, 17 Dec 2012, Will Deacon wrote:
This patch adds support for the Power State Coordination Interface
defined by ARM, allowing Linux to request CPU-centric power-management
operations from firmware implementing the PSCI protocol.
Signed-off-by: Will Deacon <redacted>
[...]
+/*
+ * The following two functions are invoked via the invoke_psci_fn pointer
+ * and will not be inlined, allowing us to piggyback on the AAPCS.
+ */
To make sure the code is always in sync with the intent, you could mark
those with noinline as well.
You don't need to surround prototype declaration here, unless your goal
was to define a dummy virt_smp_ops when CONFIG_SMP is not selected?
Otherwise the reference below would break compilation.
From: Will Deacon <hidden> Date: 2012-12-18 10:08:50
Hi Arnd,
On Mon, Dec 17, 2012 at 08:00:11PM +0000, Arnd Bergmann wrote:
On Monday 17 December 2012, Will Deacon wrote:
quoted
+
+ - function-base : The base ID from which the functions are offset.
+
+Main node optional properties:
+
+ - cpu_suspend : Offset of CPU_SUSPEND ID from function-base
+
+ - cpu_off : Offset of CPU_OFF ID from function-base
+
+ - cpu_on : Offset of CPU_ON ID from function-base
+
+ - migrate : Offset of MIGRATE ID from function-base
What is the benefit of the "function-base" property over just having
32 bit IDs for each function. For all I can tell, the interface does
not rely on the numbers to be consecutive, so removing the function-base
attribute would make the binding simpler as well as more flexible.
From: Will Deacon <hidden> Date: 2012-12-18 10:11:25
On Mon, Dec 17, 2012 at 08:51:27PM +0000, Nicolas Pitre wrote:
On Mon, 17 Dec 2012, Will Deacon wrote:
quoted
This patch adds support for the Power State Coordination Interface
defined by ARM, allowing Linux to request CPU-centric power-management
operations from firmware implementing the PSCI protocol.
Signed-off-by: Will Deacon <redacted>
[...]
quoted
+/*
+ * The following two functions are invoked via the invoke_psci_fn pointer
+ * and will not be inlined, allowing us to piggyback on the AAPCS.
+ */
To make sure the code is always in sync with the intent, you could mark
those with noinline as well.
Same thing here: this lacks context in a kernel log.
And so on for the other occurrences.
Actually, these are all prefixed with "psci: " thanks to the pr_fmt
definition at the top of the file. I can remove them if you like, but then
it's not obvious which parts of the PSCI code are available from looking at
a kernel boot log.
Cheers for the review,
Will
You don't need to surround prototype declaration here, unless your goal
was to define a dummy virt_smp_ops when CONFIG_SMP is not selected?
Otherwise the reference below would break compilation.
Right you are, the smp_ops macro does the magic for us. I'll put together a
v3.
Cheers,
Will
From: Marc Zyngier <redacted>
Add support for the smallest, dumbest possible platform, to be
used as a guest for KVM or other hypervisors.
It only mandates a GIC and architected timers. Fits nicely with
a multiplatform zImage. Uses very little silicon area.
Signed-off-by: Marc Zyngier <redacted>
Signed-off-by: Will Deacon <redacted>
---
arch/arm/Kconfig | 2 ++
arch/arm/Makefile | 1 +
arch/arm/mach-virt/Kconfig | 9 +++++++
arch/arm/mach-virt/Makefile | 5 ++++
arch/arm/mach-virt/virt.c | 65 +++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 82 insertions(+)
create mode 100644 arch/arm/mach-virt/Kconfig
create mode 100644 arch/arm/mach-virt/Makefile
create mode 100644 arch/arm/mach-virt/virt.c
@@ -1127,6 +1127,8 @@ source "arch/arm/mach-versatile/Kconfig"source"arch/arm/mach-vexpress/Kconfig"source"arch/arm/plat-versatile/Kconfig"+source"arch/arm/mach-virt/Kconfig"+source"arch/arm/mach-w90x900/Kconfig"# Definitions to make life easier
@@ -192,6 +192,7 @@ machine-$(CONFIG_ARCH_SOCFPGA) += socfpgamachine-$(CONFIG_ARCH_SPEAR13XX)+=spear13xxmachine-$(CONFIG_ARCH_SPEAR3XX)+=spear3xxmachine-$(CONFIG_MACH_SPEAR600)+=spear6xx+machine-$(CONFIG_ARCH_VIRT)+=virtmachine-$(CONFIG_ARCH_ZYNQ)+=zynq# Platform directory name. This list is sorted alphanumerically
@@ -0,0 +1,76 @@+/*+*DummyVirtualMachine-doeswhatitsaysonthetin.+*+*Copyright(C)2012ARMLtd+*Author:WillDeacon<will.deacon@arm.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseversion2as+*publishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*+*YoushouldhavereceivedacopyoftheGNUGeneralPublicLicense+*alongwiththisprogram.Ifnot,see<http://www.gnu.org/licenses/>.+*/++#include<linux/init.h>+#include<linux/smp.h>+#include<linux/of.h>++#include<asm/psci.h>+#include<asm/smp_plat.h>+#include<asm/hardware/gic.h>++externvoidsecondary_startup(void);++/*+*EnumeratethepossibleCPUsetfromthedevicetree.+*/+staticvoid__initvirt_smp_init_cpus(void)+{+structdevice_node*dn=NULL;+intcpu=0;++while((dn=of_find_node_by_type(dn,"cpu"))){+if(cpu<NR_CPUS)+set_cpu_possible(cpu,true);+cpu++;+}++/* sanity check */+if(cpu>NR_CPUS)+pr_warning("no. of cores (%d) greater than configured maximum "+"of %d - clipping\n",+cpu,NR_CPUS);++set_smp_cross_call(gic_raise_softirq);+}++staticvoid__initvirt_smp_prepare_cpus(unsignedintmax_cpus)+{+}++staticint__cpuinitvirt_boot_secondary(unsignedintcpu,+structtask_struct*idle)+{+if(psci_ops.cpu_on)+returnpsci_ops.cpu_on(cpu_logical_map(cpu),+__pa(secondary_startup));+return-ENODEV;+}
Isn't there a better way to check whether PSCI is actually "enabled", as
in present in the device tree and initialized correctly?
Maybe we need a pcsi_enabled() static inline of some sort?
From: Will Deacon <hidden> Date: 2012-12-18 13:14:01
Hi Stefano,
On Tue, Dec 18, 2012 at 12:04:38PM +0000, Stefano Stabellini wrote:
On Mon, 17 Dec 2012, Will Deacon wrote:
quoted
From: Marc Zyngier <redacted>
Add support for the smallest, dumbest possible platform, to be
used as a guest for KVM or other hypervisors.
It only mandates a GIC and architected timers. Fits nicely with
a multiplatform zImage. Uses very little silicon area.
Signed-off-by: Marc Zyngier <redacted>
Signed-off-by: Will Deacon <redacted>
---
arch/arm/Kconfig | 2 ++
arch/arm/Makefile | 1 +
arch/arm/mach-virt/Kconfig | 9 +++++++
arch/arm/mach-virt/Makefile | 5 ++++
arch/arm/mach-virt/virt.c | 65 +++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 82 insertions(+)
create mode 100644 arch/arm/mach-virt/Kconfig
create mode 100644 arch/arm/mach-virt/Makefile
create mode 100644 arch/arm/mach-virt/virt.c
Should it come along with a DTS?
The only things the platform needs are GIC, timers, memory and a CPU.
Furthermore, the location, size, frequency etc properties of these aren't
fixed, so a dts would be fairly useless because it will probably not match
the particular mach-virt instance you're targetting.
For kvmtool, I've been generating the device-tree at runtime based on how
kvmtool is invoked and it's been working pretty well so far.
Will
Hi Stefano,
On Tue, Dec 18, 2012 at 12:04:38PM +0000, Stefano Stabellini wrote:
quoted
On Mon, 17 Dec 2012, Will Deacon wrote:
quoted
From: Marc Zyngier <redacted>
Add support for the smallest, dumbest possible platform, to be
used as a guest for KVM or other hypervisors.
It only mandates a GIC and architected timers. Fits nicely with
a multiplatform zImage. Uses very little silicon area.
Signed-off-by: Marc Zyngier <redacted>
Signed-off-by: Will Deacon <redacted>
---
arch/arm/Kconfig | 2 ++
arch/arm/Makefile | 1 +
arch/arm/mach-virt/Kconfig | 9 +++++++
arch/arm/mach-virt/Makefile | 5 ++++
arch/arm/mach-virt/virt.c | 65 +++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 82 insertions(+)
create mode 100644 arch/arm/mach-virt/Kconfig
create mode 100644 arch/arm/mach-virt/Makefile
create mode 100644 arch/arm/mach-virt/virt.c
Should it come along with a DTS?
The only things the platform needs are GIC, timers, memory and a CPU.
Furthermore, the location, size, frequency etc properties of these aren't
fixed, so a dts would be fairly useless because it will probably not match
the particular mach-virt instance you're targetting.
For kvmtool, I've been generating the device-tree at runtime based on how
kvmtool is invoked and it's been working pretty well so far.
I agree on the fact that it should be generated, but I personally think
that it would still be useful as an example.
From: Christopher Covington <hidden> Date: 2012-12-18 18:01:00
Hi Will,
On 12/18/2012 08:14 AM, Will Deacon wrote:
Hi Stefano,
On Tue, Dec 18, 2012 at 12:04:38PM +0000, Stefano Stabellini wrote:
quoted
On Mon, 17 Dec 2012, Will Deacon wrote:
quoted
From: Marc Zyngier <redacted>
Add support for the smallest, dumbest possible platform, to be
used as a guest for KVM or other hypervisors.
[...]
quoted
Should it come along with a DTS?
The only things the platform needs are GIC, timers, memory and a CPU.
I assume multiple virtio-mmio peripherals are hiding behind what you seem to
advertising here as plain old memory?
Furthermore, the location, size, frequency etc properties of these aren't
fixed, so a dts would be fairly useless because it will probably not match
the particular mach-virt instance you're targetting.
I disagree. I think an example DTS would be fairly useful, if only for the
full list of peripherals you're using on the platform.
For kvmtool, I've been generating the device-tree at runtime based on how
kvmtool is invoked and it's been working pretty well so far.
If you'd much prefer to post the command line, tools version, etc. that you're
using to generate the DTB, rather than the DTS, that'd be better than nothing.
It seems like Rob Herring's earlier question about whether the dummy platform
is really justified never got answered. I think sending a sample DTS out with
the patchset would help "highlight where we need to do more work on DT driving
the initialization."
Lastly, I'm somewhat curious, why virtio-mmio console rather than DCC?
Thanks,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
the Linux Foundation
From: Marc Zyngier <hidden> Date: 2012-12-18 18:18:44
Hi Christopher,
On 18/12/12 18:01, Christopher Covington wrote:
Hi Will,
On 12/18/2012 08:14 AM, Will Deacon wrote:
quoted
Hi Stefano,
On Tue, Dec 18, 2012 at 12:04:38PM +0000, Stefano Stabellini wrote:
quoted
On Mon, 17 Dec 2012, Will Deacon wrote:
quoted
From: Marc Zyngier <redacted>
Add support for the smallest, dumbest possible platform, to be
used as a guest for KVM or other hypervisors.
[...]
quoted
quoted
Should it come along with a DTS?
The only things the platform needs are GIC, timers, memory and a CPU.
I assume multiple virtio-mmio peripherals are hiding behind what you seem to
advertising here as plain old memory?
No. Memory is memory. Virtio peripherals are created outside of the
memory range. They end up having rings and descriptor in memory, but
that's not any different from what you have with an fairly complicated
DMA capable hardware device.
Furthermore, even if virtio-mmio is what we use with KVM, it could be
something radically different. Xen uses something somewhat different.
It is not even required to boot the platform!
quoted
Furthermore, the location, size, frequency etc properties of these aren't
fixed, so a dts would be fairly useless because it will probably not match
the particular mach-virt instance you're targetting.
I disagree. I think an example DTS would be fairly useful, if only for the
full list of peripherals you're using on the platform.
That's the whole point: we do not want to to specify anything, because
there is no need to. You could have anything there, depending on your hypervisor.
quoted
For kvmtool, I've been generating the device-tree at runtime based on how
kvmtool is invoked and it's been working pretty well so far.
If you'd much prefer to post the command line, tools version, etc. that you're
using to generate the DTB, rather than the DTS, that'd be better than nothing.
It seems like Rob Herring's earlier question about whether the dummy platform
is really justified never got answered. I think sending a sample DTS out with
the patchset would help "highlight where we need to do more work on DT driving
the initialization."
Lastly, I'm somewhat curious, why virtio-mmio console rather than DCC?
What would be the point of using DCC? We would have to trap on each access, and
then we'd have to invent yet another mechanism to channel the console to userspace.
Not to mention that I like to be able to actually input something on a console,
not just read from it.
M.
--
Jazz is not dead. It just smells funny...
That's a hangover from when entry_point was a void *. I'll fix that, thanks.
Hopefully you didn't pass virtual pointers to the PSCI call, did you? :-)
...and I'd have gotten away with it if it wasn't for those meddling kids!
It was also made worse by Marc's code working first time too (after I blamed
the firmware like any sane kernel hacker would do :)
Will
From: Christopher Covington <hidden> Date: 2012-12-19 15:25:35
On 12/18/2012 01:18 PM, Marc Zyngier wrote:
Hi Christopher,
On 18/12/12 18:01, Christopher Covington wrote:
quoted
Hi Will,
On 12/18/2012 08:14 AM, Will Deacon wrote:
quoted
Hi Stefano,
[...]
quoted
quoted
The only things the platform needs are GIC, timers, memory and a CPU.
I assume multiple virtio-mmio peripherals are hiding behind what you seem to
be advertising here as plain old memory?
No. Memory is memory. Virtio peripherals are created outside of the
memory range. They end up having rings and descriptor in memory, but
that's not any different from what you have with an fairly complicated
DMA capable hardware device.
Sure, but I would consider such a device to be part of the platform (or
perhaps there's some better name to group together the set of devices that
are expected to modify memory?), and I was trying to fish for what additional
devices might be part of the platform on a regular basis, like what
console(s) and network interface(s).
Here's what kvmtool has been seen to generate, with the parameters I used
a few minutes ago:
/dts-v1/;
/memreserve/ 0x000000008fff0000 0x0000000000001000;
/ {
interrupt-parent = <0x1>;
compatible = "linux,dummy-virt";
Might it make sense to call this a generic ARM platform, using something
roughly in the direction of "linux,arm-generic" here and
s/mach-virt/mach-generic/ in the paths? Then any device-tree enabled ARMv7
platform using the generic timer and interrupt controller could reuse this
definition. This machine/platform seems like it could prove useful in
simulation and hardware scenarios. Would, for example, a fully-DT-enabled
Versatile Express machine converge on this definition? I wonder if it might
also be useful as a simple example with which to test out code sharing
between arch/arm and arch/arm64.
[...]
Does it help?
Yes, thanks!
[...]
What would be the point of using DCC?
It seemed like ARM-Ltd.-architected peripherals were picked for the timer and
interrupt controller, so I wondered why not for the console as well. As best
I'm aware, unless one ventures into the PrimeCell line with the PL011, DCC is
the closest match for an officially architected console mechanism.
We would have to trap on each access...
Now that you point his out, this would indeed be fundamentally different than how
the coprocessor-register-accessed generic timer is handled, because the
virtualization extensions mean the hypervisor just needs to handle setup and
switching, but not intervention during normal operation.
This is drifting a bit off-topic to this particular patchset, but while I'm
on the topic of coprocessor register accesses in a virtualized environment,
is there a plan or are there existing mechanisms for handling the performance
counters? Do ID or cache or other register accesses need to be trapped?
Perhaps there are existing threads or portions of code on the topic that I've
overlooked.
...and then we'd have to invent yet another mechanism to channel the
console to userspace.
What mechanism does virtio-mmio support in KVM use to channel the console to
userspace? Would there be a fundamental difference?
It seemed like Will was trying to frame the changes as _whether_ to support
various peripheral devices, because some of them aren't "needed" for an
artificial use case. I would rather frame the implementation decisions as
_which_ devices are going to be supported in the foreseeable future by your
work. Choosing a virtio-mmio console over DCC, semihosting, ram buffer, UART,
and whatever other alternatives there might be impacts someone trying to put
together a Linux image that boots on some combination of simulation,
virtualization, and hardware.
If one puts together a Linux image that uses a UART on hardware and a
virtio-mmio console in a virtualized environment, I would argue that this
image has some incrementally higher debug and maintenance cost than an image
that has the same console mechanism across all platforms. On the other hand,
perhaps the cost of implementing a uniform mechanism across all platforms is
higher still.
Not to mention that I like to be able to actually input something on a console,
not just read from it.
It seemed like ARM-Ltd.-architected peripherals were picked for the timer and
interrupt controller, so I wondered why not for the console as well. As best
I'm aware, unless one ventures into the PrimeCell line with the PL011, DCC is
the closest match for an officially architected console mechanism.
I certainly wouldn't want to mandate the presence of any devices that
require emulation in the DT for a virtual machine, including DCC, as
simple as it might be.
From: Marc Zyngier <hidden> Date: 2012-12-20 13:25:00
On 20/12/12 13:12, Stefano Stabellini wrote:
On Wed, 19 Dec 2012, Christopher Covington wrote:
quoted
quoted
What would be the point of using DCC?
It seemed like ARM-Ltd.-architected peripherals were picked for the timer and
interrupt controller, so I wondered why not for the console as well. As best
I'm aware, unless one ventures into the PrimeCell line with the PL011, DCC is
the closest match for an officially architected console mechanism.
I certainly wouldn't want to mandate the presence of any devices that
require emulation in the DT for a virtual machine, including DCC, as
simple as it might be.
Indeed. GIC and timers have explicit support for virtualization in
hardware. Emulating random IPs is up to the implementor, and given that
virtio already exists (and performs rather well), I don't feel the urge
to reinvent the wheel.
M.
--
Jazz is not dead. It just smells funny...