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

[Igor Mammedov]

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  
> >   
>