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 0xC0000. By convention the primary VGA adapter ROM
always resides at 0xC0000.
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
