qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks
Date: Tue, 2 Feb 2016 17:49:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]