[Top][All Lists]

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

Re: [Qemu-devel] RFC: Proposed vfio IGD assignment fw_cfg ABI

From: Gerd Hoffmann
Subject: Re: [Qemu-devel] RFC: Proposed vfio IGD assignment fw_cfg ABI
Date: Fri, 13 May 2016 10:21:00 +0200

> #1: "etc/igd-opregion"
> the IGD OpRegion is an area of memory which contains among other
> things, the Video BIOS Table which is integral in allowing an assigned
> IGD to configure and make use of the physical display outputs of the
> system.  "etc/igd-opregion" is an opaque fw_cfg file which the BIOS
> will use to allocate an appropriately sized reserved memory region,
> copy the contents of the fw_cfg file into the allocated memory region,
> and write the base address of the allocated memory region to the dword
> registers at 0xFC in PCI config space on the IGD device itself.  The
> BIOS will look for this fw_cfg file any time a PCI class VGA device is
> found with Intel vendor ID.  Multiple IGD devices per VM, such as might
> potentially be possible with Intel vGPU, is not within the scope of
> this proposal.  The expected size of this fw_cfg file is on the order
> of a few pages, 8KB is typical.

Looks good to me.

> #2: "etc/igd-bdsm"

> possibility of multiple BDSM per VM.  The expected size of this fw_cfg
> file is from 1MB to multiple hundreds of MB with user specified stolen
> video memory.

Having a big fw_cfg file without using the content looks a bit odd to
me.  I'd suggest to create a fw_cfg file with the size in it instead.
Usual way to do this is to stick a 64bit value in little endian byte
order into fw_cfg, then use romfile_loadint() in seabios to read it.

> I'd appreciate any comments on these entries and I'd be happy to
> describe them further.  Perhaps we should create a docs/api/
> directory with these sorts of descriptions where we define how a
> given API is intended to work.

There is docs/specs/ already where this would fit, and it even has a
fw_cfg.txt file.  It might make sense to have a separate igd-assign.txt


reply via email to

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