fix -kernel option

PATCH In review Glauber de Oliveira Costa 7 participants 13 messages Dec 7, 2007 – Dec 10, 2007 6 messages not in the archive KVM

lore

Share & tools

lore

Glauber de Oliveira Costa

author

2007-12-07 17:01 UTC #0 lore raw

PATCH 1/1 fix -kernel option

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 <[email protected]>

---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

qemu/hw/pc.c +8 -3

index 6c71b09..e4a5f2d 100644
@@ -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);
+
         ram_addr = qemu_ram_alloc(ram_size - 0x100000);
         cpu_register_physical_memory(0x100000, ram_size - 0x100000, ram_addr);
         kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
                                          ram_addr);
-        ram_addr = qemu_ram_alloc(0xa0000);
-        cpu_register_physical_memory(0, 0xa0000, ram_addr);
-        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
     } else
  #endif
 #endif

Signature · 9 lines

1.5.0.6


-------------------------------------------------------------------------
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

A message that is not in the archive (sent off-list or not yet received): 11970469043041-git-send-email-gcosta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org

Anthony Liguori

2007-12-07 17:14 UTC #2 lore raw

Quoted 5 lines · Glauber de Oliveira Costa

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.

I think this patch is a reasonable work-around but the long term solution is probably going to have to be making sure that nothing makes the phys_ram_addr + PA assumption. With > 4GB of memory, this assumption is broken because of the BIOS/PCI holes anyway. I guess we could preserve this assumption though by burning some memory.

Thoughts?

Regards,

Anthony Liguori

Quoted 26 lines

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 <[email protected]>

---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

qemu/hw/pc.c +8 -0

index 6c71b09..e4a5f2d 100644
@@ -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);
+

qemu/hw/pc.c static void pc_init1(ram_addr_t ram_size, int vga_ram_size, int boot_device, · line 742

Quoted 10 lines

qemu/hw/pc.c +0 -3

         ram_addr = qemu_ram_alloc(ram_size - 0x100000);
         cpu_register_physical_memory(0x100000, ram_size - 0x100000, ram_addr);
         kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
                                          ram_addr);
-        ram_addr = qemu_ram_alloc(0xa0000);
-        cpu_register_physical_memory(0, 0xa0000, ram_addr);
-        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
     } else
  #endif
 #endif

-------------------------------------------------------------------------
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Izik Eidus

2007-12-07 17:45 UTC #4 lore raw

Quoted 9 lines · Anthony Liguori

Quoted 6 lines · Glauber de Oliveira Costa
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.

Quoted 4 lines

I think this patch is a reasonable work-around but the long term solution is probably going to have to be making sure that nothing makes the phys_ram_addr + PA assumption. With > 4GB of memory, this assumption is broken because of the BIOS/PCI holes anyway.

we can always allocate 300 mbs of junk :)
but i agree with you, and i guess it is important to the dirty bit tracking that no one will touch this
memory without the formal functions anyway (at least for qemu)

Quoted 51 lines

I guess we
could preserve this assumption though by burning some memory.
Thoughts?
Regards,
Anthony Liguori
Quoted 27 lines
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 <[email protected]>
---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)
qemu/hw/pc.c +8 -0
index 6c71b09..e4a5f2d 100644
@@ -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);
+
qemu/hw/pc.c static void pc_init1(ram_addr_t ram_size, int vga_ram_size, int boot_device, · line 742
Quoted 10 lines
qemu/hw/pc.c +0 -3
         ram_addr = qemu_ram_alloc(ram_size - 0x100000);
         cpu_register_physical_memory(0x100000, ram_size - 0x100000, ram_addr);
         kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
                                          ram_addr);
-        ram_addr = qemu_ram_alloc(0xa0000);
-        cpu_register_physical_memory(0, 0xa0000, ram_addr);
-        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
     } else
  #endif
 #endif
-------------------------------------------------------------------------
SF.Net email is sponsored by:

Quoted 9 lines

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
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

A message that is not in the archive (sent off-list or not yet received): 475986AD.90506-atKUWr5tajBWk0Htik3J/[email protected]

Anthony Liguori

