Mailing List Archive: [PATCH v2 5/6] ARM: Dummy Virtual Machine platform support

[PATCH v2 5/6] ARM: Dummy Virtual Machine platform support

Dec 17, 2012, 8:35 AM

Post #1 of 9 (1246 views)

From: Marc Zyngier <marc.zyngier@arm.com>

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 <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
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

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2a04375..552d72e0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -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
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 5f914fc..e8232ad 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -192,6 +192,7 @@ machine-$(CONFIG_ARCH_SOCFPGA) += socfpga
machine-$(CONFIG_ARCH_SPEAR13XX) += spear13xx
machine-$(CONFIG_ARCH_SPEAR3XX) += spear3xx
machine-$(CONFIG_MACH_SPEAR600) += spear6xx
+machine-$(CONFIG_ARCH_VIRT) += virt
machine-$(CONFIG_ARCH_ZYNQ) += zynq

# Platform directory name. This list is sorted alphanumerically
diff --git a/arch/arm/mach-virt/Kconfig b/arch/arm/mach-virt/Kconfig
new file mode 100644
index 0000000..a568a2a
--- /dev/null
+++ b/arch/arm/mach-virt/Kconfig
@@ -0,0 +1,9 @@
+config ARCH_VIRT
+ bool "Dummy Virtual Machine" if ARCH_MULTI_V7
+ select ARCH_WANT_OPTIONAL_GPIOLIB
+ select ARM_GIC
+ select ARM_ARCH_TIMER
+ select HAVE_SMP
+ select CPU_V7
+ select SPARSE_IRQ
+ select USE_OF
diff --git a/arch/arm/mach-virt/Makefile b/arch/arm/mach-virt/Makefile
new file mode 100644
index 0000000..7ddbfa6
--- /dev/null
+++ b/arch/arm/mach-virt/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the linux kernel.
+#
+
+obj-y := virt.o
diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
new file mode 100644
index 0000000..174b9da
--- /dev/null
+++ b/arch/arm/mach-virt/virt.c
@@ -0,0 +1,65 @@
+/*
+ * Dummy Virtual Machine - does what it says on the tin.
+ *
+ * Copyright (C) 2012 ARM Ltd
+ * Authors: Will Deacon <will.deacon@arm.com>,
+ * Marc Zyngier <marc.zyngier@arm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+
+#include <asm/arch_timer.h>
+#include <asm/hardware/gic.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/time.h>
+
+const static struct of_device_id irq_match[] = {
+ { .compatible = "arm,cortex-a15-gic", .data = gic_of_init, },
+ {}
+};
+
+static void __init gic_init_irq(void)
+{
+ of_irq_init(irq_match);
+}
+
+static void __init virt_init(void)
+{
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static void __init virt_timer_init(void)
+{
+ WARN_ON(arch_timer_of_register() != 0);
+ WARN_ON(arch_timer_sched_clock_init() != 0);
+}
+
+static const char *virt_dt_match[] = {
+ "linux,dummy-virt",
+ NULL
+};
+
+static struct sys_timer virt_timer = {
+ .init = virt_timer_init,
+};
+
+DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
+ .init_irq = gic_init_irq,
+ .handle_irq = gic_handle_irq,
+ .timer = &virt_timer,
+ .init_machine = virt_init,
+ .dt_compat = virt_dt_match,
+MACHINE_END
--
1.8.0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 5/6] ARM: Dummy Virtual Machine platform support [ In reply to ]

stefano.stabellini at eu

Dec 18, 2012, 4:04 AM

Post #2 of 9 (1221 views)

Permalink

On Mon, 17 Dec 2012, Will Deacon wrote:
> From: Marc Zyngier <marc.zyngier@arm.com>
>
> 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 <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> 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?

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2a04375..552d72e0 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -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
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 5f914fc..e8232ad 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -192,6 +192,7 @@ machine-$(CONFIG_ARCH_SOCFPGA) += socfpga
> machine-$(CONFIG_ARCH_SPEAR13XX) += spear13xx
> machine-$(CONFIG_ARCH_SPEAR3XX) += spear3xx
> machine-$(CONFIG_MACH_SPEAR600) += spear6xx
> +machine-$(CONFIG_ARCH_VIRT) += virt
> machine-$(CONFIG_ARCH_ZYNQ) += zynq
>
> # Platform directory name. This list is sorted alphanumerically
> diff --git a/arch/arm/mach-virt/Kconfig b/arch/arm/mach-virt/Kconfig
> new file mode 100644
> index 0000000..a568a2a
> --- /dev/null
> +++ b/arch/arm/mach-virt/Kconfig
> @@ -0,0 +1,9 @@
> +config ARCH_VIRT
> + bool "Dummy Virtual Machine" if ARCH_MULTI_V7
> + select ARCH_WANT_OPTIONAL_GPIOLIB
> + select ARM_GIC
> + select ARM_ARCH_TIMER
> + select HAVE_SMP
> + select CPU_V7
> + select SPARSE_IRQ
> + select USE_OF
> diff --git a/arch/arm/mach-virt/Makefile b/arch/arm/mach-virt/Makefile
> new file mode 100644
> index 0000000..7ddbfa6
> --- /dev/null
> +++ b/arch/arm/mach-virt/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the linux kernel.
> +#
> +
> +obj-y := virt.o
> diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
> new file mode 100644
> index 0000000..174b9da
> --- /dev/null
> +++ b/arch/arm/mach-virt/virt.c
> @@ -0,0 +1,65 @@
> +/*
> + * Dummy Virtual Machine - does what it says on the tin.
> + *
> + * Copyright (C) 2012 ARM Ltd
> + * Authors: Will Deacon <will.deacon@arm.com>,
> + * Marc Zyngier <marc.zyngier@arm.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +
> +#include <asm/arch_timer.h>
> +#include <asm/hardware/gic.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/time.h>
> +
> +const static struct of_device_id irq_match[] = {
> + { .compatible = "arm,cortex-a15-gic", .data = gic_of_init, },
> + {}
> +};
> +
> +static void __init gic_init_irq(void)
> +{
> + of_irq_init(irq_match);
> +}
> +
> +static void __init virt_init(void)
> +{
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}
> +
> +static void __init virt_timer_init(void)
> +{
> + WARN_ON(arch_timer_of_register() != 0);
> + WARN_ON(arch_timer_sched_clock_init() != 0);
> +}
> +
> +static const char *virt_dt_match[] = {
> + "linux,dummy-virt",
> + NULL
> +};
> +
> +static struct sys_timer virt_timer = {
> + .init = virt_timer_init,
> +};
> +
> +DT_MACHINE_START(VIRT, "Dummy Virtual Machine")
> + .init_irq = gic_init_irq,
> + .handle_irq = gic_handle_irq,
> + .timer = &virt_timer,
> + .init_machine = virt_init,
> + .dt_compat = virt_dt_match,
> +MACHINE_END
> --
> 1.8.0
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 5/6] ARM: Dummy Virtual Machine platform support [ In reply to ]

will.deacon at arm

Dec 18, 2012, 5:14 AM

Post #3 of 9 (1218 views)

Permalink

Hi Stefano,

On Tue, Dec 18, 2012 at 12:04:38PM +0000, Stefano Stabellini wrote:
> On Mon, 17 Dec 2012, Will Deacon wrote:
> > From: Marc Zyngier <marc.zyngier@arm.com>
> >
> > 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 <marc.zyngier@arm.com>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> > 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 5/6] ARM: Dummy Virtual Machine platform support [ In reply to ]

stefano.stabellini at eu

Dec 18, 2012, 5:32 AM

Post #4 of 9 (1225 views)

Permalink

On Tue, 18 Dec 2012, Will Deacon wrote:
> Hi Stefano,
>
> On Tue, Dec 18, 2012 at 12:04:38PM +0000, Stefano Stabellini wrote:
> > On Mon, 17 Dec 2012, Will Deacon wrote:
> > > From: Marc Zyngier <marc.zyngier@arm.com>
> > >
> > > 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 <marc.zyngier@arm.com>
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > ---
> > > 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 5/6] ARM: Dummy Virtual Machine platform support [ In reply to ]

cov at codeaurora

Dec 18, 2012, 10:01 AM

Post #5 of 9 (1223 views)

Permalink

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:
>> On Mon, 17 Dec 2012, Will Deacon wrote:
>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>
>>> Add support for the smallest, dumbest possible platform, to be
>>> used as a guest for KVM or other hypervisors.

[...]

>> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 5/6] ARM: Dummy Virtual Machine platform support [ In reply to ]

marc.zyngier at arm

Dec 18, 2012, 10:18 AM

Post #6 of 9 (1218 views)

Permalink

Hi Christopher,

On 18/12/12 18:01, Christopher Covington wrote:
> 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:
>>> On Mon, 17 Dec 2012, Will Deacon wrote:
>>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>>
>>>> Add support for the smallest, dumbest possible platform, to be
>>>> used as a guest for KVM or other hypervisors.
>
> [...]
>
>>> 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!

>> 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.

>> 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.

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";
#address-cells = <0x2>;
#size-cells = <0x2>;

chosen {
bootargs = "console=hvc0,38400 root=/dev/vda1";
};

memory {
device_type = "memory";
reg = <0x0 0x80000000 0x0 0x40000000>;
};

cpus {
#address-cells = <0x1>;
#size-cells = <0x0>;

cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
enable-method = "psci";
reg = <0x0>;
};

cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
enable-method = "psci";
reg = <0x1>;
};
};

intc {
compatible = "arm,cortex-a15-gic";
#interrupt-cells = <0x3>;
interrupt-controller;
reg = <0x0 0x3ffff000 0x0 0x1000 0x0 0x3fffd000 0x0 0x2000>;
phandle = <0x1>;
};

timer {
compatible = "arm,armv7-timer";
interrupts = <0x1 0xd 0x301 0x1 0xe 0x301 0x1 0xb 0x301 0x1 0xa 0x301>;
};

virtio@0 {
compatible = "virtio,mmio";
reg = <0x0 0x0 0x0 0x200>;
interrupts = <0x0 0x0 0x1>;
};

virtio@200 {
compatible = "virtio,mmio";
reg = <0x0 0x200 0x0 0x200>;
interrupts = <0x0 0x1 0x1>;
};

virtio@400 {
compatible = "virtio,mmio";
reg = <0x0 0x400 0x0 0x200>;
interrupts = <0x0 0x2 0x1>;
};

virtio@600 {
compatible = "virtio,mmio";
reg = <0x0 0x600 0x0 0x200>;
interrupts = <0x0 0x3 0x1>;
};

psci {
compatible = "arm,psci";
method = "hvc";
cpu_suspend = <0x95c1ba5e>;
cpu_off = <0x95c1ba5f>;
cpu_on = <0x95c1ba60>;
migrate = <0x95c1ba61>;
};
};

Does it help?

> 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...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 5/6] ARM: Dummy Virtual Machine platform support [ In reply to ]

cov at codeaurora

Dec 19, 2012, 7:25 AM

Post #7 of 9 (1221 views)

Permalink

On 12/18/2012 01:18 PM, Marc Zyngier wrote:
> Hi Christopher,
>
> On 18/12/12 18:01, Christopher Covington wrote:
>> Hi Will,
>>
>> On 12/18/2012 08:14 AM, Will Deacon wrote:
>>> Hi Stefano,
>>>

[...]

>>
>>> 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.

Perhaps there's some misunderstanding here. The Debug Communications Channel
that I'm familiar with is fully capable of both input and output.

http://infocenter.arm.com/help/topic/com.arm.doc.dui0471c/BEIHGIBB.html
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/tty/hvc/hvc_dcc.c

Thanks,
Christopher

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
the Linux Foundation

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 5/6] ARM: Dummy Virtual Machine platform support [ In reply to ]

stefano.stabellini at eu

Dec 20, 2012, 5:12 AM

Post #8 of 9 (1224 views)

Permalink

On Wed, 19 Dec 2012, Christopher Covington wrote:
> > 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 5/6] ARM: Dummy Virtual Machine platform support [ In reply to ]

marc.zyngier at arm

Dec 20, 2012, 5:25 AM

Post #9 of 9 (1216 views)

Permalink

On 20/12/12 13:12, Stefano Stabellini wrote:
> On Wed, 19 Dec 2012, Christopher Covington wrote:
>>> 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...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel