On 12.05.2017 14:26, Joshua Pincus wrote: > Hi Zoran, > > Please see my inline response below. > > On May 12, 2017 8:13 AM, "Zoran Stojsavljevic" < > [email protected]> wrote: >> >> Hello Joshua, >> >> You managed to confuse me, on the very high level.Why, you'll ask? >> >> [1] I have no idea if you ever were able to solve the following issue: > https://www.mail-archive.com/[email protected]/msg48827.html And did > you, after all (and what was the solution, if not secret)? > > [JP] We did solve it. I am sorry I did not post the solution earlier. The > problem was that the video BIOS was not executing the initialization > routines on a guest VM reboot. Consequently, the guest would reboot > without any of the HD graphics registers being re-initialized as they would > on a cold boot. The solution was to extract the video BIOS from the boot > ROM and re-execute the image after the FLR. > >> [2] It seems that you in your original email imply that Linux GFX driver > i915 is used in WIN10 too? Or Linux is actually host, and WIN10 is a VM on > the top of some (which one?) HYP type 2? Or maybe, HYP is type 1? Really, > what is the true OS configuration stack in your case??? > > [JP] Sorry. Here is the stack: Win10 guest running Intel HD graphics Gen8 > driver for video and audio on top of type 1 Hypervisor. > > I am looking at the i915 drm driver for insipiration as well as the VBT > data. So far, I am not seeing anything in the VBT that describes the audio > capabilities of the DisplayPort connected monitor. This is all very > puzzling.
VBT was just a random guess, I wouldn't know why Intel would put some- thing related there. But it's Intel, you never know. Now that I've looked at some VBT binary description files, I don't see anything ei- ther. So that might be a dead end. Nico > >> >> Any answer would be greatly appreciated. > > JP > >> >> >> Thanks, >> >> ZS >> >> >> On Thu, May 11, 2017 at 10:43 PM, Joshua Pincus <[email protected]> > wrote: >>> >>> Hey Folks, >>> >>> >>> I've been smacking my head against the wall for 2 weeks. I can't smack > it anymore. There's not much brain left at this point. Here's my issue: >>> >>> >>> I have a Broadwell system with HD Video/Audio support. When Windows 10 > runs native (without a Hypervisor), Windows correctly finds the DisplayPort > adapter and correctly probes whatever it is that it needs to probe to > determine that the adapter in question supports both audio and video > output. When Windows 10 is executed as a guest on top of a Hypervisor, it > correctly finds both the video device @ 0/2/0 and the audio device @ 0/3/0 > but it is unable to detect that the DisplayPort supports audio. >>> >>> >>> >>> I can confirm that both the Intel drivers for video and audio correctly > attach and seem to be running perfectly inside the guest VM. All of the > PCI BARs associated with both devices are correctly being mapped to the > Windows 10 guest. It is my guess that Windows is looking at something > other than the EDID extracted from the attached monitor or the MMIO BAR for > the PCI audio or video devices to determine that audio is supported by the > attached hardware. Indeed, if I probe the EDID information from the guest, > I see that the attached monitor supports audio. >>> >>> >>> >>> My question is this: Is there something else other than the PCI BARs > associated with the onboard HD graphics and HD audio devices that are > required for a Windows or a Linux guest to detect the physical presence of > audio hardware associated with an attached monitor via HDMI or DP? Is > there an MCH or PCH register? My guess is that I am not mapping ALL of the > BARs or IO ports into the guest to allow Windows to probe the hardware > properly. Something is missing. I can’t figure out what that something is. >>> >>> >>> >>> Any help would be greatly appreciated. >>> >>> >>> >>> Thanks, >>> >>> JP >>> >>> >>> -- >>> coreboot mailing list: [email protected] >>> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> > > > -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
