* [PATCH 0/1] pci hole remaping
@ 2009-01-11 1:25 Izik Eidus
2009-01-11 1:25 ` [PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000 Izik Eidus
0 siblings, 1 reply; 5+ messages in thread
From: Izik Eidus @ 2009-01-11 1:25 UTC (permalink / raw
To: kvm
kind of simple, i would send one to qemu later (need to check something
first
Spice need this, it allow more memory cache (badly needed when runing
with multiple screens)
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000
2009-01-11 1:25 [PATCH 0/1] pci hole remaping Izik Eidus
@ 2009-01-11 1:25 ` Izik Eidus
2009-01-17 0:57 ` Chris Wright
0 siblings, 1 reply; 5+ messages in thread
From: Izik Eidus @ 2009-01-11 1:25 UTC (permalink / raw
To: kvm; +Cc: 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 0x100000000...,
for 32bits that arent pea, it mean the maximum memory that would be
avaible now is 3giga.
Signed-off-by: Izik Eidus <ieidus@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,
0x00000000, // Address Space Granularity
- 0xE0000000, // Address Range Minimum
+ 0xC0000000, // Address Range Minimum
0xFEBFFFFF, // Address Range Maximum
0x00000000, // Address Translation Offset
0x1EC00000, // 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, #0xe0000000 ;; base for memory init
+ mov eax, #0xc0000000 ;; 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_F0000, 0);
wrmsr_smp(MSR_MTRRfix4K_F8000, 0);
- /* Mark 3.5-4GB as UC, anything not specified defaults to WB */
- wrmsr_smp(MTRRphysBase_MSR(0), 0xe0000000ull | 0);
+ /* Mark 3-4GB as UC, anything not specified defaults to WB */
+ wrmsr_smp(MTRRphysBase_MSR(0), 0xc0000000ull | 0);
wrmsr_smp(MTRRphysMask_MSR(0), ~(0x20000000ull - 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, 0xE0000000);
+ /* VGA: map frame buffer */
+ pci_set_io_region_addr(d, 0, 0xC0000000);
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 = 0xf0000000;
+ pci_bios_mem_addr = 0xc0000000 + 0x1000000;
pci_bios_bigmem_addr = ram_size;
if (pci_bios_bigmem_addr < 0x90000000)
pci_bios_bigmem_addr = 0x90000000;
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 >= 0xe0000000 ) {
- above_4g_mem_size = ram_size - 0xe0000000;
- below_4g_mem_size = 0xe0000000;
+ if (ram_size >= 0xc0000000 ) {
+ above_4g_mem_size = ram_size - 0xc0000000;
+ below_4g_mem_size = 0xc0000000;
} 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_NOCLEARMEM 0x80
-#define VBE_DISPI_LFB_PHYSICAL_ADDRESS 0xE0000000
+#define VBE_DISPI_LFB_PHYSICAL_ADDRESS 0xC0000000
#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_SIZE 0x10000
-# define SVGA_MEM_BASE 0xe0000000
+# define SVGA_MEM_BASE 0xc0000000
# define SVGA_PCI_DEVICE_ID PCI_DEVICE_ID_VMWARE_SVGA2
#else
# define SVGA_ID SVGA_ID_1
# define SVGA_IO_BASE SVGA_LEGACY_BASE_PORT
# define SVGA_IO_MUL 4
# define SVGA_FIFO_SIZE 0x10000
-# define SVGA_MEM_BASE 0xe0000000
+# define SVGA_MEM_BASE 0xc0000000
# define SVGA_PCI_DEVICE_ID PCI_DEVICE_ID_VMWARE_SVGA
#endif
diff --git a/qemu/kvm-tpr-opt.c b/qemu/kvm-tpr-opt.c
index f2a3a1e..9fa6a33 100644
--- a/qemu/kvm-tpr-opt.c
+++ b/qemu/kvm-tpr-opt.c
@@ -142,7 +142,7 @@ static int instruction_is_ok(CPUState *env, uint64_t rip, int is_write)
uint32_t addr;
uint64_t p;
- if ((rip & 0xf0000000) != 0x80000000 && (rip & 0xf0000000) != 0xe0000000)
+ if ((rip & 0xc1000000) != 0x80000000 && (rip & 0xc1000000) != 0xc0000000)
return 0;
if (kvm_rsp_read(env) == 0)
return 0;
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index e4fba78..0763f5a 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -827,7 +827,7 @@ static int must_use_aliases_target(target_phys_addr_t addr)
{
if (destroy_region_works)
return false;
- if (addr >= 0xe0000000 && addr < 0x100000000ull)
+ if (addr >= 0xc0000000 && addr < 0x100000000ull)
return true;
return false;
}
diff --git a/vgabios/vbe.h b/vgabios/vbe.h
index 60434ac..a199c7d 100644
--- a/vgabios/vbe.h
+++ b/vgabios/vbe.h
@@ -308,6 +308,6 @@ typedef struct ModeInfoListItem
#define VBE_DISPI_LFB_ENABLED 0x40
#define VBE_DISPI_NOCLEARMEM 0x80
- #define VBE_DISPI_LFB_PHYSICAL_ADDRESS 0xE0000000
+ #define VBE_DISPI_LFB_PHYSICAL_ADDRESS 0xC0000000
#endif
diff --git a/vgabios/vbe_display_api.txt b/vgabios/vbe_display_api.txt
index fddb78b..c6be039 100644
--- a/vgabios/vbe_display_api.txt
+++ b/vgabios/vbe_display_api.txt
@@ -119,7 +119,7 @@ vbe.h
#define VBE_DISPI_VBE_ENABLED 0x40
#define VBE_DISPI_NOCLEARMEM 0x80
- #define VBE_DISPI_LFB_PHYSICAL_ADDRESS 0xE0000000
+ #define VBE_DISPI_LFB_PHYSICAL_ADDRESS 0xC0000000
API
---
--
1.6.0.6
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000
2009-01-11 1:25 ` [PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000 Izik Eidus
@ 2009-01-17 0:57 ` Chris Wright
2009-01-17 1:23 ` Izik Eidus
0 siblings, 1 reply; 5+ messages in thread
From: Chris Wright @ 2009-01-17 0:57 UTC (permalink / raw
To: Izik Eidus; +Cc: kvm
* Izik Eidus (ieidus@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 0x100000000...,
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000
2009-01-17 0:57 ` Chris Wright
@ 2009-01-17 1:23 ` Izik Eidus
2009-01-18 8:41 ` Avi Kivity
0 siblings, 1 reply; 5+ messages in thread
From: Izik Eidus @ 2009-01-17 1:23 UTC (permalink / raw
To: Chris Wright; +Cc: kvm, avi
Chris Wright wrote:
> * Izik Eidus (ieidus@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 0x100000000...,
>> 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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000
2009-01-17 1:23 ` Izik Eidus
@ 2009-01-18 8:41 ` Avi Kivity
0 siblings, 0 replies; 5+ messages in thread
From: Avi Kivity @ 2009-01-18 8:41 UTC (permalink / raw
To: Izik Eidus; +Cc: Chris Wright, kvm
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-01-18 8:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-11 1:25 [PATCH 0/1] pci hole remaping Izik Eidus
2009-01-11 1:25 ` [PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000 Izik Eidus
2009-01-17 0:57 ` Chris Wright
2009-01-17 1:23 ` Izik Eidus
2009-01-18 8:41 ` Avi Kivity
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.