2007-12-07 18:38 UTC #6 lore raw

Quoted 9 lines · Izik Eidus

Quoted 8 lines · Anthony Liguori
Quoted 5 lines · Glauber de Oliveira Costa
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.

Quoted 5 lines

Quoted 4 lines
I think this patch is a reasonable work-around but the long term solution is probably going to have to be making sure that nothing makes the phys_ram_addr + PA assumption. With > 4GB of memory, this assumption is broken because of the BIOS/PCI holes anyway.
we can always allocate 300 mbs of junk :)

Well, it may not be so bad. We can certainly malloc() those 300mbs. They'll never be touched by anyone so it doesn't actually increase the resident size.

Quoted 3 lines

but i agree with you, and i guess it is important to the dirty bit tracking that no one will touch this
memory without the formal functions anyway (at least for qemu)

Yes, the only concern I have is that I really want to be able maintain that physically contiguous memory is virtually contiguous in QEMU. This is an important assumption in virtio. It's less important if phys_ram_base + PA works or not as long as that property is preserved.

Regards,

Anthony Liguori

Quoted 55 lines

I guess we could preserve this assumption though by burning some
memory.

Thoughts?

Regards,

Anthony Liguori

Quoted 31 lines

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 <[email protected]>

---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

qemu/hw/pc.c +8 -0

index 6c71b09..e4a5f2d 100644
@@ -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);
+
         ram_addr = qemu_ram_alloc(ram_size - 0x100000);
         cpu_register_physical_memory(0x100000, ram_size - 0x100000,

qemu/hw/pc.c static void pc_init1(ram_addr_t ram_size, int · line 742

Quoted 10 lines

qemu/hw/pc.c +0 -3

 ram_addr);
         kvm_cpu_register_physical_memory(0x100000, ram_size - 
 0x100000,
                                          ram_addr);
-        ram_addr = qemu_ram_alloc(0xa0000);
-        cpu_register_physical_memory(0, 0xa0000, ram_addr);
-        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
     } else
  #endif
 #endif

-------------------------------------------------------------------------

Quoted 12 lines

Quoted 10 lines
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
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

A message that is not in the archive (sent off-list or not yet received): [email protected]

Izik Eidus

2007-12-07 18:45 UTC #8 lore raw

Quoted 20 lines · Anthony Liguori

Quoted 9 lines · Izik Eidus
Quoted 8 lines · Anthony Liguori
Quoted 5 lines · Glauber de Oliveira Costa
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.
Quoted 5 lines
Quoted 4 lines
I think this patch is a reasonable work-around but the long term solution is probably going to have to be making sure that nothing makes the phys_ram_addr + PA assumption. With > 4GB of memory, this assumption is broken because of the BIOS/PCI holes anyway.
we can always allocate 300 mbs of junk :)
Well, it may not be so bad. We can certainly malloc() those 300mbs. They'll never be touched by anyone so it doesn't actually increase the resident size.

Quoted 8 lines

Quoted 3 lines
but i agree with you, and i guess it is important to the dirty bit tracking that no one will touch this
memory without the formal functions anyway (at least for qemu)
Yes, the only concern I have is that I really want to be able maintain that physically contiguous memory is virtually contiguous in QEMU. This is an important assumption in virtio. It's less important if phys_ram_base + PA works or not as long as that property is preserved.

well it already should be like that, any cpu_physical_memory_write/cpu_physical_memory_read, should go to vaild addresses
we had issue with older kvm userspace (below 52) that had such problem, and the dma in the rtl8139 card made the whole qemu to crush when you ran it with above 4 giga,
now it look like everything is working fine, but if you see something please report :)

Quoted 74 lines

