From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQdrW-0006ee-Ck for qemu-devel@nongnu.org; Tue, 02 Feb 2016 11:31:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQdrS-0001N5-SO for qemu-devel@nongnu.org; Tue, 02 Feb 2016 11:31:30 -0500 Received: from mail-qk0-x244.google.com ([2607:f8b0:400d:c09::244]:34051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQdrS-0001N1-LN for qemu-devel@nongnu.org; Tue, 02 Feb 2016 11:31:26 -0500 Received: by mail-qk0-x244.google.com with SMTP id u128so5390807qkh.1 for ; Tue, 02 Feb 2016 08:31:26 -0800 (PST) Date: Tue, 2 Feb 2016 11:31:24 -0500 From: Kevin O'Connor Message-ID: <20160202163123.GA3727@morn.lan> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1454403380.9300.49.camel@redhat.com> Subject: Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: "igvt-g@ml01.01.org" , "Tian, Kevin" , "xen-devel@lists.xensource.com" , Eduardo Habkost , Stefano Stabellini , seabios@seabios.org, "qemu-devel@nongnu.org" , Alex Williamson , Cao jin , "vfio-users@redhat.com" , Laszlo Ersek 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); }