Re: [PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000

[Avi Kivity]

Izik Eidus wrote:

b) It is brute force.  I'm not sure it really matters all that much to
limit a 32-bit (non-PAE) guest to 3G, but it's a little extreme for the
cases that don't care about the large hole.
Is there anyway to make it dynamic based on the requirements of the
devices that are part of the launched VM?
  


There is (you need to transfer data to the bios but it is 
possible...), the thing is - there was concern that
it will make windows crazy if you keep changing the devices physical 
mapping


Avi what do you think?


It's possible for the bios to size the resources needed by PCI devices 
(excluding hotplug) and tell qemu where to map RAM.  However I don't 
think that's what standard bioses do.


On a barcelona I have here the hole is 0.75GB; I think either 0.5 or 1 
GB holes are reasonable.  I prefer 1GB so we can accommodate large 
assigned framebuffers; I don't see people running 4GB Windows guests 
(and Linux guests can use PAE).


--
error compiling committee.c: too many arguments to function

--
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: [PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000

[Izik Eidus]

Chris Wright wrote:

* Izik Eidus (iei...@redhat.com) wrote:
  

This patch make the pci mem region larger (1 giga now).
this is needed for pci devices that require large amount of memory
such as video cards.

for pea guests this patch is not an issue beacuse the guest OS will map
the rest of the ram after 0x1...,
for 32bits that arent pea, it mean the maximum memory that would be
avaible now is 3giga.



Seems a little heavy handed.

a) Given the size...code could be cleaned up so that a simple constant
change doesn't need to touch so much code.
  


Yea it probably can...


b) It is brute force.  I'm not sure it really matters all that much to
limit a 32-bit (non-PAE) guest to 3G, but it's a little extreme for the
cases that don't care about the large hole. 


Is there anyway to make it dynamic based on the requirements of the
devices that are part of the launched VM?
  


There is (you need to transfer data to the bios but it is possible...), 
the thing is - there was concern that

it will make windows crazy if you keep changing the devices physical mapping

Avi what do you think?


thanks,
-chris
  


--
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: [PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000

[Chris Wright]

* Izik Eidus (iei...@redhat.com) wrote:
 This patch make the pci mem region larger (1 giga now).
 this is needed for pci devices that require large amount of memory
 such as video cards.
 
 for pea guests this patch is not an issue beacuse the guest OS will map
 the rest of the ram after 0x1...,
 for 32bits that arent pea, it mean the maximum memory that would be
 avaible now is 3giga.

Seems a little heavy handed.

a) Given the size...code could be cleaned up so that a simple constant
change doesn't need to touch so much code.

b) It is brute force.  I'm not sure it really matters all that much to
limit a 32-bit (non-PAE) guest to 3G, but it's a little extreme for the
cases that don't care about the large hole. 

Is there anyway to make it dynamic based on the requirements of the
devices that are part of the launched VM?

thanks,
-chris
--
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

[PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000

[Izik Eidus]

This patch make the pci mem region larger (1 giga now).
this is needed for pci devices that require large amount of memory
such as video cards.

for pea guests this patch is not an issue beacuse the guest OS will map
the rest of the ram after 0x1...,
for 32bits that arent pea, it mean the maximum memory that would be
avaible now is 3giga.

Signed-off-by: Izik Eidus iei...@redhat.com
---
 bios/acpi-dsdt.dsl  |2 +-
 bios/rombios.c  |2 +-
 bios/rombios32.c|   10 +-
 qemu/hw/pc.c|6 +++---
 qemu/hw/vga_int.h   |2 +-
 qemu/hw/vmware_vga.c|4 ++--
 qemu/kvm-tpr-opt.c  |2 +-
 qemu/qemu-kvm.c |2 +-
 vgabios/vbe.h   |2 +-
 vgabios/vbe_display_api.txt |2 +-
 10 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index d67616d..78061ab 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -226,7 +226,7 @@ DefinitionBlock (
 ,, , AddressRangeMemory, TypeStatic)
 DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, 
NonCacheable, ReadWrite,
 0x, // Address Space Granularity
-0xE000, // Address Range Minimum
+0xC000, // Address Range Minimum
 0xFEBF, // Address Range Maximum
 0x, // Address Translation Offset
 0x1EC0, // Address Length
diff --git a/bios/rombios.c b/bios/rombios.c
index c4f6ccd..146dd52 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -9829,7 +9829,7 @@ pcibios_init_sel_reg:
 pcibios_init_iomem_bases:
   push bp
   mov  bp, sp
-  mov  eax, #0xe000 ;; base for memory init
+  mov  eax, #0xc000 ;; base for memory init
   push eax
   mov  ax, #0xc000 ;; base for i/o init
   push ax
diff --git a/bios/rombios32.c b/bios/rombios32.c
index ab37e13..dceaff6 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -565,8 +565,8 @@ void setup_mtrr(void)
 wrmsr_smp(MSR_MTRRfix4K_E8000, 0);
 wrmsr_smp(MSR_MTRRfix4K_F, 0);
 wrmsr_smp(MSR_MTRRfix4K_F8000, 0);
-/* Mark 3.5-4GB as UC, anything not specified defaults to WB */
-wrmsr_smp(MTRRphysBase_MSR(0), 0xe000ull | 0);
+/* Mark 3-4GB as UC, anything not specified defaults to WB */
+wrmsr_smp(MTRRphysBase_MSR(0), 0xc000ull | 0);
 wrmsr_smp(MTRRphysMask_MSR(0), ~(0x2000ull - 1) | 0x800);
 wrmsr_smp(MSR_MTRRdefType, 0xc06);
 }