Regards,
Anthony Liguori
Quoted 68 lines
Quoted 66 lines
I guess we could preserve this assumption though by burning some
memory.
Thoughts?
Regards,
Anthony Liguori
Quoted 32 lines
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 <[email protected]>
---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)
qemu/hw/pc.c +8 -0
index 6c71b09..e4a5f2d 100644
@@ -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);
+
         ram_addr = qemu_ram_alloc(ram_size - 0x100000);
         cpu_register_physical_memory(0x100000, ram_size - 
qemu/hw/pc.c static void pc_init1(ram_addr_t ram_size, int
Quoted 10 lines
qemu/hw/pc.c +0 -3
 0x100000, ram_addr);
         kvm_cpu_register_physical_memory(0x100000, ram_size - 
 0x100000,
                                          ram_addr);
-        ram_addr = qemu_ram_alloc(0xa0000);
-        cpu_register_physical_memory(0, 0xa0000, ram_addr);
-        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
     } else
  #endif
 #endif
-------------------------------------------------------------------------
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
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Luca Tettamanti

2007-12-07 20:04 UTC #9 lore raw

In reply to a message not in the archive

Quoted 13 lines · Anthony Liguori

Quoted 12 lines · Izik Eidus
Quoted 11 lines · Anthony Liguori
Quoted 4 lines · Glauber de Oliveira Costa
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.
I think this patch is a reasonable work-around but the long term solution is probably going to have to be making sure that nothing makes the phys_ram_addr + PA assumption. With > 4GB of memory, this assumption is broken because of the BIOS/PCI holes anyway.

Quoted 5 lines

Quoted 1 line
we can always allocate 300 mbs of junk :)
Well, it may not be so bad. We can certainly malloc() those 300mbs. They'll never be touched by anyone so it doesn't actually increase the resident size.

Iff the host kernel is configured to overcommit memory.

Luca

Avi Kivity

2007-12-09 08:54 UTC #10 lore raw

In reply to a message not in the archive

Quoted 9 lines · Anthony Liguori

Quoted 6 lines · Glauber de Oliveira Costa
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.

Quoted 7 lines

I think this patch is a reasonable work-around but the long term solution is probably going to have to be making sure that nothing makes the phys_ram_addr + PA assumption. With > 4GB of memory, this assumption is broken because of the BIOS/PCI holes anyway. I guess we could preserve this assumption though by burning some memory.

We don't need to burn the memory, you can munmap() the unneeded part after allocating it.

Just make sure you don't touch it afterwards. We used this method in previous versions, then moved to the current approach which is more aligned with how qemu does things.

Signature · 9 lines

Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
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

Izik Eidus

2007-12-07 17:49 UTC #11 lore raw

In reply to a message not in the archive

Quoted 19 lines · Glauber de Oliveira Costa

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 <[email protected]>
---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)
qemu/hw/pc.c +0 -0
index 6c71b09..e4a5f2d 100644
@@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size, int boot_device,
 #ifdef USE_KVM

qemu/hw/pc.c static void pc_init1(ram_addr_t ram_size, int vga_ram_size, int boot_device, · line 735

Quoted 10 lines

qemu/hw/pc.c +7 -0

  #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);

good catch!

Quoted 10 lines

qemu/hw/pc.c +1 -3

+
         ram_addr = qemu_ram_alloc(ram_size - 0x100000);
         cpu_register_physical_memory(0x100000, ram_size - 0x100000, ram_addr);
         kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
                                          ram_addr);
-        ram_addr = qemu_ram_alloc(0xa0000);
-        cpu_register_physical_memory(0, 0xa0000, ram_addr);
-        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
     } else
  #endif

Quoted 2 lines

#endif

Dor Laor

2007-12-09 14:00 UTC #12 lore raw

In reply to a message not in the archive

Quoted 21 lines · Glauber de Oliveira Costa

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 <[email protected]>
---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)
qemu/hw/pc.c +0 -0
index 6c71b09..e4a5f2d 100644
@@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int 
 vga_ram_size, int boot_device,
 #ifdef USE_KVM

qemu/hw/pc.c static void pc_init1(ram_addr_t ram_size, int · line 736

Quoted 10 lines

qemu/hw/pc.c +7 -0

  #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.

Regards,
Dor.

Quoted 17 lines

qemu/hw/pc.c +1 -3

+
         ram_addr = qemu_ram_alloc(ram_size - 0x100000);
         cpu_register_physical_memory(0x100000, ram_size - 0x100000, 
 ram_addr);
         kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
                                          ram_addr);
