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