@@ -924,8 +924,8 @@ static void pci_bios_init_device(PCIDevice *d)
 case 0x0300: /* Display controller - VGA compatible controller */
 if (vendor_id != 0x1234)
 goto default_map;
-/* VGA: map frame buffer to default Bochs VBE address */
-pci_set_io_region_addr(d, 0, 0xE000);
+/* VGA: map frame buffer */
+pci_set_io_region_addr(d, 0, 0xC000);
 break;
 case 0x0800: /* Generic system peripheral - PIC */
 if (vendor_id == PCI_VENDOR_ID_IBM) {
@@ -1016,7 +1016,7 @@ void pci_for_each_device(void (*init_func)(PCIDevice *d))
 void pci_bios_init(void)
 {
 pci_bios_io_addr = 0xc000;
-pci_bios_mem_addr = 0xf000;
+pci_bios_mem_addr = 0xc000 + 0x100;
 pci_bios_bigmem_addr = ram_size;
 if (pci_bios_bigmem_addr  0x9000)
 pci_bios_bigmem_addr = 0x9000;
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index c470646..c04d9b6 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -821,9 +821,9 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
 BlockDriverState *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
 BlockDriverState *fd[MAX_FD];
 
-if (ram_size = 0xe000 ) {
-above_4g_mem_size = ram_size - 0xe000;
-below_4g_mem_size = 0xe000;
+if (ram_size = 0xc000 ) {
+above_4g_mem_size = ram_size - 0xc000;
+below_4g_mem_size = 0xc000;
 } else {
 below_4g_mem_size = ram_size;
 }
diff --git a/qemu/hw/vga_int.h b/qemu/hw/vga_int.h
index 65ac68a..64f594a 100644
--- a/qemu/hw/vga_int.h
+++ b/qemu/hw/vga_int.h
@@ -59,7 +59,7 @@
 #define VBE_DISPI_LFB_ENABLED   0x40
 #define VBE_DISPI_NOCLEARMEM0x80
 
-#define VBE_DISPI_LFB_PHYSICAL_ADDRESS  0xE000
+#define VBE_DISPI_LFB_PHYSICAL_ADDRESS  0xC000
 
 #ifdef CONFIG_BOCHS_VBE
 
diff --git a/qemu/hw/vmware_vga.c b/qemu/hw/vmware_vga.c
index e30d03f..028bf81 100644
--- a/qemu/hw/vmware_vga.c
+++ b/qemu/hw/vmware_vga.c
@@ -119,14 +119,14 @@ struct pci_vmsvga_state_s {
 # define SVGA_IO_BASE  SVGA_LEGACY_BASE_PORT
 # define SVGA_IO_MUL   1
 # define SVGA_FIFO_SIZE0x1
-# define SVGA_MEM_BASE 0xe000
+# define SVGA_MEM_BASE 0xc000
 # define SVGA_PCI_DEVICE_IDPCI_DEVICE_ID_VMWARE_SVGA2
 #else
 # define SVGA_ID   SVGA_ID_1
 # define