Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote:
> In KVM mode the bootrom is loaded and executed from the last 1MB of
> DRAM.
What is the reason for that? I am not opposed to that, but if it is
really needed, it means that loading a bootloader into the flash area
(for example YAMON) won't work and that this should be forbidden to the
user.
> Based on "[PATCH 12/12] KVM/MIPS: General KVM support and support for
> SMP Guests" by Sanjay Lal .
>
> Signed-off-by: James Hogan
> Reviewed-by: Aurelien Jarno
> Cc: Peter Maydell
> Cc: Sanjay Lal
> ---
> Changes in v5:
> - Kseg0 doesn't actually change size, so use cpu_mips_kseg0_to_phys()
>rather than having the KVM specific cpu_mips_kvm_um_kseg0_to_phys().
>
> Changes in v3:
> - Remove unnecessary includes, especially linux/kvm.h which isn't a
>good idea on non-Linux (Peter Maydell).
>
> Changes in v2:
> - Removal of cps / GIC / SMP support
> - Minimal bootloader modified to execute safely from RAM
> - Remove "Writing bootloader to final 1MB of RAM" printf
> ---
> hw/mips/mips_malta.c | 73
> ++--
> 1 file changed, 53 insertions(+), 20 deletions(-)
>
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index f4a7d4712952..8bc5392b4223 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -51,6 +51,7 @@
> #include "sysemu/qtest.h"
> #include "qemu/error-report.h"
> #include "hw/empty_slot.h"
> +#include "sysemu/kvm.h"
>
> //#define DEBUG_BOARD_INIT
>
> @@ -603,29 +604,31 @@ static void network_init(PCIBus *pci_bus)
> */
>
> static void write_bootloader (CPUMIPSState *env, uint8_t *base,
> - int64_t kernel_entry)
> + int64_t run_addr, int64_t kernel_entry)
> {
> uint32_t *p;
>
> /* Small bootloader */
> p = (uint32_t *)base;
> -stl_p(p++, 0x0bf00160); /* j
> 0x1fc00580 */
> +
> +stl_p(p++, 0x0800 | /* j
> 0x1fc00580 */
> + ((run_addr + 0x580) & 0x0fff) >> 2);
> stl_p(p++, 0x); /* nop */
>
> /* YAMON service vector */
> -stl_p(base + 0x500, 0xbfc00580); /* start: */
> -stl_p(base + 0x504, 0xbfc0083c); /* print_count: */
> -stl_p(base + 0x520, 0xbfc00580); /* start: */
> -stl_p(base + 0x52c, 0xbfc00800); /* flush_cache: */
> -stl_p(base + 0x534, 0xbfc00808); /* print: */
> -stl_p(base + 0x538, 0xbfc00800); /* reg_cpu_isr: */
> -stl_p(base + 0x53c, 0xbfc00800); /* unred_cpu_isr: */
> -stl_p(base + 0x540, 0xbfc00800); /* reg_ic_isr: */
> -stl_p(base + 0x544, 0xbfc00800); /* unred_ic_isr: */
> -stl_p(base + 0x548, 0xbfc00800); /* reg_esr: */
> -stl_p(base + 0x54c, 0xbfc00800); /* unreg_esr: */
> -stl_p(base + 0x550, 0xbfc00800); /* getchar: */
> -stl_p(base + 0x554, 0xbfc00800); /* syscon_read: */
> +stl_p(base + 0x500, run_addr + 0x0580); /* start: */
> +stl_p(base + 0x504, run_addr + 0x083c); /* print_count: */
> +stl_p(base + 0x520, run_addr + 0x0580); /* start: */
> +stl_p(base + 0x52c, run_addr + 0x0800); /* flush_cache: */
> +stl_p(base + 0x534, run_addr + 0x0808); /* print: */
> +stl_p(base + 0x538, run_addr + 0x0800); /* reg_cpu_isr: */
> +stl_p(base + 0x53c, run_addr + 0x0800); /* unred_cpu_isr: */
> +stl_p(base + 0x540, run_addr + 0x0800); /* reg_ic_isr: */
> +stl_p(base + 0x544, run_addr + 0x0800); /* unred_ic_isr: */
> +stl_p(base + 0x548, run_addr + 0x0800); /* reg_esr: */
> +stl_p(base + 0x54c, run_addr + 0x0800); /* unreg_esr: */
> +stl_p(base + 0x550, run_addr + 0x0800); /* getchar: */
> +stl_p(base + 0x554, run_addr + 0x0800); /* syscon_read: */
>
>
> /* Second part of the bootloader */
> @@ -701,7 +704,7 @@ static void write_bootloader (CPUMIPSState *env, uint8_t
> *base,
> p = (uint32_t *) (base + 0x800);
> stl_p(p++, 0x03e8); /* jr ra */
> stl_p(p++, 0x2402); /* li v0,0 */
> - /* 808 YAMON print */
> +/* 808 YAMON print */
> stl_p(p++, 0x03e06821); /* move
> t5,ra */
> stl_p(p++, 0x00805821); /* move
> t3,a0 */
> stl_p(p++, 0x00a05021); /* move
> t2,a1 */
> @@ -774,6 +777,7 @@ static int64_t load_kernel (void)
> uint32_t *prom_buf;
> long prom_size;
> int prom_index = 0;
> +uint64_t (*xlate_to_kseg0) (void *opaque, uint64_t addr);
>
> #ifdef TARGET_WORDS_BIGENDIAN
> big_endian = 1;
> @@ -788,6 +792,11 @@ static int64_t load_kernel (void)
> loaderparams.kernel_filename);
> exit(1);
>
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On Jun 19, 2014, at 9:27 AM, Aurelien Jarno wrote: > On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote: >> In KVM mode the bootrom is loaded and executed from the last 1MB of >> DRAM. > > What is the reason for that? I am not opposed to that, but if it is > really needed, it means that loading a bootloader into the flash area > (for example YAMON) won't work and that this should be forbidden to the > user. > In trap and emulate mode, both the kernel and userland run in user mode on the processor. Virtual addresses >= 0x8000 are only accessible in kernel mode, and the default flash area (VA: 0xbfc0/PA: 0x1fc0) falls in this range. We therefore decided to relocate the bootloader to the last 1MB of RAM. This area is excluded from the RAM ranges supplied to the kernel, so it should not be accessible to the user. Regards Sanjay signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On Thu, Jun 19, 2014 at 12:34:24PM -0700, Sanjay Lal wrote: > > On Jun 19, 2014, at 9:27 AM, Aurelien Jarno wrote: > > > On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote: > >> In KVM mode the bootrom is loaded and executed from the last 1MB of > >> DRAM. > > > > What is the reason for that? I am not opposed to that, but if it is > > really needed, it means that loading a bootloader into the flash area > > (for example YAMON) won't work and that this should be forbidden to the > > user. > > > > In trap and emulate mode, both the kernel and userland run in user mode on > the processor. Virtual addresses >= 0x8000 are only accessible in kernel > mode, and the default flash area (VA: 0xbfc0/PA: 0x1fc0) falls in > this range. > > We therefore decided to relocate the bootloader to the last 1MB of RAM. This > area is excluded from the RAM ranges supplied to the kernel, so it should not > be accessible to the user. > Thanks for the explanation. It means we should disable the support for booting from the flash (using -pflash) in KVM mode, as it would simply not work. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
- Messaggio originale - > Da: "Aurelien Jarno" > A: "Sanjay Lal" > Cc: "James Hogan" , qemu-de...@nongnu.org, "Peter > Maydell" , > kvm@vger.kernel.org, "Gleb Natapov" , "Paolo Bonzini" > > Inviato: Giovedì, 19 giugno 2014 23:47:34 > Oggetto: Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support > > On Thu, Jun 19, 2014 at 12:34:24PM -0700, Sanjay Lal wrote: > > > > On Jun 19, 2014, at 9:27 AM, Aurelien Jarno wrote: > > > > > On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote: > > >> In KVM mode the bootrom is loaded and executed from the last 1MB of > > >> DRAM. > > > > > > What is the reason for that? I am not opposed to that, but if it is > > > really needed, it means that loading a bootloader into the flash area > > > (for example YAMON) won't work and that this should be forbidden to the > > > user. > > > > > > > In trap and emulate mode, both the kernel and userland run in user mode on > > the processor. Virtual addresses >= 0x8000 are only accessible in > > kernel mode, and the default flash area (VA: 0xbfc0/PA: 0x1fc0) > > falls in this range. > > > > We therefore decided to relocate the bootloader to the last 1MB of RAM. > > This area is excluded from the RAM ranges supplied to the kernel, so it > > should not be accessible to the user. > > > > Thanks for the explanation. It means we should disable the support for > booting from the flash (using -pflash) in KVM mode, as it would simply > not work. My idea was to add a machines-specific option umkernel=on, and require it in order to run KVM. Later we can add umkernel=on support for TCG as well, while umkernel=off with KVM requires virtualization extensions. The same option can disable pflash boot. What do you think? Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
Hi, On 20/06/14 07:07, Paolo Bonzini wrote: > - Messaggio originale - >> Da: "Aurelien Jarno" >> A: "Sanjay Lal" >> Cc: "James Hogan" , qemu-de...@nongnu.org, "Peter >> Maydell" , >> kvm@vger.kernel.org, "Gleb Natapov" , "Paolo Bonzini" >> >> Inviato: Giovedì, 19 giugno 2014 23:47:34 >> Oggetto: Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support >> >> On Thu, Jun 19, 2014 at 12:34:24PM -0700, Sanjay Lal wrote: >>> >>> On Jun 19, 2014, at 9:27 AM, Aurelien Jarno wrote: >>> >>>> On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote: >>>>> In KVM mode the bootrom is loaded and executed from the last 1MB of >>>>> DRAM. >>>> >>>> What is the reason for that? I am not opposed to that, but if it is >>>> really needed, it means that loading a bootloader into the flash area >>>> (for example YAMON) won't work and that this should be forbidden to the >>>> user. >>>> >>> >>> In trap and emulate mode, both the kernel and userland run in user mode on >>> the processor. Virtual addresses >= 0x8000 are only accessible in >>> kernel mode, and the default flash area (VA: 0xbfc0/PA: 0x1fc0) >>> falls in this range. >>> >>> We therefore decided to relocate the bootloader to the last 1MB of RAM. >>> This area is excluded from the RAM ranges supplied to the kernel, so it >>> should not be accessible to the user. I did recently try relocating the bootloader to the reset address in the T&E KSeg0 (i.e. PA=0x1fc0, VA=0x5fc0), but the current MIPS KVM implementation in the kernel has some limitations when it comes to memory regions. It allocates a linear guest_pmap array (for GPA->RPA page mapping) based only on the first memory region committed, so if you set e.g. mem=64MB then physical memory according to guest_pmap won't reach the reset address and it fails to map it. The kernel needs fixing to use a more flexible physical page table structure first really. >> Thanks for the explanation. It means we should disable the support for >> booting from the flash (using -pflash) in KVM mode, as it would simply >> not work. > > My idea was to add a machines-specific option umkernel=on, and require it > in order to run KVM. Later we can add umkernel=on support for TCG as well, FYI I tried this and it was a fairly small change (fixing CP0_EBase initialisation and switching a couple of kvm_enabled() checks to something like mips_um_ksegs_enabled()). Needs more testing though. > while umkernel=off with KVM requires virtualization extensions. > > The same option can disable pflash boot. > > What do you think? I think with an executable flash region / reset address the pflash option could be made to work, but of course you'd probably need a relocated flash image too, which may make the option less useful (and it presumably isn't like a kernel ELF where you can detect what address it's linked). For now disabling Malta non kernel loads in KVM mode makes sense I think. Thanks James -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On Fri, Jun 20, 2014 at 02:07:05AM -0400, Paolo Bonzini wrote: > > > - Messaggio originale - > > Da: "Aurelien Jarno" > > A: "Sanjay Lal" > > Cc: "James Hogan" , qemu-de...@nongnu.org, "Peter > > Maydell" , > > kvm@vger.kernel.org, "Gleb Natapov" , "Paolo Bonzini" > > > > Inviato: Giovedì, 19 giugno 2014 23:47:34 > > Oggetto: Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support > > > > On Thu, Jun 19, 2014 at 12:34:24PM -0700, Sanjay Lal wrote: > > > > > > On Jun 19, 2014, at 9:27 AM, Aurelien Jarno wrote: > > > > > > > On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote: > > > >> In KVM mode the bootrom is loaded and executed from the last 1MB of > > > >> DRAM. > > > > > > > > What is the reason for that? I am not opposed to that, but if it is > > > > really needed, it means that loading a bootloader into the flash area > > > > (for example YAMON) won't work and that this should be forbidden to the > > > > user. > > > > > > > > > > In trap and emulate mode, both the kernel and userland run in user mode on > > > the processor. Virtual addresses >= 0x8000 are only accessible in > > > kernel mode, and the default flash area (VA: 0xbfc0/PA: 0x1fc0) > > > falls in this range. > > > > > > We therefore decided to relocate the bootloader to the last 1MB of RAM. > > > This area is excluded from the RAM ranges supplied to the kernel, so it > > > should not be accessible to the user. > > > > > > > Thanks for the explanation. It means we should disable the support for > > booting from the flash (using -pflash) in KVM mode, as it would simply > > not work. > > My idea was to add a machines-specific option umkernel=on, and require it > in order to run KVM. Later we can add umkernel=on support for TCG as well, > while umkernel=off with KVM requires virtualization extensions. > > The same option can disable pflash boot. > > What do you think? For what I understand the current KVM support in MIPS uses trap and emulate and thus doesn't need hardware support, just a recent kernel with the option enabled. That's why I do wonder if there is a real point in supporting UM kernels in TCG mode. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On 19/06/14 22:47, Aurelien Jarno wrote:
> On Thu, Jun 19, 2014 at 12:34:24PM -0700, Sanjay Lal wrote:
>>
>> On Jun 19, 2014, at 9:27 AM, Aurelien Jarno wrote:
>>
>>> On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote:
In KVM mode the bootrom is loaded and executed from the last 1MB of
DRAM.
>>>
>>> What is the reason for that? I am not opposed to that, but if it is
>>> really needed, it means that loading a bootloader into the flash area
>>> (for example YAMON) won't work and that this should be forbidden to the
>>> user.
>>>
>>
>> In trap and emulate mode, both the kernel and userland run in user mode on
>> the processor. Virtual addresses >= 0x8000 are only accessible in kernel
>> mode, and the default flash area (VA: 0xbfc0/PA: 0x1fc0) falls in
>> this range.
>>
>> We therefore decided to relocate the bootloader to the last 1MB of RAM.
>> This area is excluded from the RAM ranges supplied to the kernel, so it
>> should not be accessible to the user.
>>
>
> Thanks for the explanation. It means we should disable the support for
> booting from the flash (using -pflash) in KVM mode, as it would simply
> not work.
>
Hi Aurelien,
Is this fixup to the malta patch the sort of thing you had in mind? If
so I'll generate a v6 patchset with it.
Cheers
James
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index 8bc5392b4223..91b0ce566111 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -1052,6 +1052,12 @@ void mips_malta_init(MachineState *machine)
bootloader_run_addr, kernel_entry);
}
} else {
+/* The flash region isn't executable from a KVM T&E guest */
+if (kvm_enabled()) {
+error_report("KVM enabled but no -kernel argument was specified. "
+ "Booting from flash is not supported with KVM T&E.");
+exit(1);
+}
/* Load firmware from flash. */
if (!dinfo) {
/* Load a BIOS image. */
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
Il 20/06/2014 11:10, Aurelien Jarno ha scritto: > My idea was to add a machines-specific option umkernel=on, and require it > in order to run KVM. Later we can add umkernel=on support for TCG as well, > while umkernel=off with KVM requires virtualization extensions. > > The same option can disable pflash boot. > > What do you think? For what I understand the current KVM support in MIPS uses trap and emulate and thus doesn't need hardware support, just a recent kernel with the option enabled. Yes, but work to support virtualization extensions is underway. Patches were posted a few months ago. That's why I do wonder if there is a real point in supporting UM kernels in TCG mode. Debugging, mainly. It is sometimes useful to compare TCG with KVM on x86, and I suppose it could be the same on MIPS. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
Il 20/06/2014 11:25, James Hogan ha scritto: On 19/06/14 22:47, Aurelien Jarno wrote: On Thu, Jun 19, 2014 at 12:34:24PM -0700, Sanjay Lal wrote: On Jun 19, 2014, at 9:27 AM, Aurelien Jarno wrote: On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote: In KVM mode the bootrom is loaded and executed from the last 1MB of DRAM. What is the reason for that? I am not opposed to that, but if it is really needed, it means that loading a bootloader into the flash area (for example YAMON) won't work and that this should be forbidden to the user. In trap and emulate mode, both the kernel and userland run in user mode on the processor. Virtual addresses >= 0x8000 are only accessible in kernel mode, and the default flash area (VA: 0xbfc0/PA: 0x1fc0) falls in this range. We therefore decided to relocate the bootloader to the last 1MB of RAM. This area is excluded from the RAM ranges supplied to the kernel, so it should not be accessible to the user. Thanks for the explanation. It means we should disable the support for booting from the flash (using -pflash) in KVM mode, as it would simply not work. Hi Aurelien, Is this fixup to the malta patch the sort of thing you had in mind? If so I'll generate a v6 patchset with it. It looks like this. No hurry, it can go in after the main series; just git-send-email it so it gets noticed and has a proper commit message. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On Fri, Jun 20, 2014 at 12:38:30PM +0200, Paolo Bonzini wrote: > Il 20/06/2014 11:10, Aurelien Jarno ha scritto: > >> My idea was to add a machines-specific option umkernel=on, and require it > >> in order to run KVM. Later we can add umkernel=on support for TCG as well, > >> while umkernel=off with KVM requires virtualization extensions. > >> > >> The same option can disable pflash boot. > >> > >> What do you think? > > > >For what I understand the current KVM support in MIPS uses trap and > >emulate and thus doesn't need hardware support, just a recent kernel > >with the option enabled. > > Yes, but work to support virtualization extensions is underway. > Patches were posted a few months ago. > > >That's why I do wonder if there is a real point > >in supporting UM kernels in TCG mode. > > Debugging, mainly. It is sometimes useful to compare TCG with KVM > on x86, and I suppose it could be the same on MIPS. Ok, then we can indeed add a umkernel option, which is always enabled with KVM, and which disable the flash (and why not other devices) in that case. At some point it might be a good idea to add a specific machine for emulation/virtualization, like it is done on ARM, which do not have to handle this kind of devices, and which does not have all the current limitations of the Malta board. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On Fri, Jun 20, 2014 at 10:25:24AM +0100, James Hogan wrote:
> On 19/06/14 22:47, Aurelien Jarno wrote:
> > On Thu, Jun 19, 2014 at 12:34:24PM -0700, Sanjay Lal wrote:
> >>
> >> On Jun 19, 2014, at 9:27 AM, Aurelien Jarno wrote:
> >>
> >>> On Tue, Jun 17, 2014 at 11:10:35PM +0100, James Hogan wrote:
> In KVM mode the bootrom is loaded and executed from the last 1MB of
> DRAM.
> >>>
> >>> What is the reason for that? I am not opposed to that, but if it is
> >>> really needed, it means that loading a bootloader into the flash area
> >>> (for example YAMON) won't work and that this should be forbidden to the
> >>> user.
> >>>
> >>
> >> In trap and emulate mode, both the kernel and userland run in user mode on
> >> the processor. Virtual addresses >= 0x8000 are only accessible in
> >> kernel mode, and the default flash area (VA: 0xbfc0/PA: 0x1fc0)
> >> falls in this range.
> >>
> >> We therefore decided to relocate the bootloader to the last 1MB of RAM.
> >> This area is excluded from the RAM ranges supplied to the kernel, so it
> >> should not be accessible to the user.
> >>
> >
> > Thanks for the explanation. It means we should disable the support for
> > booting from the flash (using -pflash) in KVM mode, as it would simply
> > not work.
> >
>
> Hi Aurelien,
>
> Is this fixup to the malta patch the sort of thing you had in mind? If
> so I'll generate a v6 patchset with it.
>
> Cheers
> James
>
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index 8bc5392b4223..91b0ce566111 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -1052,6 +1052,12 @@ void mips_malta_init(MachineState *machine)
> bootloader_run_addr, kernel_entry);
> }
> } else {
> +/* The flash region isn't executable from a KVM T&E guest */
> +if (kvm_enabled()) {
> +error_report("KVM enabled but no -kernel argument was specified.
> "
> + "Booting from flash is not supported with KVM
> T&E.");
> +exit(1);
> +}
> /* Load firmware from flash. */
> if (!dinfo) {
> /* Load a BIOS image. */
>
This looks fine to me.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
On 20/06/14 12:19, Aurelien Jarno wrote: > On Fri, Jun 20, 2014 at 12:38:30PM +0200, Paolo Bonzini wrote: >> Il 20/06/2014 11:10, Aurelien Jarno ha scritto: My idea was to add a machines-specific option umkernel=on, and require it in order to run KVM. Later we can add umkernel=on support for TCG as well, while umkernel=off with KVM requires virtualization extensions. The same option can disable pflash boot. What do you think? >>> >>> For what I understand the current KVM support in MIPS uses trap and >>> emulate and thus doesn't need hardware support, just a recent kernel >>> with the option enabled. >> >> Yes, but work to support virtualization extensions is underway. >> Patches were posted a few months ago. >> >>> That's why I do wonder if there is a real point >>> in supporting UM kernels in TCG mode. >> >> Debugging, mainly. It is sometimes useful to compare TCG with KVM >> on x86, and I suppose it could be the same on MIPS. > > Ok, then we can indeed add a umkernel option, which is always enabled > with KVM, and which disable the flash (and why not other devices) in > that case. > > At some point it might be a good idea to add a specific machine for > emulation/virtualization, like it is done on ARM, which do not have to > handle this kind of devices, and which does not have all the current > limitations of the Malta board. FYI Cavium have been working on a para-virtualised machine which they use with their VZ KVM implementation. They're using lkvm, but I expect it will make sense to port that to QEMU too. lkvm patchset (applied): https://www.mail-archive.com/kvm%40vger.kernel.org/msg102792.html linux kernel patchset (merged in v3.16-rc1): https://www.mail-archive.com/kvm%40vger.kernel.org/msg102806.html Cheers James -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
