qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Gerd Hoffmann <kraxel@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: Mon, 16 May 2016 17:03:07 -0600	[thread overview]
Message-ID: <20160516170307.51cf7ab2@t450s.home> (raw)
In-Reply-To: <1463127660.14138.42.camel@redhat.com>

On Fri, 13 May 2016 10:21:00 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:

> > #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 think following this approach I'd rename the fw_cfg file to
"etc/igd-bdsm-size", otherwise looks reasonable, I'll make the change.

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

Yeah, even beyond these fw_cfg options there's probably enough oddity
with IGD assignment to have it's own docs file.  I'll cook something up
for the next posting.  Thanks for the review and comments.

Alex

      reply	other threads:[~2016-05-16 23:03 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
2016-05-16 23:03   ` Alex Williamson [this message]

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=20160516170307.51cf7ab2@t450s.home \
    --to=alex.williamson@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=kraxel@redhat.com \
    --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).