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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Gerd Hoffmann [mailto:kraxel@xxxxxxxxxx]
> Sent: Tuesday, February 02, 2016 4:56 PM
> 
>   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.
> 
> Advantage of option one is that we'll keep the option to do things in a
> different way in the future, without breaking the guest/qemu interface.
> 
> Disadvantage is that it'll cause hugepage mappings to be splitted.
> 

based on where you pick up the gfn to map or copy opregion. If you look
at physical, it's usually close to mmio region where several other reserved
e820 entries also exist. If we do same for virtual opregion, it shouldn't
impact hugepage.

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