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

[Kevin O'Connor]

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);
}

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

[Laszlo Ersek]

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);
> }

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

[Alex Williamson]

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