Mailing List Archive: [RFC PATCH 0/2] Add support for a fake, para-virtualised machine

[RFC PATCH 0/2] Add support for a fake, para-virtualised machine

Dec 3, 2012, 10:52 AM

Post #1 of 4 (986 views)

Hello,

When running Linux on a para-virtualised platform (that is, one where
the guest is aware that it is dealing with virtual devices sitting on
things like virtio or xenbus) we require very little in the way of
platform code and piggy-backing on top of an existing platform can
require a lot of device emulation for very little gain.

These two patches introduce mach-virt: a very simple, DT-based machine
which can be used with kvmtool in conjunction with virtio-based devices.
It's not hard to imagine the same machine being targetted by Xen, which
currently emulates a minimal variant of the vexpress platform.

Note that this patch series depends on the timer rework from Mark
Rutland, posted on Friday:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/135651.html

All feedback welcome. We suspect that most controversy will be around
the name of the thing :)

Will

Marc Zyngier (2):
ARM: Dummy Virtual Machine platform support
ARM: SMP support for mach-virt

arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/mach-virt/Kconfig | 9 ++
arch/arm/mach-virt/Makefile | 6 ++
arch/arm/mach-virt/headsmp.S | 38 ++++++++
arch/arm/mach-virt/platsmp.c | 205 +++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-virt/virt.c | 71 +++++++++++++++
7 files changed, 332 insertions(+)
create mode 100644 arch/arm/mach-virt/Kconfig
create mode 100644 arch/arm/mach-virt/Makefile
create mode 100644 arch/arm/mach-virt/headsmp.S
create mode 100644 arch/arm/mach-virt/platsmp.c
create mode 100644 arch/arm/mach-virt/virt.c

--
1.8.0

_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

Re: [RFC PATCH 0/2] Add support for a fake, para-virtualised machine [ In reply to ]

robherring2 at gmail

Dec 3, 2012, 2:54 PM

Post #2 of 4 (978 views)

Permalink

On 12/03/2012 11:52 AM, Will Deacon wrote:
> Hello,
>
> When running Linux on a para-virtualised platform (that is, one where
> the guest is aware that it is dealing with virtual devices sitting on
> things like virtio or xenbus) we require very little in the way of
> platform code and piggy-backing on top of an existing platform can
> require a lot of device emulation for very little gain.
>
> These two patches introduce mach-virt: a very simple, DT-based machine
> which can be used with kvmtool in conjunction with virtio-based devices.
> It's not hard to imagine the same machine being targetted by Xen, which
> currently emulates a minimal variant of the vexpress platform.
>
> Note that this patch series depends on the timer rework from Mark
> Rutland, posted on Friday:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/135651.html
>
> All feedback welcome. We suspect that most controversy will be around
> the name of the thing :)

We've discussed this before at conferences. I don't know that we
concluded this wasn't needed, but it certainly leaned that direction. So
what has changed? You're not going to save code space because we're
building multiple platforms together. You'll save some boot time, but a
stripped down dtb with only the minimal peripherals would probably save
nearly as much time. However, I do have concerns with using VExpress as
the guest. For example, you can't support a non-PAE guest with 4GB of
RAM on VExpress (maybe if the vexpress code gets all memory map info
from DT).

Is this really complete? Will we need reset, poweroff, hotplug, and
suspend/resume support for example? Unlike most initial platform
submissions which are minimal, I think seeing full support would be
useful here. Then we can better gauge how much we are really saving.

Rob

>
> Will
>
>
> Marc Zyngier (2):
> ARM: Dummy Virtual Machine platform support
> ARM: SMP support for mach-virt
>
> arch/arm/Kconfig | 2 +
> arch/arm/Makefile | 1 +
> arch/arm/mach-virt/Kconfig | 9 ++
> arch/arm/mach-virt/Makefile | 6 ++
> arch/arm/mach-virt/headsmp.S | 38 ++++++++
> arch/arm/mach-virt/platsmp.c | 205 +++++++++++++++++++++++++++++++++++++++++++
> arch/arm/mach-virt/virt.c | 71 +++++++++++++++
> 7 files changed, 332 insertions(+)
> create mode 100644 arch/arm/mach-virt/Kconfig
> create mode 100644 arch/arm/mach-virt/Makefile
> create mode 100644 arch/arm/mach-virt/headsmp.S
> create mode 100644 arch/arm/mach-virt/platsmp.c
> create mode 100644 arch/arm/mach-virt/virt.c
>

_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

Re: [RFC PATCH 0/2] Add support for a fake, para-virtualised machine [ In reply to ]

will.deacon at arm

Dec 5, 2012, 8:07 AM

Post #3 of 4 (982 views)

Permalink

On Wed, Dec 05, 2012 at 02:52:57PM +0000, Catalin Marinas wrote:
> On 4 December 2012 18:14, Will Deacon <will.deacon@arm.com> wrote:
> > Well, this depends on the guest taking an undefined instruction exception on
> > the smc, then deciding to issue an hvc instead and *then* having the
> > hypervisor somehow translate that into a PSCI invocation. It could work, but
> > it sounds easy to mess up and relies on the PSCI firmware co-existing with
> > things like kvm.
>
> We can have enable-method DT entries independent of the SoC and one of
> them can be psci-hvc.

As soon as the support is there in the upper layers, we can do that.

> Just for clarification, AArch32 with virtualisation mandates the
> security extensions, so the SMC can be trapped. On AArch64 it is a bit
> tricky since the presence of EL3 is not mandate, in which case SMC
> would undef (don't as why ;). That's where we can have different
> enable methods specified via the DT.

Not entirely true: only ARMv7 mandates the security extensions in this
manner. You can still have ARMv8 CPUs running AArch32 code without the
security extensions.

Will

_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm

Re: [RFC PATCH 0/2] Add support for a fake, para-virtualised machine [ In reply to ]

catalin.marinas at arm

Dec 5, 2012, 8:15 AM

Post #4 of 4 (982 views)

Permalink

On Wed, Dec 05, 2012 at 03:07:32PM +0000, Will Deacon wrote:
> On Wed, Dec 05, 2012 at 02:52:57PM +0000, Catalin Marinas wrote:
> > Just for clarification, AArch32 with virtualisation mandates the
> > security extensions, so the SMC can be trapped. On AArch64 it is a bit
> > tricky since the presence of EL3 is not mandate, in which case SMC
> > would undef (don't as why ;). That's where we can have different
> > enable methods specified via the DT.
>
> Not entirely true: only ARMv7 mandates the security extensions in this
> manner. You can still have ARMv8 CPUs running AArch32 code without the
> security extensions.

Yes, I pretty much had the 32-bit and 64-bit ARM ports in mind. An
AArch32 guest OS running on an AArch64 KVM would indeed have this issue.

But HVC PSCI would still work for the mach-virt in all cases.

--
Catalin

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm