From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: [PATCH] fix -kernel option Date: Mon, 10 Dec 2007 19:56:27 +0200 Message-ID: <475D7DCB.5040001@qumranet.com> References: <11970469043041-git-send-email-gcosta@redhat.com> <475BF50F.5020001@qumranet.com> <475D6686.4070202@redhat.com> Reply-To: dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1895595727==" Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Avi Kivity To: Glauber de Oliveira Costa Return-path: In-Reply-To: <475D6686.4070202-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org This is a multi-part message in MIME format. --===============1895595727== Content-Type: multipart/alternative; boundary="------------080600030706070501090707" This is a multi-part message in MIME format. --------------080600030706070501090707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Glauber de Oliveira Costa wrote: > > Dor Laor wrote: > > Glauber de Oliveira Costa wrote: > >> > >> Currently, the -kernel option is not working. > >> > >> Reason is, because we're registering chunks for regions 0-0xa0000 and > >> 0x100000-ram_size, the phys_ram_addr + PA is broken. > >> The real fix should be to rewrite all the load_linux() code to not rely > >> on this, but meanwhile, filling in the gap up to 0xc0000 - the > beginning > >> of extended memory - makes it work again > >> > >> Signed-off-by: Glauber de Oliveira Costa > >> --- > >> qemu/hw/pc.c | 11 ++++++++--- > >> 1 files changed, 8 insertions(+), 3 deletions(-) > >> > >> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c > >> index 6c71b09..e4a5f2d 100644 > >> --- a/qemu/hw/pc.c > >> +++ b/qemu/hw/pc.c > >> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int > >> vga_ram_size, int boot_device, > >> #ifdef USE_KVM > >> #ifdef KVM_CAP_USER_MEMORY > >> if (kvm_allowed && > kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) { > >> + ram_addr = qemu_ram_alloc(0xa0000); > >> + cpu_register_physical_memory(0, 0xa0000, ram_addr); > >> + kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr); > >> + > >> + /* move the pointer up to 0xc0000, which is the next > >> + address we'll touch */ > >> + qemu_ram_alloc(0x20000); > >> > > It should be 0x60000 instead of 0x20000 since the code below should > > start at offset of > > 0x100000. > > This finally solved my problem with running virtio using kvm, before it > > only worked for -no-kvm. > > In general this fixes phys_mem_base + PA. > > > I disagree. We allocate the piece 0xc0000 onwards a little bit later. So > we only need to fill the gap 0xa0000 -> 0xc0000 > First it fixed the phys_mem_base + pa for virtio. As Izike mentioned we should use standard qemu_rw_memory and not to access it directly. Second, right after the 0x20000 allocation there is a call to ram_addr = qemu_ram_alloc(ram_size - 0x100000); So either don't call qemu_ram_alloc(0x20000) at all or call it with the right value. Regards, Dor --------------080600030706070501090707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glauber de Oliveira Costa wrote:
Re: [kvm-devel] [PATCH] fix -kernel option

Dor Laor wrote:
> Glauber de Oliveira Costa wrote:
>>
>> Currently, the -kernel option is not working.
>>
>> Reason is, because we're registering chunks for regions 0-0xa0000 and
>> 0x100000-ram_size, the phys_ram_addr + PA is broken.
>> The real fix should be to rewrite all the load_linux() code to not rely
>> on this, but meanwhile, filling in the gap up to 0xc0000 - the beginning
>> of extended memory - makes it work again
>>
>> Signed-off-by: Glauber de Oliveira Costa <gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>>  qemu/hw/pc.c |   11 ++++++++---
>>  1 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
>> index 6c71b09..e4a5f2d 100644
>> --- a/qemu/hw/pc.c
>> +++ b/qemu/hw/pc.c
>> @@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int
>> vga_ram_size, int boot_device,
>>  #ifdef USE_KVM
>>   #ifdef KVM_CAP_USER_MEMORY
>>      if (kvm_allowed && kvm_qemu_check_extension(KVM_CAP_USER_MEMORY)) {
>> +        ram_addr = qemu_ram_alloc(0xa0000);
>> +        cpu_register_physical_memory(0, 0xa0000, ram_addr);
>> +        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
>> +
>> +       /* move the pointer up to 0xc0000, which is the next
>> +           address we'll touch */
>> +        qemu_ram_alloc(0x20000);
>>
> It should be 0x60000 instead of 0x20000 since the code below should
> start at offset of
> 0x100000.
> This finally solved my problem with running virtio using kvm, before it
> only worked for -no-kvm.
> In general this fixes phys_mem_base + PA.
>
I disagree. We allocate the piece 0xc0000 onwards a little bit later. So
we only need to fill the gap 0xa0000 -> 0xc0000

First it fixed the phys_mem_base + pa for virtio.
As Izike mentioned we should use standard qemu_rw_memory and not to access it directly.
Second, right after the 0x20000 allocation there is a call to
ram_addr = qemu_ram_alloc(ram_size - 0x100000);
So either don't call qemu_ram_alloc(0x20000) at all or call it with the right value.

Regards,
Dor
--------------080600030706070501090707-- --===============1895595727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php --===============1895595727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel --===============1895595727==--