[Top] [All Lists]

Re: [PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the MI

To: David Daney <>
Subject: Re: [PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
From: Sanjay Lal <>
Date: Mon, 10 Jun 2013 09:37:30 -0700
Cc: Gleb Natapov <>, David Daney <>, David Daney <>,,,,, David Daney <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <> <>
On Jun 9, 2013, at 4:23 PM, David Daney wrote:

> On 06/09/2013 12:31 AM, Gleb Natapov wrote:
>> On Fri, Jun 07, 2013 at 04:15:00PM -0700, David Daney wrote:
>>> I should also add that I will shortly send patches for the kvm tool
>>> required to drive this VM as well as a small set of patches that
>>> create a para-virtualized MIPS/Linux guest kernel.
>>> The idea is that because there is no standard SMP linux system, we
>>> create a standard para-virtualized system that uses a handful of
>>> hypercalls, but mostly just uses virtio devices.  It has no emulated
>>> real hardware (no 8250 UART, no emulated legacy anything...)
>> Virtualization is useful for running legacy code. Why dismiss support
>> for non pv guests so easily?
> Just because we create standard PV system devices, doesn't preclude emulating 
> real hardware.  In fact Sanjay Lal's work includes QEMU support for doing 
> just this for a MIPS malta board.  I just wanted a very simple system I could 
> implement with the kvm tool in a couple of days, so that is what I initially 
> did.
> The problem is that almost nobody has real malta boards, they are really only 
> of interest because QEMU implements a virtual malta board.
> Personally, I see the most interesting us cases of MIPS KVM being a 
> deployment platform for new services, so legacy support is not so important 
> to me.  That doesn't mean that other people wouldn't want some sort of legacy 
> support.  The problem with 'legacy' on MIPS is that there are hundreds of 
> legacies to choose from (Old SGI and DEC hardware, various network hardware 
> from many different vendors, etc.).  Which would you choose?
>>  How different MIPS SMP systems are?
> o Old SGI heavy metal (several different system architectures).
> o Cavium OCTEON SMP SoCs.
> o Broadcom (several flavors) SoCs
> o Loongson
> Come to think of it, Emulating SGI hardware might be an interesting case.  
> There may be old IRIX systems and applications that could be running low on 
> real hardware.  Some of those systems take up a whole room and draw a lot of 
> power.  They might run faster and at much lower power consumption on a modern 
> 48-Way SMP SoC based system.
>>  What
>> about running non pv UP systems?
> See above.  I think this is what Sanjay Lal is doing.

The KVM implementation from MIPS (currently in mainline) supports UP systems in 
trap and emulate mode.  The patch set I posted earlier adding VZ support also 
supports SMP.  We leverage the Malta board emulation in QEMU to offer full 
non-PV virtualization:

UP system: Malta board with a MIPS 24K processor
SMP system: Malta board with a 1074K CMP processor cluster with a GIC.

When it comes to PV/non-PV support, I see the two implementations as 
complementary.  If people want full legacy system emulation without any kernel 
modifications, then they can run the full QEMU/KVM stack, while people 
interested in pure PV solutions can run the lkvm version.


<Prev in Thread] Current Thread [Next in Thread>