On 2015-03-27 12:58, Laszlo Ersek wrote:
> 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)
I was rather hoping, as a first pass, to simply statically encode the
payload into a binary string and have the _ROM method simply return
that. Would that not work?
> 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.
I am 99% certain it is not being patched at runtime, because what
nouveau pulls out and makes available as
/sys/kernel/debug/dri/<id>/vbios.rom
is exactly identical to the firmware blob I pulled out of the
system firmware.
Having said that, the system firmware does include no fewer than 3
Nvidia BIOS-es with different version numbers, so I suspect what is
happening there is the firmware figuring out which of the three it
should use for the card that is present.
> 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.
Which does kind of present another possibility. Nvidia cards, according
to what nouveau driver does, offer 3 methods of getting the VBIOS out:
1) PRAMIN (read it from the particular place in VRAM)
It has been suggested that if I use a driver to initialize the RAM,
then use nvafakebios to load the BIOS blob into the PRAMIN, and then
start the VM. But it doesn't appear to have worked - seems something
seems to clobber the BIOS payload along the way.
2) PROM (read it from the supported PROM)
Short of writing a qemu emulation for one, I'm not sure there's a
way to make use of this.
3) ACPI
> 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.
See above - it isn't all that messed up, the output is completely
clean.
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
