> Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 > Method (_DIS, 0, NotSerialized) // _DIS: Disable Device
Patch dsdt windows windows#
I ignored the clover way as that never worked for me and dumped the DSDT in windows then used the intel way to load it up. I have now managed to get it working in windows tho. > Name (_HID, "VMBus") // _HID: Hardware ID No can do on the OSX im afraid as I have a NVIDIA 1080. > Name (_DDN, "VMBUS") // _DDN: DOS Device Name > Here is a VMBus ACPI device description from Hyper-V in Windows Server 2019: The dumped ACPI tables that would be great). Hopefully if someone else has access to HyperV machine and willing to reply here with > I can no longer get to the HyperV computer I had (in the office so > Could you dump ACPI tables and check how hyperv describes vmbus in acpi? > perhaps it's what hyperv host puts into _CRS.
Patch dsdt windows driver#
> well, it seems that at least linux guest driver uses one IRQ, > Make IRQ numbers user-configurable via corresponding properties use 7 They seem to never be used but they still > Experimentally Windows guests were found to require this entry to > entry to DSDT in case VMBus has been enabled. > Guest OS uses ACPI to discover VMBus presence. Add a corresponding > But I'm willing to do any changes so we can keep going forward with this. To get where I was going to, but it was part of the original patchset).
Patch dsdt windows Patch#
> I dont know what were the original intentions of the original patchĪuthors (at this point I simply rebased it, and to be honest I did not need this patch > Please let me know if there is anything else. You mentioned you want under a different location than the ISA bug where Change from 2 IRQs to single one (and use 5 as the default) > So just to summarize the changes i need to do: Really necessary of it and throw away the rest. Instead of blind copying dubious AML, we should try to figure out what's Whether they are necessary or the guests can do without (Linux Right, but, as you can see, they are pretty dumb, so the question is > in the patch (unless I'm missing something). > Seems like it has all those _STA/_DIS/_PS0 just like the way it's currently > Seems like it needs to reside in the _CRS like you said. Guest was noticed to use the irqs in ACPI. HyperV using irq 5 doesn't mean QEMU has to too. > Igor it seems like the IRQ being used is 5 and not 7 & 13 like in the Roman, do you remember when is this information being used? Do we need aįull emulation setup (aka your hv-scsi / hv-net) patches in order to see I dont have any real HyperV Windows to play with. > diff -git a/hw/hyperv/vmbus.c b/hw/hyperv/vmbus.Re: i386: Hyper-V VMBus ACPI DSDT entryĭo you guys know perhaps which module is reading the ACPI configurationįor VMBus? vmbus.sys / vmbkmcl.sys / winhv.sys? is it the kernel or HAL? > include/hw/hyperv/vmbus-bridge.h | 3 +++ So in case if conflict one would get a error. It would be better to initialize and consume irqs it climes to use Perhaps it's what hyperv host puts into _CRS.Ĭould you dump ACPI tables and check how hyperv describes vmbus in acpi?Īlso what if vmbus irq collides with an irq that is already taken, Well, it seems that at least linux guest driver uses one IRQ, > Guest OS uses ACPI to discover VMBus presence.
0 kommentar(er)
