[coreboot] Question about Intel HD graphics and FLR

[Zoran Stojsavljevic]

> So long as you don't have to kill anyone to get the info, I genuinely
appreciate the help.

Question: did you ever kill... Pulling your leg! :-)))
_______

Back on the topic/thread:
[1] What kind of VM?
[2] Does your VM use PCIe Pass-through method (I guess, you must have also
in BIOS IOMMU/VT-d ON, this is A MUST)?

*Explanation: PCI Pass-through is a method of giving a VM direct access to
a PCI device.*

Thank you,
Zoran

On Thu, Mar 30, 2017 at 7:18 PM, Joshua Pincus <joshua.pincus at gmail.com>
wrote:

> Hi Zoran,
>
> So long as you don't have to kill anyone to get the info, I genuinely
> appreciate the help.
> JP
>
> On Thu, Mar 30, 2017 at 9:54 AM, Zoran Stojsavljevic <
> zoran.stojsavljevic at gmail.com> wrote:
>
>> OK, Joshua!
>>
>> I do not promise anything. But I, out of (your) desperation, will try to
>> find answers for you. If (no promise)...
>>
>> If I (eventually) return back, I have only one condition for you: NEVER
>> ask how I found (any future) answer for/to you!
>>
>> Thank you,
>> Zoran
>>
>> On Thu, Mar 30, 2017 at 5:48 PM, Joshua Pincus <joshua.pincus at gmail.com>
>> wrote:
>>
>>> Hi Zoran,
>>>
>>> Thanks for your reply.
>>>
>>> My situation is this: When the VM guest comes up the first time from a
>>> system-level reset (aka power on), the Broadwell HD graphics device runs
>>> fine.  I see basic VGA both before and during the boot of Windows.  Once
>>> Windows boots, the HD graphics device is configured by Intel's driver and I
>>> see hi-rez output.  On a reboot of Windows within the VM, an FLR is
>>> issued.  When the guest comes back up, no VGA.  Windows does boot but
>>> provides no VGA output.  If Windows needs to drop into VGA mode so that a
>>> user can access the real-mode functionality of the recovery console, still
>>> no VGA.
>>>
>>> It's only on Broadwell-based boards that we have this problem.  If we
>>> issue FLRs during the reset of the PCI bus for older Intel boards, no
>>> problem.  We get VGA.  Something involved with the FLR is messing up the
>>> state of the hardware instead of actually returning the hardware to a
>>> virgin state, akin to what you would get from a full system reset.
>>>
>>> I was wondering if anyone had seen this kind of behavior.  We've tried
>>> everything.  We've manipulated all of the obvious HD graphics MMIO
>>> registers involved with restoring VGA but nothing seems to work.
>>>
>>> Thanks,
>>> JP
>>>
>>> On Thu, Mar 30, 2017 at 4:29 AM, Zoran Stojsavljevic <
>>> zoran.stojsavljevic at gmail.com> wrote:
>>>
>>>> Hello Joshua,
>>>>
>>>> I'll ask similar question, considering UEFI (BIOS). I have no idea if
>>>> you can issue somehow easy FLR (PCI Function Level Reset), but if you
>>>> can, does this use case repeat itself?
>>>>
>>>> I found, related to BIOS, this pointer (http://www.tomshardware.co.uk
>>>> /forum/278002-30-solved-what-capability-option-bios), since I do NOT
>>>> recall this option in any (legacy and UEFI) of the BIOSes I used (and I
>>>> used lot (>100) of them). Probably, did not pay too much attention, since I
>>>> do not recall this option to be tested/used?!
>>>>
>>>> Zoran
>>>>
>>>> On Wed, Mar 29, 2017 at 10:49 PM, Joshua Pincus <
>>>> joshua.pincus at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> After performing just an FLR (PCI function level reset) of a Gen8
>>>>> Intel HD graphics device, there's no VGA output from the device, no matter
>>>>> what I try to do.  I've had coreboot reset the graphics control register,
>>>>> VGA control, VGA display disable bit, etc.
>>>>>
>>>>> Has anyone seen anything like this?  The only way I can get VGA
>>>>> restored is by performing a system-level reset.  But I just want to do an
>>>>> FLR.  Any ideas?
>>>>>
>>>>> Thanks,
>>>>> JP
>>>>>
>>>>> --
>>>>> coreboot mailing list: coreboot at coreboot.org
>>>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170330/474a9dc0/attachment.html>