qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support


From: James Hogan
Subject: Re: [Qemu-devel] [PATCH v5 10/12] hw/mips: malta: Add KVM support
Date: Fri, 20 Jun 2014 09:46:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

Hi,

On 20/06/14 07:07, Paolo Bonzini wrote:
> ----- Messaggio originale -----
>> Da: "Aurelien Jarno" <address@hidden>
>> A: "Sanjay Lal" <address@hidden>
>> Cc: "James Hogan" <address@hidden>, address@hidden, "Peter Maydell" 
>> <address@hidden>,
>> address@hidden, "Gleb Natapov" <address@hidden>, "Paolo Bonzini" 
>> <address@hidden>
>> 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 <address@hidden> 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 >= 0x80000000 are only accessible in
>>> kernel mode, and the default flash area (VA: 0xbfc00000/PA: 0x1fc00000)
>>> 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=0x1fc00000, VA=0x5fc00000), 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]