Re: [PATCH v4 5/6] i386: Hyper-V VMBus ACPI DSDT entry

[Roman Kagan]

On Fri, May 15, 2020 at 11:56:36AM +0300, Jon Doron wrote:
> On 13/05/2020, Igor Mammedov wrote:
> 
> Do you guys know perhaps which module is reading the ACPI configuration for
> VMBus? vmbus.sys / vmbkmcl.sys / winhv.sys? is it the kernel or HAL?

No idea...

> I dont have any real HyperV Windows to play with...
> 
> Roman, do you remember when is this information being used? Do we need a
> full emulation setup (aka your hv-scsi / hv-net) patches in order to see
> Windows working this ACPI entry?

I think the series you've posted should be enough to see VMBus in the
DeviceManager.  hv-scsi and hv-net should not further depend on ACPI.
hv-pci does: it (at least in its Linux driver implementation) wants the
VMBus entry or any of its ancestors to define range(s) where mmio
windows can be placed.  This may be worth considering when deciding
where to stick the VMBus entry to.

Thanks,
Roman.

> Thanks,
> -- Jon.
> 
> > On Mon, 11 May 2020 23:11:23 +0300
> > Roman Kagan <address@hidden> wrote:
> > 
> > > On Thu, May 07, 2020 at 06:14:25AM +0300, Jon Doron wrote:
> > > > Igor it seems like the IRQ being used is 5 and not 7 & 13 like in the
> > > > current patch.
> > > 
> > > HyperV using irq 5 doesn't mean QEMU has to too.  Especially so as no
> > > guest was noticed to use the irqs in ACPI.  I'd rather try and test if
> > > the guest requires any those at all.
> > > 
> > > > Seems like it needs to reside in the _CRS like you said.
> > > 
> > > They already are there.
> > > 
> > > > Seems like it has all those _STA/_DIS/_PS0 just like the way it's 
> > > > currently
> > > > in the patch (unless I'm missing something).
> > > 
> > > Right, but, as you can see, they are pretty dumb, so the question is
> > > whether they are necessary or the guests can do without (Linux
> > > apparently can).
> > 
> > Agreed with all of above,
> > Instead of blind copying dubious AML, we should try to figure out what's
> > really necessary of it and throw away the rest.
> > 
> > > 
> > > Thanks,
> > > Roman.
> > > 
> > > > Notice _PS3 is not a Method.
> > > >
> > > > So just to summarize the changes i need to do:
> > > > 1. Change from 2 IRQs to single one (and use 5 as the default)
> > > > 2. IRQs needs to be under _CRS.
> > > > 3. You mentioned you want under a different location than the ISA bug 
> > > > where
> > > > would you want it to be?
> > > >
> > > > Please let me know if there is anything else.
> > > >
> > > > Thanks,
> > > > -- Jon.
> > > >
> > > > On 06/05/2020, Maciej S. Szmigiero wrote:
> > > > > On 05.05.2020 17:38, Jon Doron wrote:
> > > > > > On 05/05/2020, Igor Mammedov wrote:
> > > > > >
> > > > > > I dont know what were the original intentions of the original patch 
> > > > > > authors (at this point I simply rebased it, and to be honest I did 
> > > > > > not need this patch to get where I was going to, but it was part of 
> > > > > > the original patchset).
> > > > > >
> > > > > > But I'm willing to do any changes so we can keep going forward with 
> > > > > > this.
> > > > > >
> > > > > > > On Fri, 24 Apr 2020 15:34:43 +0300
> > > > > > > Jon Doron <address@hidden> wrote:
> > > > > > >
> > > > > > > > Guest OS uses ACPI to discover VMBus presence.  Add a 
> > > > > > > > corresponding
> > > > > > > > entry to DSDT in case VMBus has been enabled.
> > > > > > > >
> > > > > > > > Experimentally Windows guests were found to require this entry 
> > > > > > > > to
> > > > > > > > include two IRQ resources. They seem to never be used but they 
> > > > > > > > still
> > > > > > > > have to be there.
> > > > > > > >
> > > > > > > > Make IRQ numbers user-configurable via corresponding 
> > > > > > > > properties; use 7
> > > > > > > > and 13 by default.
> > > > > > > well, it seems that at least linux guest driver uses one IRQ,
> > > > > > > abeit not from ACPI descriptior
> > > > > > >
> > > > > > > perhaps it's what hyperv host puts into _CRS.
> > > > > > > Could you dump ACPI tables and check how hyperv describes vmbus 
> > > > > > > in acpi?
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > I can no longer get to the HyperV computer I had (in the office so 
> > > > > > hopefully if someone else has access to HyperV machine and willing 
> > > > > > to reply here with the dumped ACPI tables that would be great).
> > > > > >
> > > > >
> > > > > Here is a VMBus ACPI device description from Hyper-V in Windows 
> > > > > Server 2019:
> > > > >
> > > > > Device (\_SB.VMOD.VMBS)
> > > > > {
> > > > >    Name (STA, 0x0F)
> > > > >    Name (_ADR, Zero)  // _ADR: Address
> > > > >    Name (_DDN, "VMBUS")  // _DDN: DOS Device Name
> > > > >    Name (_HID, "VMBus")  // _HID: Hardware ID
> > > > >    Name (_UID, Zero)  // _UID: Unique ID
> > > > >    Method (_DIS, 0, NotSerialized)  // _DIS: Disable Device
> > > > >    {
> > > > >       STA &= 0x0D
> > > > >    }
> > > > >
> > > > >    Method (_PS0, 0, NotSerialized)  // _PS0: Power State 0
> > > > >    {
> > > > >       STA |= 0x0F
> > > > >    }
> > > > >
> > > > >    Method (_STA, 0, NotSerialized)  // _STA: Status
> > > > >    {
> > > > >       Return (STA) /* \_SB_.VMOD.VMBS.STA_ */
> > > > >    }
> > > > >
> > > > >    Name (_PS3, Zero)  // _PS3: Power State 3
> > > > >    Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
> > > > >    {
> > > > >       IRQ (Edge, ActiveHigh, Exclusive, )
> > > > >           {5}
> > > > >    })
> > > > > }
> > > > >
> > > > > It seems to use just IRQ 5.
> > > > >
> > > > > Maciej
> > > >
> > > 
> >