On 03/27/15 13:27, Gordan Bobic wrote:
> On 2015-03-27 09:39, Laszlo Ersek wrote:
>>>
>>> Return (VROM)
>>> }
>>> }
>>> }
>>
>> The end result is that the caller should call _ROM in a loop, updating
>> the start offset, and stop when the returned buffer size is smaller
>> (potentially: zero) than the requested read size. This _ROM loop will be
>> served from the memory range starting at (0x9CF9C018 + 4), for the
>> number of bytes that can be read from the UINT32 at 0x9CF9C018.
>>
>> If a copy of the actual ROM in question is available, then one might be
>> able reimplement the _ROM method: define a Buffer of bytes, listing the
>> actual bytes comprising the ROM image, and then serve the _ROM
>> invocations from *that*, instead of the VBOR operation region's VBSx
>> fields. And the RVBS references can be replaced with a known constant.
>
> Right. So what would be the correct way to embed a 103936 byte BIOS
> payload inside the _ROM method?
Please consult the ACPI spec. You should create a named Buffer object
with open-coded byte contents (*), then rebase the existing _ROM logic
on top of that object. Build the new SSDT with iasl, then pass it to
qemu with the -acpitable switch, as Gerd recommended. QEMU should then
expose that custom table too to OVMF, and OVMF should install it for the
guest OS.
((*) As an example, refer to
Name (VROM, Buffer (Local1)
{
0x00
})
in the iasl output. See also "19.5.10 Buffer (Declare Buffer Object)" in
the ACPI spec.)
I'm not suggesting this is easy -- to the contrary. In particular
because the SSDT that you decompiled has a bunch of other code in it,
with many OperationRegions and Externals.
In particular, there's a whole bunch of open-coded address constants in
the SSDT. One of those is
OperationRegion (VBOR, SystemMemory, 0x9CF9C018, 0x00019604)
itself, which you would replace with the explicit Buffer object.
However, there are others, for example:
OperationRegion (SGOP, SystemMemory, 0x9CFBBE98, 0x00000054)
The hardcoded address constant in the AML code very strongly suggests
that this AML payload was entirely composed, or partially patched, by
the laptop vendor's firmware *dynamically* during boot, dependent on
system RAM size, video card characteristics, PCI window characteristics,
whatever. To replay that in the guest, you'd probably have to
reimplement most of that logic in OVMF and/or qemu. '-acpitable' is good
only if you have a static AML blob.
So, I think your card is simply unusable for passthrough. It is strongly
tied to your proprietary system firmware, instead of carrying its own,
well-isolated option ROM.
With a separate add-on card, the vendor simply can't put the option ROM
anywhere else than on the card itself, but with an integrated card, they
can apparently pull sh*t like this.
Laszlo
>
>>>> Is there a way to modify the OVMF firmware to make it present
>>>> the BIOS payload via the _ROM method?
>>>
>>> acpi tables are provides by qemu, edk2/seabios only fetch them and store
>>> them in guest ram. So for starters have a look at the -apcitable switch
>>> qemu has.
>>
>> Agreed.
>>
>> (Although, the guest driver might want to call many more ACPI methods
>> than just _ROM...)
>
> I'm rather hoping it won't as it should only be needing the VBIOS,
> but I could be over-optimistic about that.
>
> Gordan
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
