From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laszlo Ersek Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks Date: Tue, 2 Feb 2016 17:49:27 +0100 Message-ID: <56B0DE17.7090708@redhat.com> References: <1451994098-6972-1-git-send-email-kraxel@redhat.com> <1454009759.7183.7.camel@redhat.com> <1454051359.28516.28.camel@redhat.com> <1454090373.23148.11.camel@redhat.com> <1454330962.10168.34.camel@redhat.com> <1454403380.9300.49.camel@redhat.com> <20160202163123.GA3727@morn.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160202163123.GA3727@morn.lan> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Kevin O'Connor , Gerd Hoffmann Cc: "igvt-g@ml01.01.org" , "Tian, Kevin" , "xen-devel@lists.xensource.com" , Eduardo Habkost , Stefano Stabellini , "Michael S. Tsirkin" , seabios@seabios.org, "qemu-devel@nongnu.org" , Alex Williamson , Cao jin , "vfio-users@redhat.com" , Igor Mammedov List-Id: xen-devel@lists.xenproject.org Including Igor & MST Thanks Laszlo On 02/02/16 17:31, 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); > } >