qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	Kevin O'Connor <kevin@koconnor.net>,
	seabios@seabios.org
Subject: Re: [Qemu-devel] RFC: Proposed vfio IGD assignment fw_cfg ABI
Date: Fri, 13 May 2016 10:21:00 +0200	[thread overview]
Message-ID: <1463127660.14138.42.camel@redhat.com> (raw)
In-Reply-To: <20160512180425.2ad55ded@t450s.home>

> #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
though.

cheers,
  Gerd

  reply	other threads:[~2016-05-13  8:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-13  0:04 [Qemu-devel] RFC: Proposed vfio IGD assignment fw_cfg ABI Alex Williamson
2016-05-13  8:21 ` Gerd Hoffmann [this message]
2016-05-16 23:03   ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1463127660.14138.42.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).