Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Leendert van Doorn wrote: Avi wrote: This is worrying as it will cause us to diverge from upstream bochs bios. Yep. I'll create a less invasive patch. I've been looking at SEABIOS which seems a much better alternative but the GPLv3 license worries me, especially when you have proprietary guests that calls back into it. Surely, the BIOS call interface is a GPL boundary, just like the Linux syscall interface. Kevin, is that not the case? If it is a GPL interface, can you add an explicit exception to make it clear? Can you elaborate? Since we're running the card's bios again, won't it initialize correctly? The problem is that the device-assignment code doesn't update the cards BARs, it just emulates them and maps the guest BARs onto the correct host BARs. Unfortunately, the graphics card has undocumented interfaces for obtaining the memory regions (faster than a full PCI lookup) and they of course return the host mappings as opposed to the guest mappings. !...@#$%^. My first attempt was to implement a state machine that would emulate these interfaces and rewrite them but this got pretty ugly pretty fast. No doubt. And it wouldn't work for cards where we don't know about these interfaces, or where we directly assign the mmio regions that implement these interfaces. Ensuring the same mappings was much cleaner. With a switch, please. Default behaviour should be to virtualize. One way to implement it is to pass pci devfn - BAR hints through the firmware interface. This way you can choose which BARs to place where, and where to allow the default placement. Of course, my goal is to run unmodified BIOS/drivers. You could always change the drivers. Not Windows drivers. I'll clean things up and resubmit. Thanks. -- 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][v2] kvm-userspace: Load PCI option ROMs
Avi Kivity wrote: Surely, the BIOS call interface is a GPL boundary, just like the Linux syscall interface. Kevin, is that not the case? If it is a GPL interface, can you add an explicit exception to make it clear? s/GPL interface/GPL boundary/. Must be clear on this lawyer talk. -- 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][v2] kvm-userspace: Load PCI option ROMs
On Sun, Jan 04, 2009 at 07:28:50PM +0200, Avi Kivity wrote: Leendert van Doorn wrote: Avi wrote: This is worrying as it will cause us to diverge from upstream bochs bios. Yep. I'll create a less invasive patch. I've been looking at SEABIOS which seems a much better alternative but the GPLv3 license worries me, especially when you have proprietary guests that calls back into it. Surely, the BIOS call interface is a GPL boundary, just like the Linux syscall interface. Kevin, is that not the case? If it is a GPL interface, can you add an explicit exception to make it clear? I would not want the SeaBIOS license to extend to an emulator that deploys SeaBIOS nor to any regular real-mode apps that call SeaBIOS handlers. I'd be happy to make this explicit. -Kevin -- 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][v2] kvm-userspace: Load PCI option ROMs
Avi wrote: This is worrying as it will cause us to diverge from upstream bochs bios. Yep. I'll create a less invasive patch. I've been looking at SEABIOS which seems a much better alternative but the GPLv3 license worries me, especially when you have proprietary guests that calls back into it. #if BX_ROMBIOS32 call rombios32_init #else @@ -10665,7 +10661,12 @@ post_default_ints: call pcibios_init_iomem_bases call pcibios_init_irqs #endif //BX_PCIBIOS -#endif + mov cx, #0xc000 ;; init vga bios + mov ax, #0xc780 + call rom_scan +#endif //BX_ROMBIOS32 + + call _print_bios_banner If one assigns a graphics card, it should replace the cirrus vga bios; that should make this change unnecessary. You have to initialize the PCI subsystem before you can initialize the VGABIOS. The PCI bus scan may have discovered the primary graphics adapter and copied its BIOS to 0xC. By convention the primary VGA adapter ROM always resides at 0xC. I also have a patch for the cirrus-vga emulation so that it properly emulates the PCI ROM BAR. I'll clean that up and submit it. +/* + * Some complex PCI devices (such as graphic controllers) + * keep lots of internal state, including their PCI mappings + * that were determined at initial PCI configuration. + * To make them work under QEMU/KVM, we preserve the host's + * PCI mappings in the guest. + * (we have to do this twice to ensure we update the mappings) + */ Can you elaborate? Since we're running the card's bios again, won't it initialize correctly? The problem is that the device-assignment code doesn't update the cards BARs, it just emulates them and maps the guest BARs onto the correct host BARs. Unfortunately, the graphics card has undocumented interfaces for obtaining the memory regions (faster than a full PCI lookup) and they of course return the host mappings as opposed to the guest mappings. My first attempt was to implement a state machine that would emulate these interfaces and rewrite them but this got pretty ugly pretty fast. Ensuring the same mappings was much cleaner. Of course, my goal is to run unmodified BIOS/drivers. You could always change the drivers. Keeping the same mapping in the host and guest may not be possible in some circumstances (differently sized pci holes, or using a 64-bit BAR in a 64-bit host but running a 32-bit guest that cannot utilize 64-bit BARs). Yes but that all depends on what the host BIOS does. Most of my experiments have been on a Dell optiplex 755 where all the PCI BARs are allocated at the top of the 32-bit range (I run a 64-bit host and 32-bit guest). Arguably, my rombios patch should do more validation than it does today. Other than that, the patch looks pretty good. It will need some massaging before merging, but nothing serious. I'll clean things up and resubmit. Leendert -- 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][v2] kvm-userspace: Load PCI option ROMs
Leendert van Doorn wrote:
I've been experimenting with passthru graphics for KVM and for that I needed
to add PCI ROM support to QEMU. I went a slightly different route than
Haitoa, I enabled the BIOS to do the PCI ROM mapping and initialization and
added support for QEMU to fully implement the ROM BAR. This patch also uses
the host BAR addresses in the guest for direct assigned devices, because (as
Avi already pointed out) this is needed for more complex PCI cards such as
graphics adapters. My patch also allows you to optionally specify the ROM
image, which I found very useful for debugging.
My ROMBIOS patches are probably more invasive than necessary. I found it
cleaner (==easier to understand) to call the rombios from 32-bit mode than
leave some droppings (option rom address, bdf) in the BIOS extended data
segment. The other thing you notice is that I initialize the primary VGA ROM
last. I found that this was necessary when emulating dual headed displays
(one display on qemu's emulation window, the other the actual device).
I've attached my patches.
Note that I have not included the full graphics passthru patches yet. I have
that working for the xorg ati drivers (and ATI's ATOMBIOS) but not for the
closed sourced or Windows drivers yet. Let me know if you are interested in
those patches.
This is very interesting.
@@ -10194,6 +10195,7 @@ no_serial:
pop dx
ret
+#if !BX_ROMBIOS32
rom_checksum:
push ax
push bx
@@ -10266,7 +10268,6 @@ block_count_rounded:
mov ax, #0xf000
mov es, ax
lea di, pnp_string
-
mov bp, sp ;; Call ROM init routine using seg:off on stack
db 0xff ;; call_far ss:[bp+0]
db 0x5e
@@ -10348,6 +10349,7 @@ rom_scan_increment:
xor ax, ax ;; Restore DS back to :
mov ds, ax
ret
+#endif /* !BX_ROMBIOS32 */
This is worrying as it will cause us to diverge from upstream bochs bios.
post_enable_cache:
;; enable cache
@@ -10652,12 +10654,6 @@ post_default_ints:
;; PIC
call post_init_pic
- mov cx, #0xc000 ;; init vga bios
- mov ax, #0xc780
- call rom_scan
-
- call _print_bios_banner
-
#if BX_ROMBIOS32
call rombios32_init
#else
@@ -10665,7 +10661,12 @@ post_default_ints:
call pcibios_init_iomem_bases
call pcibios_init_irqs
#endif //BX_PCIBIOS
-#endif
+ mov cx, #0xc000 ;; init vga bios
+ mov ax, #0xc780
+ call rom_scan
+#endif //BX_ROMBIOS32
+
+ call _print_bios_banner
If one assigns a graphics card, it should replace the cirrus vga bios;
that should make this change unnecessary.
@@ -953,18 +955,21 @@ static void pci_bios_init_device(PCIDevice *d)
default_map:
/* default memory mappings */
for(i = 0; i PCI_NUM_REGIONS; i++) {
+uint32_t orig, addr, val, size;
int ofs;
-uint32_t val, size ;
if (i == PCI_ROM_SLOT)
ofs = 0x30;
else
ofs = 0x10 + i * 4;
+orig = pci_config_readl(d, ofs);
pci_config_writel(d, ofs, 0x);
val = pci_config_readl(d, ofs);
if (val != 0) {
size = (~(val ~0xf)) + 1;
-if (val PCI_ADDRESS_SPACE_IO)
+ if (i == PCI_ROM_SLOT)
+ paddr = pci_bios_mem_addr;
+ else if (val PCI_ADDRESS_SPACE_IO)
paddr = pci_bios_io_addr;
else if (size = 0x0400)
paddr = pci_bios_bigmem_addr;
@@ -972,7 +977,24 @@ static void pci_bios_init_device(PCIDevice *d)
paddr = pci_bios_mem_addr;
*paddr = (*paddr + size - 1) ~(size - 1);
pci_set_io_region_addr(d, i, *paddr);
+ BX_INFO(PCI: region %d: paddr 0x%x, size 0x%x\n,
+ i, *paddr, size);
*paddr += size;
+
+ /*
+* Some complex PCI devices (such as graphic controllers)
+* keep lots of internal state, including their PCI mappings
+* that were determined at initial PCI configuration.
+* To make them work under QEMU/KVM, we preserve the host's
+* PCI mappings in the guest.
+* (we have to do this twice to ensure we update the
mappings)
+*/
Can you elaborate? Since we're running the card's bios again, won't it
initialize correctly?
Keeping the same mapping in the host and guest may not be possible in
some circumstances (differently sized pci holes, or using a 64-bit BAR
in a 64-bit host but running a 32-bit guest that cannot utilize 64-bit
BARs).
Other than that, the patch looks pretty good. It will need some
massaging before merging, but nothing serious.
--
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
Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Leendert van Doorn wrote: With a switch, please. Default behaviour should be to virtualize. One way to implement it is to pass pci devfn - BAR hints through the firmware interface. This way you can choose which BARs to place where, and where to allow the default placement. I'm already providing the hints, but you are proposing that the default behavior for the BIOS should be to allocate BARs and when given a flag it should try to preserve the host BAR mappings. I can do that. It's a general policy -- isolate the guest from the host wherever possible. In a few cases it isn't possible (time) and it really hurts. Of course, my goal is to run unmodified BIOS/drivers. You could always change the drivers. Not Windows drivers. Well, at least I have a fighting chance to change the ATI windows drivers :-) :-) -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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][v2] kvm-userspace: Load PCI option ROMs
Avi wrote: Surely, the BIOS call interface is a GPL boundary, just like the Linux syscall interface. Kevin, is that not the case? If it is a GPL interface, can you add an explicit exception to make it clear? At IBM we had many discussions about what precisely constitutes a GPL boundary. Especially when you are examining internal BIOS data structures (which most kernels do when accessing the BIOS). In the end Legal advised us that LGPL was ok and GPL was not. This was all in the context of v2 so things may have changed with v3. I don't want this to turn into a GPL versus LGPL argument because I'm not a lawyer either. If the KVM project picks up SEABIOS I'm all for it because it is much cleaner and easier to maintain. Ensuring the same mappings was much cleaner. With a switch, please. Default behaviour should be to virtualize. One way to implement it is to pass pci devfn - BAR hints through the firmware interface. This way you can choose which BARs to place where, and where to allow the default placement. I'm already providing the hints, but you are proposing that the default behavior for the BIOS should be to allocate BARs and when given a flag it should try to preserve the host BAR mappings. I can do that. Of course, my goal is to run unmodified BIOS/drivers. You could always change the drivers. Not Windows drivers. Well, at least I have a fighting chance to change the ATI windows drivers :-) Leendert -- 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][v2] kvm-userspace: Load PCI option ROMs
Sorry I made some mistakes concerning ROM BAR.
Although pci_default_write_config supports ROM BAR write emulation,
assigned_dev_pci_write_config does not invoke that function. The little patch
below shows where and when the function will be invoked.
Also initial mapping for ROM BAR is not setup in init_assigned_device. However,
I do not why they are not there.
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
index 7a5..129d350 100644
--- a/qemu/hw/device-assignment.c
+++ b/qemu/hw/device-assignment.c
@@ -237,7 +237,7 @@ static void assigned_dev_pci_write_config(PCIDevice *d, uint
/* Continue to program the card */
}
-if ((address = 0x10 address = 0x24) || address == 0x34 ||
+if ((address = 0x10 address = 0x24) || address == 0x30 ||
address == 0x3c || address == 0x3d) {
/* used for update-mappings (BAR emulation) */
pci_default_write_config(d, address, val, len);
Best Regards
Haitao Shan
Avi Kivity wrote:
Shan, Haitao wrote:
Hi, Avi,
Option ROM already has its own BAR at 0x30h. I think the devices
assignment code now already handles this register.
Okay good.
Can I summary your proposals like the following: In guest BIOS, scan
all the pci devices (virtual) for existance of Option ROMs. Copy
them to available BIOS space in 0xC - 0xD. Execute the ROM
code at copied location.
Yes.
I don't understand why this makes differences compared to scanning
and copying Option ROMs in QEMU,
If the ROM BAR is already handled (including registering the memory
when the BAR is programmed -- I don't see that in the code), then
there is no big advantage. It's closer to how real hardware works,
but that's about it.
especially given that the VGA BIOS and etherboot ROM are also copied
to BIOS space in QEMU before they execute in rom_scan loop in guest
BIOS.
The VGA BIOS is typically present on the motherboard itself, at least
on some configurations. You're right about etherboot.
I'll apply the patch. Can you take a look at the ROM BAR?--
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][v2] kvm-userspace: Load PCI option ROMs
I've been experimenting with passthru graphics for KVM and for that I needed
to add PCI ROM support to QEMU. I went a slightly different route than
Haitoa, I enabled the BIOS to do the PCI ROM mapping and initialization and
added support for QEMU to fully implement the ROM BAR. This patch also uses
the host BAR addresses in the guest for direct assigned devices, because (as
Avi already pointed out) this is needed for more complex PCI cards such as
graphics adapters. My patch also allows you to optionally specify the ROM
image, which I found very useful for debugging.
My ROMBIOS patches are probably more invasive than necessary. I found it
cleaner (==easier to understand) to call the rombios from 32-bit mode than
leave some droppings (option rom address, bdf) in the BIOS extended data
segment. The other thing you notice is that I initialize the primary VGA ROM
last. I found that this was necessary when emulating dual headed displays
(one display on qemu's emulation window, the other the actual device).
I've attached my patches.
Note that I have not included the full graphics passthru patches yet. I have
that working for the xorg ati drivers (and ATI's ATOMBIOS) but not for the
closed sourced or Windows drivers yet. Let me know if you are interested in
those patches.
Leendert
diff --git a/bios/rombios.c b/bios/rombios.c
index b7a240f..c8ef8ac 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -10130,7 +10130,7 @@ rombios32_real_mode:
ret
rombios32_gdt_48:
- dw 0x30
+ dw 0x38
dw rombios32_gdt
dw 0x000f
@@ -10141,6 +10141,7 @@ rombios32_gdt:
dw 0x, 0, 0x9300, 0x00cf ; 32 bit flat data segment (0x18)
dw 0x, 0, 0x9b0f, 0x ; 16 bit code segment base=0xf
limit=0x
dw 0x, 0, 0x9300, 0x ; 16 bit data segment base=0x0 limit=0x
+ dw 0x, 0, 0x9b0e, 0x ; 16 bit code segment base=0xE
limit=0x
#endif // BX_ROMBIOS32
@@ -10194,6 +10195,7 @@ no_serial:
pop dx
ret
+#if !BX_ROMBIOS32
rom_checksum:
push ax
push bx
@@ -10266,7 +10268,6 @@ block_count_rounded:
mov ax, #0xf000
mov es, ax
lea di, pnp_string
-
mov bp, sp ;; Call ROM init routine using seg:off on stack
db 0xff ;; call_far ss:[bp+0]
db 0x5e
@@ -10348,6 +10349,7 @@ rom_scan_increment:
xor ax, ax ;; Restore DS back to :
mov ds, ax
ret
+#endif /* !BX_ROMBIOS32 */
post_enable_cache:
;; enable cache
@@ -10652,12 +10654,6 @@ post_default_ints:
;; PIC
call post_init_pic
- mov cx, #0xc000 ;; init vga bios
- mov ax, #0xc780
- call rom_scan
-
- call _print_bios_banner
-
#if BX_ROMBIOS32
call rombios32_init
#else
@@ -10665,7 +10661,12 @@ post_default_ints:
call pcibios_init_iomem_bases
call pcibios_init_irqs
#endif //BX_PCIBIOS
-#endif
+ mov cx, #0xc000 ;; init vga bios
+ mov ax, #0xc780
+ call rom_scan
+#endif //BX_ROMBIOS32
+
+ call _print_bios_banner
;;
;; Floppy setup
@@ -10698,9 +10699,11 @@ post_default_ints:
call _init_boot_vectors
+#if !BX_ROMBIOS32
mov cx, #0xc800 ;; init option roms
mov ax, #0xe000
call rom_scan
+#endif
#if BX_ELTORITO_BOOT
call _interactive_bootkey
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 321563d..580aa17 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -1,4 +1,4 @@
-/
+
// $Id: rombios32.c,v 1.11 2007/08/03 13:56:13 vruppert Exp $
/
//
@@ -679,6 +679,7 @@ typedef struct PCIDevice {
int devfn;
} PCIDevice;
+static int pci_bios_nvga = 0;
static uint32_t pci_bios_io_addr;
static uint32_t pci_bios_mem_addr;
static uint32_t pci_bios_bigmem_addr;
@@ -736,7 +737,7 @@ static void pci_set_io_region_addr(PCIDevice *d, int
region_num, uint32_t addr)
old_addr = pci_config_readl(d, ofs);
pci_config_writel(d, ofs, addr);
-BX_INFO(region %d: 0x%08x\n, region_num, addr);
+// BX_INFO(region %d: 0x%08x\n, region_num, addr);
/* enable memory mappings */
cmd = pci_config_readw(d, PCI_COMMAND);
@@ -928,6 +929,7 @@ static void pci_bios_init_device(PCIDevice *d)
}
break;
case 0x0300: /* Display controller - VGA compatible controller */
+ pci_bios_nvga++;
if (vendor_id != 0x1234)
goto default_map;
/* VGA: map frame buffer to default Bochs VBE address */
@@ -953,18 +955,21 @@ static void pci_bios_init_device(PCIDevice *d)
default_map:
/* default memory mappings */
for(i = 0; i PCI_NUM_REGIONS; i++) {
+uint32_t orig, addr, val, size;
int ofs;
-uint32_t val, size ;
if (i == PCI_ROM_SLOT)
ofs = 0x30;
else
ofs = 0x10 + i * 4;
+orig = pci_config_readl(d, ofs);
RE: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Ah, your approach is much better than mine.
Please ignore ours.
Best Regards
Haitao Shan
Leendert van Doorn wrote:
I've been experimenting with passthru graphics for KVM and for that I
needed to add PCI ROM support to QEMU. I went a slightly different
route than Haitoa, I enabled the BIOS to do the PCI ROM mapping and
initialization and added support for QEMU to fully implement the ROM
BAR. This patch also uses the host BAR addresses in the guest for
direct assigned devices, because (as Avi already pointed out) this is
needed for more complex PCI cards such as graphics adapters. My patch
also allows you to optionally specify the ROM image, which I found
very useful for debugging.
My ROMBIOS patches are probably more invasive than necessary. I found
it cleaner (==easier to understand) to call the rombios from 32-bit
mode than leave some droppings (option rom address, bdf) in the BIOS
extended data segment. The other thing you notice is that I
initialize the primary VGA ROM last. I found that this was necessary
when emulating dual headed displays (one display on qemu's emulation
window, the other the actual device).
I've attached my patches.
Note that I have not included the full graphics passthru patches yet.
I have that working for the xorg ati drivers (and ATI's ATOMBIOS) but
not for the closed sourced or Windows drivers yet. Let me know if you
are interested in those patches.
Leendert
diff --git a/bios/rombios.c b/bios/rombios.c
index b7a240f..c8ef8ac 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -10130,7 +10130,7 @@ rombios32_real_mode:
ret
rombios32_gdt_48:
- dw 0x30
+ dw 0x38
dw rombios32_gdt
dw 0x000f
@@ -10141,6 +10141,7 @@ rombios32_gdt:
dw 0x, 0, 0x9300, 0x00cf ; 32 bit flat data segment (0x18)
dw 0x, 0, 0x9b0f, 0x ; 16 bit code segment base=0xf
limit=0x
dw 0x, 0, 0x9300, 0x ; 16 bit data segment base=0x0
limit=0x + dw 0x, 0, 0x9b0e, 0x ; 16 bit code segment
base=0xE limit=0x
#endif // BX_ROMBIOS32
@@ -10194,6 +10195,7 @@ no_serial:
pop dx
ret
+#if !BX_ROMBIOS32
rom_checksum:
push ax
push bx
@@ -10266,7 +10268,6 @@ block_count_rounded:
mov ax, #0xf000
mov es, ax
lea di, pnp_string
-
mov bp, sp ;; Call ROM init routine using seg:off on stack
db 0xff ;; call_far ss:[bp+0]
db 0x5e
@@ -10348,6 +10349,7 @@ rom_scan_increment:
xor ax, ax ;; Restore DS back to :
mov ds, ax
ret
+#endif /* !BX_ROMBIOS32 */
post_enable_cache:
;; enable cache
@@ -10652,12 +10654,6 @@ post_default_ints:
;; PIC
call post_init_pic
- mov cx, #0xc000 ;; init vga bios
- mov ax, #0xc780
- call rom_scan
-
- call _print_bios_banner
-
#if BX_ROMBIOS32
call rombios32_init
#else
@@ -10665,7 +10661,12 @@ post_default_ints:
call pcibios_init_iomem_bases
call pcibios_init_irqs
#endif //BX_PCIBIOS
-#endif
+ mov cx, #0xc000 ;; init vga bios
+ mov ax, #0xc780
+ call rom_scan
+#endif //BX_ROMBIOS32
+
+ call _print_bios_banner
;;
;; Floppy setup
@@ -10698,9 +10699,11 @@ post_default_ints:
call _init_boot_vectors
+#if !BX_ROMBIOS32
mov cx, #0xc800 ;; init option roms
mov ax, #0xe000
call rom_scan
+#endif
#if BX_ELTORITO_BOOT
call _interactive_bootkey
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 321563d..580aa17 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -1,4 +1,4 @@
-/
+
// $Id: rombios32.c,v 1.11 2007/08/03 13:56:13 vruppert Exp $
/
//
@@ -679,6 +679,7 @@ typedef struct PCIDevice {
int devfn;
} PCIDevice;
+static int pci_bios_nvga = 0;
static uint32_t pci_bios_io_addr;
static uint32_t pci_bios_mem_addr;
static uint32_t pci_bios_bigmem_addr;
@@ -736,7 +737,7 @@ static void pci_set_io_region_addr(PCIDevice *d,
int region_num, uint32_t addr)
old_addr = pci_config_readl(d, ofs);
pci_config_writel(d, ofs, addr);
-BX_INFO(region %d: 0x%08x\n, region_num, addr);
+// BX_INFO(region %d: 0x%08x\n, region_num, addr);
/* enable memory mappings */
cmd = pci_config_readw(d, PCI_COMMAND);
@@ -928,6 +929,7 @@ static void pci_bios_init_device(PCIDevice *d)
}
break;
case 0x0300: /* Display controller - VGA compatible controller */
+ pci_bios_nvga++;
if (vendor_id != 0x1234)
goto default_map;
/* VGA: map frame buffer to default Bochs VBE address */
@@ -953,18 +955,21 @@ static void pci_bios_init_device(PCIDevice *d)
default_map:
/* default memory mappings */
for(i = 0; i PCI_NUM_REGIONS; i++) {
+uint32_t orig, addr, val, size;
RE: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Thanks, Avi!
I will definitely double check it when I go back to work tomorrow.
Happy New Year! :)
Best Regards
Shan Haitao
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: 2008年12月31日 17:29
To: Shan, Haitao
Cc: Liu, Kechao; 'kvm@vger.kernel.org'
Subject: Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Shan, Haitao wrote:
Hi, Avi,
Option ROM already has its own BAR at 0x30h. I think the devices assignment
code now already handles this register.
Okay good.
Can I summary your proposals like the following: In guest BIOS, scan all the
pci devices (virtual) for existance of Option ROMs. Copy them to available
BIOS space in 0xC - 0xD. Execute the ROM code at copied location.
Yes.
I don't understand why this makes differences compared to scanning and
copying Option ROMs in QEMU,
If the ROM BAR is already handled (including registering the memory when
the BAR is programmed -- I don't see that in the code), then there is no
big advantage. It's closer to how real hardware works, but that's about it.
especially given that the VGA BIOS and etherboot ROM are also copied to BIOS
space in QEMU before they execute in rom_scan loop in guest BIOS.
The VGA BIOS is typically present on the motherboard itself, at least on
some configurations. You're right about etherboot.
I'll apply the patch. Can you take a look at the ROM BAR?
--
error compiling committee.c: too many arguments to function
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�筏�hФ�≤�}��财�z�j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ���)撷f
Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Shan, Haitao wrote: Hi, Avi, Option ROM already has its own BAR at 0x30h. I think the devices assignment code now already handles this register. Okay good. Can I summary your proposals like the following: In guest BIOS, scan all the pci devices (virtual) for existance of Option ROMs. Copy them to available BIOS space in 0xC - 0xD. Execute the ROM code at copied location. Yes. I don't understand why this makes differences compared to scanning and copying Option ROMs in QEMU, If the ROM BAR is already handled (including registering the memory when the BAR is programmed -- I don't see that in the code), then there is no big advantage. It's closer to how real hardware works, but that's about it. especially given that the VGA BIOS and etherboot ROM are also copied to BIOS space in QEMU before they execute in rom_scan loop in guest BIOS. The VGA BIOS is typically present on the motherboard itself, at least on some configurations. You're right about etherboot. I'll apply the patch. Can you take a look at the ROM BAR? -- 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][v2] kvm-userspace: Load PCI option ROMs
Shan, Haitao wrote: Well, it may make sense to provide the ROMs as virtual PCI BARs, and have the bios do the work. This way, if some driver relies on remapping the BAR (graphic cards?), it can still work. I do not quite understand this. Can you elaborate? Which part? I propose not to copy the card option rom to the bios. Instead, present the bios as a virtual PCI BAR. The loop that scans the ROMs can then be moved to the bios. The advantage is that if a driver needs something in the ROM (mode tables for graphics), they will be available. I don't know if any card actually requires this. Maybe all the information is in the driver. -- 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][v2] kvm-userspace: Load PCI option ROMs
Hi, Avi, Option ROM already has its own BAR at 0x30h. I think the devices assignment code now already handles this register. Can I summary your proposals like the following: In guest BIOS, scan all the pci devices (virtual) for existance of Option ROMs. Copy them to available BIOS space in 0xC - 0xD. Execute the ROM code at copied location. I don't understand why this makes differences compared to scanning and copying Option ROMs in QEMU, especially given that the VGA BIOS and etherboot ROM are also copied to BIOS space in QEMU before they execute in rom_scan loop in guest BIOS. Thanks! Best Regards Haitao Shan Avi Kivity wrote: Shan, Haitao wrote: Well, it may make sense to provide the ROMs as virtual PCI BARs, and have the bios do the work. This way, if some driver relies on remapping the BAR (graphic cards?), it can still work. I do not quite understand this. Can you elaborate? Which part? I propose not to copy the card option rom to the bios. Instead, present the bios as a virtual PCI BAR. The loop that scans the ROMs can then be moved to the bios. The advantage is that if a driver needs something in the ROM (mode tables for graphics), they will be available. I don't know if any card actually requires this. Maybe all the information is in the driver.-- 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][v2] kvm-userspace: Load PCI option ROMs
Liu, Kechao wrote: Hi Avi, Thanks for your comments. I've updated the patch according to them. Please review it. Thank you. Load assigned devices' PCI option ROMs to the RAM of guest OS. And pass the corresponding devfns to BIOS. Looks good. + +/* Write ROM data and devfn to phys_addr */ +cpu_physical_memory_write_rom(0xd + offset, rom, size); +cpu_physical_memory_write_rom(0xd + offset + size, devfn, 1); + How is the last bit performed on real hardware? Obviously the ROM can't have devfn embedded. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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][v2] kvm-userspace: Load PCI option ROMs
Hi Avi, -Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: 2008年12月29日 16:29 To: Liu, Kechao Cc: kvm@vger.kernel.org; Shan, Haitao Subject: Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs Liu, Kechao wrote: Hi Avi, Thanks for your comments. I've updated the patch according to them. Please review it. Thank you. Load assigned devices' PCI option ROMs to the RAM of guest OS. And pass the corresponding devfns to BIOS. Looks good. + +/* Write ROM data and devfn to phys_addr */ +cpu_physical_memory_write_rom(0xd + offset, rom, size); +cpu_physical_memory_write_rom(0xd + offset + size, devfn, 1); + How is the last bit performed on real hardware? Obviously the ROM can't have devfn embedded. On a real hardware, BIOS scans PCI devices, loads ROMs and it can get devices' devfns. Here, in an easier way, we load option ROMs in QEMU and thus need to store and pass the devfns. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. Best Regards, Liu, Kechao
Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Liu, Kechao wrote: How is the last bit performed on real hardware? Obviously the ROM can't have devfn embedded. On a real hardware, BIOS scans PCI devices, loads ROMs and it can get devices' devfns. Here, in an easier way, we load option ROMs in QEMU and thus need to store and pass the devfns. Well, it may make sense to provide the ROMs as virtual PCI BARs, and have the bios do the work. This way, if some driver relies on remapping the BAR (graphic cards?), it can still work. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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][v2] kvm-userspace: Load PCI option ROMs
Avi Kivity wrote: Liu, Kechao wrote: How is the last bit performed on real hardware? Obviously the ROM can't have devfn embedded. On a real hardware, BIOS scans PCI devices, loads ROMs and it can get devices' devfns. Here, in an easier way, we load option ROMs in QEMU and thus need to store and pass the devfns. Well, it may make sense to provide the ROMs as virtual PCI BARs, and have the bios do the work. This way, if some driver relies on remapping the BAR (graphic cards?), it can still work. I do not quite understand this. Can you elaborate? Best Regards Shan Haitao-- 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
