[coreboot] Lenovo G505s AMD Hardware Virtualization

[awokd]

On Fri, December 15, 2017 10:00 am, Ivan Ivanov wrote:
> awokd, could you please answer some questions:
>
> 1) From where you got that 0x06001119 microcode patch?
> Is it a trusted source of a microcode? (hope its directly from AMD)
>
>
> 2) Is there any way to determine that 0x06001119 is really the latest
> microcode? Or there could be more recent versions available?

1) I got it by executing the following on a Debian Stretch install:
dd skip=5284 iflag=skip_bytes
if=/lib/firmware/amd-ucode/microcode_amd_fam15h.bin of=amd.bin
xxd -i amd.bin
Then copying and pasting.

Executing these steps against
coreboot/3rdparty/blobs/cpu/amd/family_15h/microcode_amd_fam15h.bin
provides identical results.

2) It's internally dated July 13, 2012. There's another ucode for a
different processor in the same microcode_amd_fam15h.bin file dated 2016,
so I'm assuming there is not a newer version available for this processor
or the maintainer would have updated it at the same time. There could
still be one somewhere, but I was having trouble tracking down any
information at all on these different patch levels.

It looks like the microcode_amd_fam15h.bin that ships with coreboot is
slightly out of date. The blob dated 2016 in the Debian distro is dated
2014 in here. I'll try to research why and submit an update if there's no
obvious reason not to.

>
> 2017-12-12 6:21 GMT+03:00 Taiidan at gmx.com <Taiidan at gmx.com>:

>> I am not sure how to do a commit, but I hope you are able to find out
>> as you will have helped a lot of people.

I did figure it out: https://review.coreboot.org/#/c/22843/

>> I am pleased with myself for noticing that the lack of microcode
>> updates was the issue - as the CPU is similar to a piledriver not a
>> bulldozer it requires microcode for IOMMU.

Thank you for pointing this out! Definitely helped.

>> I do not have the technical documents for that chipset and I do not
>> know how to change the PCI regs but I am sure the USB controllers
>> support FLR considering the nearly identical SR56xx chipsets usb
>> controllers do - I will look in to this further.

There is something strange going on with interrupt remapping on these USB
controllers too. Might be a Qubes regression, still investigating...

PS Pls. note email change.