Izik, is this still needed?
From: Izik Eidus ieidus@redhat.com
The vbe was not registered as reserved memory, and therefore windows was able to try to map pci devices into this address range.
Signed-off-by: Marcelo Tosatti mtosatti@redhat.com
diff --git a/src/post.c b/src/post.c index fb3b37f..3a1be89 100644 --- a/src/post.c +++ b/src/post.c @@ -96,6 +96,9 @@ init_bda(void) ebda->size = esize; }
+#define VBE_DISPI_LFB_PHYSICAL_ADDRESS 0xE0000000 +#define VGA_RAM_SIZE (16 * 1024 * 1024) + static void ram_probe(void) { @@ -140,6 +143,8 @@ ram_probe(void) // other page for EPT real mode pagetable add_e820(0xfffbc000, 4*4096, E820_RESERVED);
+ add_e820(VBE_DISPI_LFB_PHYSICAL_ADDRESS, VGA_RAM_SIZE, E820_RESERVED); + dprintf(1, "Ram Size=0x%08x (0x%08x%08x high)\n" , RamSize, (u32)(RamSizeOver4G >> 32), (u32)RamSizeOver4G); }
On Sat, 23 Jan 2010 16:02:05 -0200 Marcelo Tosatti mtosatti@redhat.com wrote:
Izik, is this still needed?
Hi,
Look correct acording to the acpi spec.
From: Izik Eidus ieidus@redhat.com
The vbe was not registered as reserved memory, and therefore windows was able to try to map pci devices into this address range.
Signed-off-by: Marcelo Tosatti mtosatti@redhat.com
diff --git a/src/post.c b/src/post.c index fb3b37f..3a1be89 100644 --- a/src/post.c +++ b/src/post.c @@ -96,6 +96,9 @@ init_bda(void) ebda->size = esize; }
+#define VBE_DISPI_LFB_PHYSICAL_ADDRESS 0xE0000000 +#define VGA_RAM_SIZE (16 * 1024 * 1024)
static void ram_probe(void) { @@ -140,6 +143,8 @@ ram_probe(void) // other page for EPT real mode pagetable add_e820(0xfffbc000, 4*4096, E820_RESERVED);
- add_e820(VBE_DISPI_LFB_PHYSICAL_ADDRESS, VGA_RAM_SIZE, E820_RESERVED);
- dprintf(1, "Ram Size=0x%08x (0x%08x%08x high)\n" , RamSize, (u32)(RamSizeOver4G >> 32), (u32)RamSizeOver4G);
}
On Sat, Jan 23, 2010 at 04:02:05PM -0200, Marcelo Tosatti wrote:
Izik, is this still needed?
From: Izik Eidus ieidus@redhat.com
The vbe was not registered as reserved memory, and therefore windows was able to try to map pci devices into this address range.
Signed-off-by: Marcelo Tosatti mtosatti@redhat.com
It is not normal to add e820 entries for device memory. Also, it is not normal for a BIOS to add special mappings for video cards (how would it know what needed to be mapped). One exception to this would be machines with built-in video adapters where the video ram is shared with system ram - however, in that case the memory area would almost certainly be at the end of ram and not at a fixed location.
So, in general, this looks like a hack for VBE - can't we just fix this in the VBE code instead of adding it to the BIOS?
-Kevin
On Sat, 23 Jan 2010 15:37:12 -0500 "Kevin O'Connor" kevin@koconnor.net wrote:
On Sat, Jan 23, 2010 at 04:02:05PM -0200, Marcelo Tosatti wrote:
Izik, is this still needed?
From: Izik Eidus ieidus@redhat.com
The vbe was not registered as reserved memory, and therefore windows was able to try to map pci devices into this address range.
Signed-off-by: Marcelo Tosatti mtosatti@redhat.com
It is not normal to add e820 entries for device memory.
This is true for pci and isa hot plug devices, but how in this case we can tell the os not to map to this physical address pci devices?
If the range doesnt reserved I dont see how windows wont try to end up mapping pci devices to there.
not normal for a BIOS to add special mappings for video cards (how would it know what needed to be mapped). One exception to this would be machines with built-in video adapters where the video ram is shared with system ram - however, in that case the memory area would almost certainly be at the end of ram and not at a fixed location.
So, in general, this looks like a hack for VBE - can't we just fix this in the VBE code instead of adding it to the BIOS?
-Kevin
On Sat, Jan 23, 2010 at 11:30:33PM +0200, Izik Eidus wrote:
On Sat, 23 Jan 2010 15:37:12 -0500 "Kevin O'Connor" kevin@koconnor.net wrote:
It is not normal to add e820 entries for device memory.
This is true for pci and isa hot plug devices, but how in this case we can tell the os not to map to this physical address pci devices?
If the range doesnt reserved I dont see how windows wont try to end up mapping pci devices to there.
What is special about 0xe0000000 that the OS can't map pci devices there? Normal machines don't treat 0xe0000000 as special, why does the VBE device require that?
-Kevin
On Sat, 23 Jan 2010 18:10:37 -0500 "Kevin O'Connor" kevin@koconnor.net wrote:
On Sat, Jan 23, 2010 at 11:30:33PM +0200, Izik Eidus wrote:
On Sat, 23 Jan 2010 15:37:12 -0500 "Kevin O'Connor" kevin@koconnor.net wrote:
It is not normal to add e820 entries for device memory.
This is true for pci and isa hot plug devices, but how in this case we can tell the os not to map to this physical address pci devices?
If the range doesnt reserved I dont see how windows wont try to end up mapping pci devices to there.
What is special about 0xe0000000 that the OS can't map pci devices there? Normal machines don't treat 0xe0000000 as special, why does the VBE device require that?
From the last time I looked on the code 0xe0000000 was the LFB address, LFB is used by vesa devices as the framebuffer memory area, this mean that vesa devices (not the case for vga) will try to map this 0xe000000 physical memory.
The last real spec that I have checked x48 and as far as I remember it clearly said that the beahivor is unspecificed in case you map physical memory more than once.
To make life easier for us we can look on the acpi spec (3b) that say:
14.5 Example Address Map This sample address map (for an Intel processor-based system) describes a machine that has 128 MB of RAM, 640 KB of base memory and 127 MB of extended memory. The base memory has 639 KB available for the user and 1 KB for an extended BIOS data area. A 4-MB Linear Frame Buffer (LFB) is based at 12 MB. The memory hole created by the chip set is from 8 MB to 16 MB. Memory-mapped APIC devices are in the system. The I/O Unit is at FEC00000 and the Local Unit is at FEE00000. The system BIOS is remapped to 1 GB–64 KB. The 639-KB endpoint of the first memory range is also the base memory size reported in the BIOS data segment at 40:13. The following table shows the memory map of a typical system. Table 14-8 Sample Memory Map Base (Hex) Length Type Description 0000 0000 639 KB AddressRangeMemory Available Base memory. Typically the same value as is returned using the INT 12 function. Hewlett-Packard/Intel/Microsoft/Phoenix/Toshiba System Address Map Interfaces 399 Base (Hex) Length Type Description 0009 FC00 1 KB AddressRangeReserved Memory reserved for use by the BIOS(s). This area typically includes the Extended BIOS data area. 000F 0000 64 KB AddressRangeReserved System BIOS 0010 0000 7 MB AddressRangeMemory Extended memory, which is not limited to the 64-MB address range. 0080 0000 4 MB AddressRangeReserved Chip set memory hole required to support the LFB mapping at 12 MB. 0100 0000 120 MB AddressRangeMemory Baseboard RAM relocated above a chip set memory hole. FEC0 0000 4 KB AddressRangeReserved I/O APIC memory mapped I/O at FEC00000. FEE0 0000 4 KB AddressRangeReserved Local APIC memory mapped I/O at FEE00000. FFFF 0000 64 KB AddressRangeReserved Remapped System BIOS at end of address space.
So we can see that even the acpi spec example mark the LFB region as reserved.
Thanks.
-Kevin
On Sun, Jan 24, 2010 at 01:35:21AM +0200, Izik Eidus wrote:
On Sat, 23 Jan 2010 18:10:37 -0500 "Kevin O'Connor" kevin@koconnor.net wrote:
What is special about 0xe0000000 that the OS can't map pci devices there? Normal machines don't treat 0xe0000000 as special, why does the VBE device require that?
From the last time I looked on the code 0xe0000000 was the LFB address, LFB is used by vesa devices as the framebuffer memory area, this mean that vesa devices (not the case for vga) will try to map this 0xe000000 physical memory.
Okay, but why does the device hardcoded 0xe0000000 - why doesn't it use a PCI bar? A PCI bar should also be sufficient to stop the OS from mapping two things to the same address, and it has the advantage of not requiring special code in the BIOS.
-Kevin
On Sat, 23 Jan 2010 19:03:46 -0500 "Kevin O'Connor" kevin@koconnor.net wrote:
On Sun, Jan 24, 2010 at 01:35:21AM +0200, Izik Eidus wrote:
On Sat, 23 Jan 2010 18:10:37 -0500 "Kevin O'Connor" kevin@koconnor.net wrote:
What is special about 0xe0000000 that the OS can't map pci devices there? Normal machines don't treat 0xe0000000 as special, why does the VBE device require that?
From the last time I looked on the code 0xe0000000 was the LFB address, LFB is used by vesa devices as the framebuffer memory area, this mean that vesa devices (not the case for vga) will try to map this 0xe000000 physical memory.
Okay, but why does the device hardcoded 0xe0000000 - why doesn't it use a PCI bar? A PCI bar should also be sufficient to stop the OS from mapping two things to the same address, and it has the advantage of not requiring special code in the BIOS.
VESA standard is unrelated to pci devices, and therefore it can be used with isa devices...
For example spice start the system with the isa device and then only when there is a driver it move into the QXL device.
I have saw in QA bug that was just this case, windows tryed to map pci device into the lfb.
Thanks.
-Kevin
On Sun, Jan 24, 2010 at 02:18:43AM +0200, Izik Eidus wrote:
On Sat, 23 Jan 2010 19:03:46 -0500 "Kevin O'Connor" kevin@koconnor.net wrote:
On Sun, Jan 24, 2010 at 01:35:21AM +0200, Izik Eidus wrote:
On Sat, 23 Jan 2010 18:10:37 -0500 "Kevin O'Connor" kevin@koconnor.net wrote:
What is special about 0xe0000000 that the OS can't map pci devices there? Normal machines don't treat 0xe0000000 as special, why does the VBE device require that?
From the last time I looked on the code 0xe0000000 was the LFB address, LFB is used by vesa devices as the framebuffer memory area, this mean that vesa devices (not the case for vga) will try to map this 0xe000000 physical memory.
Okay, but why does the device hardcoded 0xe0000000 - why doesn't it use a PCI bar? A PCI bar should also be sufficient to stop the OS from mapping two things to the same address, and it has the advantage of not requiring special code in the BIOS.
VESA standard is unrelated to pci devices, and therefore it can be used with isa devices...
VGA shows up as a PCI device under qemu. Is there a reason why making the LFB part of a PCI bar of the VGA device will not work? Doing it that way seems like a simpler solution. It's also probably what real modern machines do.
-Kevin
On 01/24/2010 04:09 AM, Kevin O'Connor wrote:
VESA standard is unrelated to pci devices, and therefore it can be used with isa devices...
VGA shows up as a PCI device under qemu. Is there a reason why making the LFB part of a PCI bar of the VGA device will not work? Doing it that way seems like a simpler solution. It's also probably what real modern machines do.
-vga std is not a PCI device, therefore no BAR. Incidentally, we have a regression where VBE is not detected with qemu-0.12 and sesbios, this may be the cause.
On 01/24/2010 09:51 AM, Avi Kivity wrote:
On 01/24/2010 04:09 AM, Kevin O'Connor wrote:
VESA standard is unrelated to pci devices, and therefore it can be used with isa devices...
VGA shows up as a PCI device under qemu. Is there a reason why making the LFB part of a PCI bar of the VGA device will not work? Doing it that way seems like a simpler solution. It's also probably what real modern machines do.
-vga std is not a PCI device, therefore no BAR. Incidentally, we have a regression where VBE is not detected with qemu-0.12 and sesbios, this may be the cause.
That's not correct - when running with PCI -vga std _is_ a PCI device (and it has a BAR). What's needed is to make the VBE BIOS aware of it.
On 01/24/2010 04:16 AM, Avi Kivity wrote:
On 01/24/2010 09:51 AM, Avi Kivity wrote:
On 01/24/2010 04:09 AM, Kevin O'Connor wrote:
VESA standard is unrelated to pci devices, and therefore it can be used with isa devices...
VGA shows up as a PCI device under qemu. Is there a reason why making the LFB part of a PCI bar of the VGA device will not work? Doing it that way seems like a simpler solution. It's also probably what real modern machines do.
-vga std is not a PCI device, therefore no BAR. Incidentally, we have a regression where VBE is not detected with qemu-0.12 and sesbios, this may be the cause.
That's not correct - when running with PCI -vga std _is_ a PCI device (and it has a BAR). What's needed is to make the VBE BIOS aware of it.
I was under the impression that 0xE000... has a certain amount of significance beyond the fact that it was hardcoded in VGABIOS.
Certain versions of the VMware VGA driver assumed that the first region was mapped at 0xE000.. regardless of the contents of the BAR. We've had lots of problems with this over the years (in std vga too).
Regards,
Anthony Liguori
On 24.01.2010 14:58, Anthony Liguori wrote:
On 01/24/2010 04:16 AM, Avi Kivity wrote:
That's not correct - when running with PCI -vga std _is_ a PCI device (and it has a BAR). What's needed is to make the VBE BIOS aware of it.
I was under the impression that 0xE000... has a certain amount of significance beyond the fact that it was hardcoded in VGABIOS.
Yes, on quite a few current machines 0xE0000000 is the location of the PCI MMCONFIG area and AFAIK some drivers have that location hardcoded for PCI config space accesses (instead of ioports CF8/CFC). So while the address may be special, it is used for stuff besides VGA.
Regards, Carl-Daniel
On Sun, Jan 24, 2010 at 12:16:11PM +0200, Avi Kivity wrote:
That's not correct - when running with PCI -vga std _is_ a PCI device (and it has a BAR). What's needed is to make the VBE BIOS aware of it.
According to Sebastian, the latest version of vgabios (v0.6c) does support this. I see that the following was added to vbe.c:
+ lfb_addr = pci_get_lfb_addr(0x1234); // experimental vendor + if (lfb_addr > 0) { + info.PhysBasePtr = ((Bit32u)lfb_addr << 16); + }
The vgabios code could use an overhaul - it has many of the same maintenance problems that bochs bios has. A port to gcc would be a big help. Some time back, I ported the base vga code (see the vgasrc/ directory in seabios git), but I haven't looked at the cirrus or vbe extensions.
-Kevin
On 01/24/2010 08:18 PM, Kevin O'Connor wrote:
On Sun, Jan 24, 2010 at 12:16:11PM +0200, Avi Kivity wrote:
That's not correct - when running with PCI -vga std _is_ a PCI device (and it has a BAR). What's needed is to make the VBE BIOS aware of it.
According to Sebastian, the latest version of vgabios (v0.6c) does support this. I see that the following was added to vbe.c:
lfb_addr = pci_get_lfb_addr(0x1234); // experimental vendorif (lfb_addr> 0) {info.PhysBasePtr = ((Bit32u)lfb_addr<< 16);}
It's clear we should pull this for qemu.git master. But what about 0.12? I prefer going back to 0xf0* to reduce the risk for further regressions.
The vgabios code could use an overhaul - it has many of the same maintenance problems that bochs bios has. A port to gcc would be a big help. Some time back, I ported the base vga code (see the vgasrc/ directory in seabios git), but I haven't looked at the cirrus or vbe extensions.
That would be great, even though vgabios doesn't see much churn.
On 01/25/2010 09:06 AM, Avi Kivity wrote:
On 01/24/2010 08:18 PM, Kevin O'Connor wrote:
On Sun, Jan 24, 2010 at 12:16:11PM +0200, Avi Kivity wrote:
That's not correct - when running with PCI -vga std _is_ a PCI device (and it has a BAR). What's needed is to make the VBE BIOS aware of it.
According to Sebastian, the latest version of vgabios (v0.6c) does support this. I see that the following was added to vbe.c:
lfb_addr = pci_get_lfb_addr(0x1234); // experimentalvendor
if (lfb_addr> 0) {info.PhysBasePtr = ((Bit32u)lfb_addr<< 16);}It's clear we should pull this for qemu.git master. But what about 0.12? I prefer going back to 0xf0* to reduce the risk for further regressions.
This isn't a guest visible change so for 0.12, I would expect that bringing in the vgabios changes would be reasonable. I don't love the idea of carrying a different behaviour in SeaBIOS and VGABIOS for 0.12 than in master.
The vgabios code could use an overhaul - it has many of the same maintenance problems that bochs bios has. A port to gcc would be a big help. Some time back, I ported the base vga code (see the vgasrc/ directory in seabios git), but I haven't looked at the cirrus or vbe extensions.
That would be great, even though vgabios doesn't see much churn.
Yes, it would remove the BCC dependency on the build which would be really nice.
Regards,
Anthony Liguori
On 01/25/2010 05:45 PM, Anthony Liguori wrote:
On 01/25/2010 09:06 AM, Avi Kivity wrote:
On 01/24/2010 08:18 PM, Kevin O'Connor wrote:
On Sun, Jan 24, 2010 at 12:16:11PM +0200, Avi Kivity wrote:
That's not correct - when running with PCI -vga std _is_ a PCI device (and it has a BAR). What's needed is to make the VBE BIOS aware of it.
According to Sebastian, the latest version of vgabios (v0.6c) does support this. I see that the following was added to vbe.c:
lfb_addr = pci_get_lfb_addr(0x1234); //experimental vendor
if (lfb_addr> 0) {info.PhysBasePtr = ((Bit32u)lfb_addr<< 16);}It's clear we should pull this for qemu.git master. But what about 0.12? I prefer going back to 0xf0* to reduce the risk for further regressions.
This isn't a guest visible change so for 0.12, I would expect that bringing in the vgabios changes would be reasonable. I don't love the idea of carrying a different behaviour in SeaBIOS and VGABIOS for 0.12 than in master.
It's not guest visible unless it causes regressions. Who knows how this change can interact?
I understand the desire to track upstream, but that shouldn't take precedence over being conservative when applying patches. We should do the bare minimum that it takes to fix the bug, without disturbing unrelated functionality.
On 01/24/10 01:18, Izik Eidus wrote:
For example spice start the system with the isa device and then only when there is a driver it move into the QXL device.
Hmm, /me thinks this is a very bad idea. IMHO the std vga memory should be a normal PCI bar of the QXL device. Then you don't have this sort of problems in the first place ...
cheers, Gerd
On Mon, 25 Jan 2010 10:26:24 +0100 Gerd Hoffmann kraxel@redhat.com wrote:
On 01/24/10 01:18, Izik Eidus wrote:
For example spice start the system with the isa device and then only when there is a driver it move into the QXL device.
Hmm, /me thinks this is a very bad idea. IMHO the std vga memory should be a normal PCI bar of the QXL device. Then you don't have this sort of problems in the first place ...
Hi, It would be nice to use pci memory even for the "vga mode" of spice, But right now itwill require us to use 2 pci devices - one for the std-vga and one for the qxl, or there is a way to do this without using the secoend pci device?
cheers, Gerd
On 01/25/10 12:03, Izik Eidus wrote:
On Mon, 25 Jan 2010 10:26:24 +0100 Gerd Hoffmannkraxel@redhat.com wrote:
On 01/24/10 01:18, Izik Eidus wrote:
For example spice start the system with the isa device and then only when there is a driver it move into the QXL device.
Hmm, /me thinks this is a very bad idea. IMHO the std vga memory should be a normal PCI bar of the QXL device. Then you don't have this sort of problems in the first place ...
Hi, It would be nice to use pci memory even for the "vga mode" of spice, But right now itwill require us to use 2 pci devices - one for the std-vga and one for the qxl, or there is a way to do this without using the secoend pci device?
Make qxl look like a standard pci vga? i.e. class vga, have a rom bar for the bios, have a memory bar for the lfb. Additionally a second memory bar which is used as command/data fifo in spice mode.
cheers, Gerd
On Mon, 25 Jan 2010 13:15:24 +0100 Gerd Hoffmann kraxel@redhat.com wrote:
On 01/25/10 12:03, Izik Eidus wrote:
On Mon, 25 Jan 2010 10:26:24 +0100 Gerd Hoffmannkraxel@redhat.com wrote:
On 01/24/10 01:18, Izik Eidus wrote:
For example spice start the system with the isa device and then only when there is a driver it move into the QXL device.
Hmm, /me thinks this is a very bad idea. IMHO the std vga memory should be a normal PCI bar of the QXL device. Then you don't have this sort of problems in the first place ...
Hi, It would be nice to use pci memory even for the "vga mode" of spice, But right now itwill require us to use 2 pci devices - one for the std-vga and one for the qxl, or there is a way to do this without using the secoend pci device?
Make qxl look like a standard pci vga? i.e. class vga, have a rom bar for the bios, have a memory bar for the lfb. Additionally a second memory bar which is used as command/data fifo in spice mode.
That is possibilty, Gerd, I will catch you on this before we send spice to qemu upstream.
cheers, Gerd
Hi Izik,
On 24.01.2010 00:35, Izik Eidus wrote:
To make life easier for us we can look on the acpi spec (3b) that say:
14.5 Example Address Map This sample address map (for an Intel processor-based system) describes a machine that has 128 MB of RAM, 640 KB of base memory and 127 MB of extended memory. The base memory has 639 KB available for the user and 1 KB for an extended BIOS data area. A 4-MB Linear Frame Buffer (LFB) is based at 12 MB. The memory hole created by the chip set is from 8 MB to 16 MB. Memory-mapped APIC devices are in the system. The I/O Unit is at FEC00000 and the Local Unit is at FEE00000. The system BIOS is remapped to 1 GB–64 KB.
The sentence above is a bug in the spec. The system BIOS is remapped to 4 GB - 64 kB (not 1 GB - 64 kB).
The 639-KB endpoint of the first memory range is also the base memory size reported in the BIOS data segment at 40:13. The following table shows the memory map of a typical system. Table 14-8 Sample Memory Map Base (Hex) Length Type Description 0000 0000 639 KB AddressRangeMemory Available Base memory. Typically the same value as is returned using the INT 12 function. Hewlett-Packard/Intel/Microsoft/Phoenix/Toshiba System Address Map Interfaces 399 Base (Hex) Length Type Description 0009 FC00 1 KB AddressRangeReserved Memory reserved for use by the BIOS(s). This area typically includes the Extended BIOS data area. 000F 0000 64 KB AddressRangeReserved System BIOS 0010 0000 7 MB AddressRangeMemory Extended memory, which is not limited to the 64-MB address range. 0080 0000 4 MB AddressRangeReserved Chip set memory hole required to support the LFB mapping at 12 MB. 0100 0000 120 MB AddressRangeMemory Baseboard RAM relocated above a chip set memory hole. FEC0 0000 4 KB AddressRangeReserved I/O APIC memory mapped I/O at FEC00000. FEE0 0000 4 KB AddressRangeReserved Local APIC memory mapped I/O at FEE00000. FFFF 0000 64 KB AddressRangeReserved Remapped System BIOS at end of address space.
So we can see that even the acpi spec example mark the LFB region as reserved.
No, the memory hole is marked as reserved. The LFB region is not listed above.
Regards, Carl-Daniel
On Sun, 24 Jan 2010 15:26:55 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
So we can see that even the acpi spec example mark the LFB region as reserved.
No, the memory hole is marked as reserved. The LFB region is not listed above.
But how in case you use vesa with isa, windows will know it cant remap pci devices into that physical address?
Regards, Carl-Daniel
On 24.01.2010 16:32, Izik Eidus wrote:
On Sun, 24 Jan 2010 15:26:55 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
So we can see that even the acpi spec example mark the LFB region as reserved.
No, the memory hole is marked as reserved. The LFB region is not listed above.
But how in case you use vesa with isa, windows will know it cant remap pci devices into that physical address?
ISA only supports 24 bit addresses anyway, so you can't map any resource of an ISA card above 16 MByte. That means an ISA device will never use the region at 0xE0000000.
http://www.microsoft.com/whdc/connect/pci/isa-bus.mspx implies that the ISAPNP interface of the BIOS is available for querying any resources, so in case you have an EISA device and if that device can indeed use full 32 bit addressing (very unusual for EISA hardware) you can still ask the BIOS to retrieve the location of any memory regions.
Regards, Carl-Daniel
On Sun, 24 Jan 2010 17:10:46 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.01.2010 16:32, Izik Eidus wrote:
On Sun, 24 Jan 2010 15:26:55 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
So we can see that even the acpi spec example mark the LFB region as reserved.
No, the memory hole is marked as reserved. The LFB region is not listed above.
But how in case you use vesa with isa, windows will know it cant remap pci devices into that physical address?
ISA only supports 24 bit addresses anyway, so you can't map any resource of an ISA card above 16 MByte. That means an ISA device will never use the region at 0xE0000000.
http://www.microsoft.com/whdc/connect/pci/isa-bus.mspx implies that the ISAPNP interface of the BIOS is available for querying any resources, so in case you have an EISA device and if that device can indeed use full 32 bit addressing (very unusual for EISA hardware) you can still ask the BIOS to retrieve the location of any memory regions.
we are talking here about the framebuffer of the vesa device, it is hardcoded mapped by the vgabios, for example qemu will map it to that address (or 0xf000000) if they changed it.
It is sure being used by std vga when not working with pci.
int isa_vga_init(void) { VGACommonState *s;
s = qemu_mallocz(sizeof(*s));
vga_common_init(s, VGA_RAM_SIZE); vga_init(s); vmstate_register(0, &vmstate_vga_common, s);
s->ds = graphic_console_init(s->update, s->invalidate, s->screen_dump, s->text_update, s);
#ifdef CONFIG_BOCHS_VBE /* XXX: use optimized standard vga accesses */ cpu_register_physical_memory(VBE_DISPI_LFB_PHYSICAL_ADDRESS, VGA_RAM_SIZE, s->vram_offset); #endif /* ROM BIOS */ rom_add_vga(VGABIOS_FILENAME); return 0; }
Thanks.
Regards, Carl-Daniel
On 24.01.2010 17:16, Izik Eidus wrote:
On Sun, 24 Jan 2010 17:10:46 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.01.2010 16:32, Izik Eidus wrote:
On Sun, 24 Jan 2010 15:26:55 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
So we can see that even the acpi spec example mark the LFB region as reserved.
No, the memory hole is marked as reserved. The LFB region is not listed above.
But how in case you use vesa with isa, windows will know it cant remap pci devices into that physical address?
ISA only supports 24 bit addresses anyway, so you can't map any resource of an ISA card above 16 MByte. That means an ISA device will never use the region at 0xE0000000.
http://www.microsoft.com/whdc/connect/pci/isa-bus.mspx implies that the ISAPNP interface of the BIOS is available for querying any resources, so in case you have an EISA device and if that device can indeed use full 32 bit addressing (very unusual for EISA hardware) you can still ask the BIOS to retrieve the location of any memory regions.
we are talking here about the framebuffer of the vesa device, it is hardcoded mapped by the vgabios, for example qemu will map it to that address (or 0xf000000) if they changed it.
Earlier, you wrote "vesa with isa". If Qemu or the VGABIOS maps the vesa framebuffer of an ISA device at any address above 16 MB, that is a bug because it would be impossible on real hardware.
It is sure being used by std vga when not working with pci.
int isa_vga_init(void) { VGACommonState *s;
s = qemu_mallocz(sizeof(*s)); vga_common_init(s, VGA_RAM_SIZE); vga_init(s); vmstate_register(0, &vmstate_vga_common, s); s->ds = graphic_console_init(s->update, s->invalidate, s->screen_dump, s->text_update, s);#ifdef CONFIG_BOCHS_VBE /* XXX: use optimized standard vga accesses */ cpu_register_physical_memory(VBE_DISPI_LFB_PHYSICAL_ADDRESS, VGA_RAM_SIZE, s->vram_offset);
That looks like a bug. If you're talking about an ISA device, the LFB must be smaller than 16 MB and its upper end must be at 16 MB or below. If you only allow power-of-two sizes, the maximum LFB size is 8 MB located at 8 MB. (LFB size of 16 MB is not allowed because it would mean the lowest 640 kB are part of the LFB.) If the device is EISA (instead of ISA) it can work, but I think you need the full PNPBIOS extensions for it to work (AFAIK isapnptools have readable docs/code and could help to find out what is needed).
#endif /* ROM BIOS */ rom_add_vga(VGABIOS_FILENAME); return 0; }
Thanks for quoting that code.
Regards, Carl-Daniel
On Sun, 24 Jan 2010 17:45:25 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
That looks like a bug. If you're talking about an ISA device, the LFB must be smaller than 16 MB and its upper end must be at 16 MB or below. If you only allow power-of-two sizes, the maximum LFB size is 8 MB located at 8 MB. (LFB size of 16 MB is not allowed because it would mean the lowest 640 kB are part of the LFB.) If the device is EISA (instead of ISA) it can work, but I think you need the full PNPBIOS extensions for it to work (AFAIK isapnptools have readable docs/code and could help to find out what is needed).
I think this code probably fall into the eisa catagory, But I am confused about what the direction you offer to solve this problem.
The acpi spec does mention that PNP devices does not have to be reported.
But considering the qemu code we have right now I think this is the only right fix to make the isa_sta_vga safe.
Thanks.
#endif /* ROM BIOS */ rom_add_vga(VGABIOS_FILENAME); return 0; }
Thanks for quoting that code.
Regards, Carl-Daniel
On 24.01.2010 18:18, Izik Eidus wrote:
On Sun, 24 Jan 2010 17:45:25 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
That looks like a bug. If you're talking about an ISA device, the LFB must be smaller than 16 MB and its upper end must be at 16 MB or below. If you only allow power-of-two sizes, the maximum LFB size is 8 MB located at 8 MB. (LFB size of 16 MB is not allowed because it would mean the lowest 640 kB are part of the LFB.) If the device is EISA (instead of ISA) it can work, but I think you need the full PNPBIOS extensions for it to work (AFAIK isapnptools have readable docs/code and could help to find out what is needed).
I think this code probably fall into the eisa catagory,
Yes, probably.
But I am confused about what the direction you offer to solve this problem.
If it is pure ISA, I do not think we can solve the problem unless we place a 8 MB LFB at address 8-16 MB. If it is EISA, I propose to use the PNPBIOS extensions because most OS check these extensions before allocating (PCI) resources.
The acpi spec does mention that PNP devices does not have to be reported.
Hm. If the PNP devices are not reported in the ACPI tables, they should still be visible via the PNPBIOS extensions. We may have to extend the VGABIOS or SeaBIOS for this (I didn't check).
But considering the qemu code we have right now I think this is the only right fix to make the isa_sta_vga safe.
"this" == Adding the devices to the ACPI table?
Regards, Carl-Daniel
On Mon, 25 Jan 2010 05:40:50 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.01.2010 18:18, Izik Eidus wrote:
On Sun, 24 Jan 2010 17:45:25 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
That looks like a bug. If you're talking about an ISA device, the LFB must be smaller than 16 MB and its upper end must be at 16 MB or below. If you only allow power-of-two sizes, the maximum LFB size is 8 MB located at 8 MB. (LFB size of 16 MB is not allowed because it would mean the lowest 640 kB are part of the LFB.) If the device is EISA (instead of ISA) it can work, but I think you need the full PNPBIOS extensions for it to work (AFAIK isapnptools have readable docs/code and could help to find out what is needed).
I think this code probably fall into the eisa catagory,
Yes, probably.
But I am confused about what the direction you offer to solve this problem.
If it is pure ISA, I do not think we can solve the problem unless we place a 8 MB LFB at address 8-16 MB. If it is EISA, I propose to use the PNPBIOS extensions because most OS check these extensions before allocating (PCI) resources.
The acpi spec does mention that PNP devices does not have to be reported.
Hm. If the PNP devices are not reported in the ACPI tables, they should still be visible via the PNPBIOS extensions. We may have to extend the VGABIOS or SeaBIOS for this (I didn't check).
But considering the qemu code we have right now I think this is the only right fix to make the isa_sta_vga safe.
"this" == Adding the devices to the ACPI table?
Yes only the LFB, but anyway I dont mind to fix this thing using the PNPBIOS.
Regards, Carl-Daniel
-
Anthony Liguori -
Avi Kivity -
Carl-Daniel Hailfinger -
Gerd Hoffmann -
Izik Eidus -
Kevin O'Connor -
Marcelo Tosatti