-        ram_addr = qemu_ram_alloc(0xa0000);
-        cpu_register_physical_memory(0, 0xa0000, ram_addr);
-        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);

     } else

#endif
#endif
--
1.5.0.6

Quoted 11 lines

-------------------------------------------------------------------------
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
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

A message that is not in the archive (sent off-list or not yet received): 475BF50F.5020001-atKUWr5tajBWk0Htik3J/[email protected]

Izik Eidus

2007-12-09 13:59 UTC #14 lore raw

Quoted 39 lines · Dor Laor

Quoted 21 lines · Glauber de Oliveira Costa
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 <[email protected]>
---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)
qemu/hw/pc.c +0 -0
index 6c71b09..e4a5f2d 100644
@@ -725,13 +725,18 @@ static void pc_init1(ram_addr_t ram_size, int 
 vga_ram_size, int boot_device,
 #ifdef USE_KVM
qemu/hw/pc.c static void pc_init1(ram_addr_t ram_size, int · line 736
Quoted 10 lines
qemu/hw/pc.c +7 -0
  #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.

Quoted 2 lines

Regards,
Dor.

you will get problems using virtio with above 4 giga as well in this case, why not just using cpu_memory_write/cpu_memory_read??? (as i understand from how that cpu_register_physical_memory built this is the qemu way)

Glauber de Oliveira Costa

author

2007-12-10 16:17 UTC #15 lore raw

In reply to a message not in the archive

Quoted 30 lines · Dor Laor

Quoted 29 lines · Glauber de Oliveira Costa
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 <[email protected]>
---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)
qemu/hw/pc.c +6 -0
index 6c71b09..e4a5f2d 100644
@@ -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 */

Quoted 9 lines

qemu/hw/pc.c static void pc_init1(ram_addr_t ram_size, int · line 736
Quoted 2 lines
qemu/hw/pc.c +1 -0
+        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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Dor Laor

2007-12-10 17:56 UTC #17 lore raw

Quoted 43 lines · Glauber de Oliveira Costa

Quoted 8 lines · Dor Laor
Quoted 7 lines · Glauber de Oliveira Costa
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
Quoted 7 lines
Quoted 7 lines
of extended memory - makes it work again
Signed-off-by Glauber de Oliveira Costa <[email protected]>
---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)
Quoted 9 lines
qemu/hw/pc.c static void pc_init1(ram_addr_t ram_size, int · line 728
Quoted 9 lines
qemu/hw/pc.c +0 -0
index 6c71b09..e4a5f2d 100644
@@ -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)) {
Quoted 8 lines
qemu/hw/pc.c static void pc_init1(ram_addr_t ram_size, int vga_ram_size, int boot_device,
Quoted 8 lines
qemu/hw/pc.c +7 -0
+        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);
 
Quoted 7 lines
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.

Quoted 3 lines

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

_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Uri Lublin

2007-12-09 14:04 UTC #18 lore raw

In reply to a message not in the archive

Quoted 20 lines · Glauber de Oliveira Costa

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 <[email protected]>
---
 qemu/hw/pc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)
qemu/hw/pc.c +0 -0
index 6c71b09..e4a5f2d 100644
@@ -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

qemu/hw/pc.c static void pc_init1(ram_addr_t ram_size, int vga_ram_size, int boot_device, · line 736

Quoted 10 lines

qemu/hw/pc.c +8 -0

     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);
+

Actually the next address we'll touch (see the following lines) is 0x100000. So maybe replace the last line above with "qemu_ram_alloc (0x100000 - 0xa0000);"

Quoted 11 lines

qemu/hw/pc.c +0 -3

         ram_addr = qemu_ram_alloc(ram_size - 0x100000);
         cpu_register_physical_memory(0x100000, ram_size - 0x100000, ram_addr);
         kvm_cpu_register_physical_memory(0x100000, ram_size - 0x100000,
                                          ram_addr);
-        ram_addr = qemu_ram_alloc(0xa0000);
-        cpu_register_physical_memory(0, 0xa0000, ram_addr);
-        kvm_cpu_register_physical_memory(0, 0xa0000, ram_addr);
     } else
  #endif

#endif