Re: [Xen-devel] [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Alex Williamson <alex.williamson@xxxxxxxxxx>]

On Tue, 2016-02-02 at 11:31 -0500, Kevin O'Connor wrote:
> On Tue, Feb 02, 2016 at 09:56:20AM +0100, Gerd Hoffmann wrote:
> > Â Hi,
> >Â
> > > > I'd have qemu copy the data on 0xfc write then, so things continue to
> > > > work without updating seabios.ÂÂSo, the firmware has to allocate space,
> > > > reserve it etc.,ÂÂand programming the 0xfc register.ÂÂQemu has to make
> > > > sure the opregion appears at the address written by the firmware, by
> > > > whatever method it prefers.
> > >Â
> > > Yup. It's Qemu's responsibility to expose opregion content.Â
> > >Â
> > > btw, prefer to do copying here. It's pointless to allow write from guest
> > > side. One write example is SWSCI mailbox, thru which gfx driver can
> > > trigger some SCI event to communicate with BIOS (specifically ACPI
> > > methods here), mostly for some monitor operations. However it'sÂ
> > > not a right thing for guest to trigger host SCI and thus kick hostÂ
> > > ACPI methods.
> >Â
> > Thanks.
> >Â
> > So, question again how we do that best.ÂÂOption one being the mmap way,
> > i.e. basically what the patches posted by alex are doing.ÂÂOption two
> > being the fw_cfg way, i.e. place a opregion copy in fw_cfg and have
> > seabios not only set 0xfc, but also store the opregion there by copying
> > from fw_cfg.
>Â
> What about option 2a - SeaBIOS copies from fw_cfg to memory and then
> programs 0xfc.ÂÂQEMU can detect the write to 0xfc and choose to map
> that ram (thus completely ignoring the contents that were just copied
> in) or it can choose not to map that ram (thus guest uses the contents
> just copied in).
>Â
> The advantage of this approach is that it is a bit simpler in the
> firmware (no size probing is needed as the size comes from fw_cfg) and
> it allows for future flexibility as the choice of mapping can be
> deferred.
>Â
> Totally untested seabios code below as example.
>Â
> As an aside, if this type of "program a pci register" with a memory
> address becomes common, we could enhance the acpi-style "linker
> script" system to automate this..
>Â
> -Kevin
>Â
>Â
> static void intel_igd_opregion_setup(struct pci_device *dev, void *arg)
> {
> ÂÂÂÂstruct romfile_s *file = romfile_find("etc/igd-opregion");
> ÂÂÂÂif (!file)
> ÂÂÂÂÂÂÂÂreturn;
> ÂÂÂÂvoid *data = memalign_high(PAGE_SIZE, file->size);
> ÂÂÂÂif (!data) {
> ÂÂÂÂÂÂÂÂwarn_noalloc();
> ÂÂÂÂÂÂÂÂreturn;
> ÂÂÂÂ}
> ÂÂÂÂint ret = file->copy(file, data, file->size);
> ÂÂÂÂif (ret < 0) {
> ÂÂÂÂÂÂÂÂfree(data);
> ÂÂÂÂÂÂÂÂreturn;
> ÂÂÂÂ}
> ÂÂÂÂpci_config_writel(dev->bdf, 0xFC, (u32)data);
> }

I posted a v2 of the last QEMU patch and the SeaBIOS patch that takes
this approach with an option in QEMU for the direct map.ÂÂThanks,

Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel