Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs

[Avi Kivity <avi@redhat.com>]

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