qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/7] ramfb: simple boot framebuffer, no legac


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH v2 0/7] ramfb: simple boot framebuffer, no legacy vga
Date: Tue, 5 Jun 2018 15:16:49 +0200
User-agent: NeoMutt/20180512

On Tue, Jun 05, 2018 at 02:07:27PM +0200, Laszlo Ersek wrote:
> On 06/05/18 13:06, Gerd Hoffmann wrote:
> >   Hi,
> > 
> >>>> I could imagine an OvmfPkg-specific PCI capability that said, "all PCI
> >>>> drivers in OvmfPkg that could otherwise drive this device, ignore it --
> >>>> another (platform) driver in OvmfPkg will pick it up instead".
> >>>
> >>> pci capability for ramfb could be useful (also for linux).  I'll keep it
> >>> in mind for now.
> >>
> >> Please do. :)
> > 
> > Hmm, well.  Virtio 1.0 uses vendor specific capabilities already to
> > define the regions, and they don't have a fixed field saying "this is
> > for virtio".  So adding another vendor specific capability for something
> > else on the same device is a bit problematic ...
> 
> Can we invent a non-PCI method, e.g. fw_cfg, that tells QemuVideoDxe and
> Virtio10Dxe not to bind some PCI S/B/D/Fs? Something like:

Well, from edk2 point of view Virtio10Dxe is the only problematic case
because there is a is a native driver.  For cirrus/stdvga a version with
ramfb is rather pointless.  A qxl-ramfb device might make sense, but
QemuVideoDxe would ignore such a device like it ignores qxl today as it
can only handle the vga mode of qxl-vga devices.

Also I'd prefer to provide informations (device foo has ramfb at <addr>)
not instructions (please ignore device foo).

Maybe we should for now just scratch the idea of an virtio-ramfb device.
Linux doesn't need it, and windows wouldn't use the virtio part of it so
a standalone ramfb device would work equally well.

cheers,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]