Re: [RFC 00/10] R300 QEMU device V2

[BALATON Zoltan]

On Wed, 27 Nov 2019, Daniel P. Berrangé wrote:
> On Wed, Nov 27, 2019 at 04:00:01PM +0100, Philippe Mathieu-Daudé wrote:
> > Hi Daniel, Aaron.
> >
> > On 11/26/19 3:19 PM, Daniel P. Berrangé wrote:
> > > On Tue, Nov 26, 2019 at 06:14:27PM +0530, address@hidden wrote:
> > > > From: Aaron Dominick <address@hidden>
> > > >
> > > > I have removed the botched patches and have got the code working upto the GART 
> > > > initialization.
> > > > I am not sure how to implement the GART. I am guessing it should be an IOMMU 
> > > > device but I think that is a bit much for an emulated card.
> > > > The earlier problem of display probing seems to be resolved by using an R300 
> > > > bios I got from TechPowerUP's GPU database:
> > > >
> > > >         https://www.techpowerup.com/vgabios/14509/14509
> > > > I am NOT sure if we can distribute it in the QEMU source tree. If it
> > > > does cause problems I can send a patch to remove it.
> > >
> > > That site seems to be a repository of BIOS uploaded by arbitrary users,
> > > with no information on what license terms might apply to the uploads.
> > >
> > > We have to therefore assume the worst and treat the BIOS images on that
> > > site as proprietary and not re-distributable, despite the fact that the
> > > site itself is acting as a 3rd party distributor.
> >
> > We can not redistribute this BIOS.
> >
> > > IOW, we can't have this in QEMU git I'm afraid, unless someone can find
> > > a trustworthy vendor source for the original image with accompanying
> > > license information.
> >
> > Daniel, I think there is no problem if Aaron contributes a model of the R300
> > device to QEMU, right? This doesn't involve redistributing any BIOS.
>
> Having just the device impl doesn't cause any legal problems.
>
> It does become a slight usability issue, as any users need to go and find
> the suitable BIOS in order to use the device. No downstream OS vendors are
> going to be able to distribute this BIOS either

We may be able to avoid this problem if we identify what the driver needs 
from the BIOS and implement that in our vgabios. Gerd has already added 
some tables that some drivers need in the latest vgabios version that's 
currently in git master (but those were for Rage128 and RV100 that ati-vga 
currently implements). Aaron, did you try with latest git master and does 
that still need a BIOS from a real card or if so do you happen to know 
what the driver needs from the BIOS? (It may be some tables/structure or 
BIOS calls that the QEMU vgabios-ati does not implement yet.) If that's 
not too difficult to add it may be implemented in QEMU's vgabios to avoid 
needing proprietary blobs. It could also be EDID access that may use 
different registers on R300 but I think that may be simple to fix if more 
details are known.

> I don't know if we have hit this problem before & if we have any
> general policies about it ?

I don't know but this may be similar to boards needing firmware ROMs or 
the firmware blobs needed by some Linux kernel drivers. How are those
handled? Distros usually put them in a non-free repo I think.

Regrads,
BALATON Zoltan