Re: Add support for ACPI Module Device ACPI0004?

[Sepherosa Ziehau]

On Tue, May 2, 2017 at 11:28 AM, Sepherosa Ziehau  wrote:
> On Tue, May 2, 2017 at 12:25 AM, John Baldwin  wrote:
>> On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote:
>>> On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin  wrote:
>>> > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
>>> >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin  wrote:
>>> >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
>>> >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin  
>>> >> >> wrote:
>>> >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>>> >> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
>>> >> >> >> > Sent: Thursday, April 20, 2017 02:34
>>> >> >> >> > > Can we add the support of "ACPI0004" with the below one-line 
>>> >> >> >> > > change?
>>> >> >> >> > >
>>> >> >> >> > >  acpi_sysres_probe(device_t dev)
>>> >> >> >> > >  {
>>> >> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL 
>>> >> >> >> > > };
>>> >> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
>>> >> >> >> > > "ACPI0004", NULL };
>>> >> >> >> > >
>>> >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
>>> >> >> >> > though we
>>> >> >> >> > in turn allow any child of acpi0 to suballocate those ranges 
>>> >> >> >> > (since historically
>>> >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by 
>>> >> >> >> > things like the
>>> >> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of 
>>> >> >> >> > ACPI0004 in the ACPI
>>> >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
>>> >> >> >> > particular, it
>>> >> >> >> > seems that 004 should only allow direct children to suballocate? 
>>> >> >> >> >  This
>>> >> >> >> > change might work, but it will allow more devices to allocate 
>>> >> >> >> > the ranges in
>>> >> >> >> >  _CRS than otherwise.
>>> >> >> >> >
>>> >> >> >> > Do you have an acpidump from a guest system that contains an 
>>> >> >> >> > ACPI0004
>>> >> >> >> > node that you can share?
>>> >> >> >> >
>>> >> >> >> > John Baldwin
>>> >> >> >>
>>> >> >> >> Hi John,
>>> >> >> >> Thanks for the help!
>>> >> >> >>
>>> >> >> >> Please see the attached file, which is got by
>>> >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>>> >> >> >>
>>> >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>>> >> >> >> "VMBus" (VMBS).
>>> >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we 
>>> >> >> >> can't
>>> >> >> >> see the length of the MMIO range in the dumped asl code, it does 
>>> >> >> >> have
>>> >> >> >> a 512MB MMIO range [0xFE000, 0xF].
>>> >> >> >>
>>> >> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
>>> >> >> >> With the above one-line change, I can first find the child device
>>> >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>>> >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>>> >> >> >>
>>> >> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
>>> >> >> >> we can add a new small driver for ACPI0004, just like we added 
>>> >> >> >> VMBus
>>> >> >> >> driver as a child device of acpi0?
>>> >> >> >
>>> >> >> > Hmmm, so looking at this, the "right" thing is probably to have a 
>>> >> >> > device
>>> >> >> > driver for the ACPI0004 device that parses its _CRS and then allows 
>>> >> >> > its
>>> >> >> > child devices to sub-allocate resources from the ranges in _CRS.  
>>> >> >> > However,
>>> >> >> > this would mean make VMBus be a child of the ACPI0004 device.  
>>> >> >> > Suppose
>>> >> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' 
>>> >> >> > device
>>> >> >> > would need to create a child device for all of its child devices.  
>>> >> >> > Right
>>> >> >> > now acpi0 also creates devices for them which is somewhat messy 
>>> >> >> > (acpi0
>>> >> >> > creates child devices anywhere in its namespace that have a valid 
>>> >> >> > _HID).
>>> >> >> > You can find those duplicates and remove them during acpi_module0's 
>>> >> >> > attach
>>> >> >> > routine before creating its own child device_t devices.  (We 
>>> >> >> > associate
>>> >> >> > a device_t with each Handle when creating device_t's for ACPI 
>>> >> >> > handles
>>> >> >> > which is how you can find the old device that is a direct child of 
>>> >> >> > acpi0
>>> >> >> > so that it can be removed).
>>> >> >>
>>> >> >> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
>>> >> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
>>> >> >> we did to the hyper-v's pcib0.
>>> >> >
>>> >> > The acpi_pci driver used to do the remove/reassociate part.  What acpi0
>>> >> > should probably be doing is only creating device_t nodes for immediate
>>> >> > children.  This would require an ACPI-aware isa0 for LPC devices 

Re: Add support for ACPI Module Device ACPI0004?

[Sepherosa Ziehau]

On Tue, May 2, 2017 at 12:25 AM, John Baldwin  wrote:
> On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote:
>> On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin  wrote:
>> > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
>> >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin  wrote:
>> >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
>> >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin  wrote:
>> >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>> >> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
>> >> >> >> > Sent: Thursday, April 20, 2017 02:34
>> >> >> >> > > Can we add the support of "ACPI0004" with the below one-line 
>> >> >> >> > > change?
>> >> >> >> > >
>> >> >> >> > >  acpi_sysres_probe(device_t dev)
>> >> >> >> > >  {
>> >> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
>> >> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
>> >> >> >> > > "ACPI0004", NULL };
>> >> >> >> > >
>> >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
>> >> >> >> > though we
>> >> >> >> > in turn allow any child of acpi0 to suballocate those ranges 
>> >> >> >> > (since historically
>> >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by 
>> >> >> >> > things like the
>> >> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 
>> >> >> >> > in the ACPI
>> >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
>> >> >> >> > particular, it
>> >> >> >> > seems that 004 should only allow direct children to suballocate?  
>> >> >> >> > This
>> >> >> >> > change might work, but it will allow more devices to allocate the 
>> >> >> >> > ranges in
>> >> >> >> >  _CRS than otherwise.
>> >> >> >> >
>> >> >> >> > Do you have an acpidump from a guest system that contains an 
>> >> >> >> > ACPI0004
>> >> >> >> > node that you can share?
>> >> >> >> >
>> >> >> >> > John Baldwin
>> >> >> >>
>> >> >> >> Hi John,
>> >> >> >> Thanks for the help!
>> >> >> >>
>> >> >> >> Please see the attached file, which is got by
>> >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>> >> >> >>
>> >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>> >> >> >> "VMBus" (VMBS).
>> >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we 
>> >> >> >> can't
>> >> >> >> see the length of the MMIO range in the dumped asl code, it does 
>> >> >> >> have
>> >> >> >> a 512MB MMIO range [0xFE000, 0xF].
>> >> >> >>
>> >> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
>> >> >> >> With the above one-line change, I can first find the child device
>> >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>> >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>> >> >> >>
>> >> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
>> >> >> >> we can add a new small driver for ACPI0004, just like we added VMBus
>> >> >> >> driver as a child device of acpi0?
>> >> >> >
>> >> >> > Hmmm, so looking at this, the "right" thing is probably to have a 
>> >> >> > device
>> >> >> > driver for the ACPI0004 device that parses its _CRS and then allows 
>> >> >> > its
>> >> >> > child devices to sub-allocate resources from the ranges in _CRS.  
>> >> >> > However,
>> >> >> > this would mean make VMBus be a child of the ACPI0004 device.  
>> >> >> > Suppose
>> >> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' 
>> >> >> > device
>> >> >> > would need to create a child device for all of its child devices.  
>> >> >> > Right
>> >> >> > now acpi0 also creates devices for them which is somewhat messy 
>> >> >> > (acpi0
>> >> >> > creates child devices anywhere in its namespace that have a valid 
>> >> >> > _HID).
>> >> >> > You can find those duplicates and remove them during acpi_module0's 
>> >> >> > attach
>> >> >> > routine before creating its own child device_t devices.  (We 
>> >> >> > associate
>> >> >> > a device_t with each Handle when creating device_t's for ACPI handles
>> >> >> > which is how you can find the old device that is a direct child of 
>> >> >> > acpi0
>> >> >> > so that it can be removed).
>> >> >>
>> >> >> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
>> >> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
>> >> >> we did to the hyper-v's pcib0.
>> >> >
>> >> > The acpi_pci driver used to do the remove/reassociate part.  What acpi0
>> >> > should probably be doing is only creating device_t nodes for immediate
>> >> > children.  This would require an ACPI-aware isa0 for LPC devices below
>> >> > the ISA bus in the ACPI namespace.  We haven't done that in part because
>> >> > BIOS vendors are not always consistent in placing LPC devices under an
>> >> > ISA bus.  However, you otherwise have no good way to find 

Re: Add support for ACPI Module Device ACPI0004?

[John Baldwin]

On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote:
> On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin  wrote:
> > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
> >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin  wrote:
> >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin  wrote:
> >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> >> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
> >> >> >> > Sent: Thursday, April 20, 2017 02:34
> >> >> >> > > Can we add the support of "ACPI0004" with the below one-line 
> >> >> >> > > change?
> >> >> >> > >
> >> >> >> > >  acpi_sysres_probe(device_t dev)
> >> >> >> > >  {
> >> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> >> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
> >> >> >> > > "ACPI0004", NULL };
> >> >> >> > >
> >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
> >> >> >> > though we
> >> >> >> > in turn allow any child of acpi0 to suballocate those ranges 
> >> >> >> > (since historically
> >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by 
> >> >> >> > things like the
> >> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 
> >> >> >> > in the ACPI
> >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
> >> >> >> > particular, it
> >> >> >> > seems that 004 should only allow direct children to suballocate?  
> >> >> >> > This
> >> >> >> > change might work, but it will allow more devices to allocate the 
> >> >> >> > ranges in
> >> >> >> >  _CRS than otherwise.
> >> >> >> >
> >> >> >> > Do you have an acpidump from a guest system that contains an 
> >> >> >> > ACPI0004
> >> >> >> > node that you can share?
> >> >> >> >
> >> >> >> > John Baldwin
> >> >> >>
> >> >> >> Hi John,
> >> >> >> Thanks for the help!
> >> >> >>
> >> >> >> Please see the attached file, which is got by
> >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> >> >> >>
> >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> >> >> >> "VMBus" (VMBS).
> >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we 
> >> >> >> can't
> >> >> >> see the length of the MMIO range in the dumped asl code, it does have
> >> >> >> a 512MB MMIO range [0xFE000, 0xF].
> >> >> >>
> >> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
> >> >> >> With the above one-line change, I can first find the child device
> >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> >> >> >>
> >> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
> >> >> >> we can add a new small driver for ACPI0004, just like we added VMBus
> >> >> >> driver as a child device of acpi0?
> >> >> >
> >> >> > Hmmm, so looking at this, the "right" thing is probably to have a 
> >> >> > device
> >> >> > driver for the ACPI0004 device that parses its _CRS and then allows 
> >> >> > its
> >> >> > child devices to sub-allocate resources from the ranges in _CRS.  
> >> >> > However,
> >> >> > this would mean make VMBus be a child of the ACPI0004 device.  Suppose
> >> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' 
> >> >> > device
> >> >> > would need to create a child device for all of its child devices.  
> >> >> > Right
> >> >> > now acpi0 also creates devices for them which is somewhat messy (acpi0
> >> >> > creates child devices anywhere in its namespace that have a valid 
> >> >> > _HID).
> >> >> > You can find those duplicates and remove them during acpi_module0's 
> >> >> > attach
> >> >> > routine before creating its own child device_t devices.  (We associate
> >> >> > a device_t with each Handle when creating device_t's for ACPI handles
> >> >> > which is how you can find the old device that is a direct child of 
> >> >> > acpi0
> >> >> > so that it can be removed).
> >> >>
> >> >> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
> >> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
> >> >> we did to the hyper-v's pcib0.
> >> >
> >> > The acpi_pci driver used to do the remove/reassociate part.  What acpi0
> >> > should probably be doing is only creating device_t nodes for immediate
> >> > children.  This would require an ACPI-aware isa0 for LPC devices below
> >> > the ISA bus in the ACPI namespace.  We haven't done that in part because
> >> > BIOS vendors are not always consistent in placing LPC devices under an
> >> > ISA bus.  However, you otherwise have no good way to find your parent
> >> > ACPI0004 device.  You could perhaps find your ACPI handle, ask for its
> >> > parent handle, then ask for the device_t of that handle to find the
> >> > ACPI0004 device, but then you'd need to have 

Re: Add support for ACPI Module Device ACPI0004?

[Sepherosa Ziehau]

On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin  wrote:
> On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
>> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin  wrote:
>> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
>> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin  wrote:
>> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
>> >> >> > Sent: Thursday, April 20, 2017 02:34
>> >> >> > > Can we add the support of "ACPI0004" with the below one-line 
>> >> >> > > change?
>> >> >> > >
>> >> >> > >  acpi_sysres_probe(device_t dev)
>> >> >> > >  {
>> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
>> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
>> >> >> > > "ACPI0004", NULL };
>> >> >> > >
>> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
>> >> >> > though we
>> >> >> > in turn allow any child of acpi0 to suballocate those ranges (since 
>> >> >> > historically
>> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by things 
>> >> >> > like the
>> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in 
>> >> >> > the ACPI
>> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
>> >> >> > particular, it
>> >> >> > seems that 004 should only allow direct children to suballocate?  
>> >> >> > This
>> >> >> > change might work, but it will allow more devices to allocate the 
>> >> >> > ranges in
>> >> >> >  _CRS than otherwise.
>> >> >> >
>> >> >> > Do you have an acpidump from a guest system that contains an ACPI0004
>> >> >> > node that you can share?
>> >> >> >
>> >> >> > John Baldwin
>> >> >>
>> >> >> Hi John,
>> >> >> Thanks for the help!
>> >> >>
>> >> >> Please see the attached file, which is got by
>> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>> >> >>
>> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>> >> >> "VMBus" (VMBS).
>> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
>> >> >> see the length of the MMIO range in the dumped asl code, it does have
>> >> >> a 512MB MMIO range [0xFE000, 0xF].
>> >> >>
>> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
>> >> >> With the above one-line change, I can first find the child device
>> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>> >> >>
>> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
>> >> >> we can add a new small driver for ACPI0004, just like we added VMBus
>> >> >> driver as a child device of acpi0?
>> >> >
>> >> > Hmmm, so looking at this, the "right" thing is probably to have a device
>> >> > driver for the ACPI0004 device that parses its _CRS and then allows its
>> >> > child devices to sub-allocate resources from the ranges in _CRS.  
>> >> > However,
>> >> > this would mean make VMBus be a child of the ACPI0004 device.  Suppose
>> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' 
>> >> > device
>> >> > would need to create a child device for all of its child devices.  Right
>> >> > now acpi0 also creates devices for them which is somewhat messy (acpi0
>> >> > creates child devices anywhere in its namespace that have a valid _HID).
>> >> > You can find those duplicates and remove them during acpi_module0's 
>> >> > attach
>> >> > routine before creating its own child device_t devices.  (We associate
>> >> > a device_t with each Handle when creating device_t's for ACPI handles
>> >> > which is how you can find the old device that is a direct child of acpi0
>> >> > so that it can be removed).
>> >>
>> >> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
>> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
>> >> we did to the hyper-v's pcib0.
>> >
>> > The acpi_pci driver used to do the remove/reassociate part.  What acpi0
>> > should probably be doing is only creating device_t nodes for immediate
>> > children.  This would require an ACPI-aware isa0 for LPC devices below
>> > the ISA bus in the ACPI namespace.  We haven't done that in part because
>> > BIOS vendors are not always consistent in placing LPC devices under an
>> > ISA bus.  However, you otherwise have no good way to find your parent
>> > ACPI0004 device.  You could perhaps find your ACPI handle, ask for its
>> > parent handle, then ask for the device_t of that handle to find the
>> > ACPI0004 device, but then you'd need to have all your bus_alloc_resource
>> > calls go to that device, not your "real" parent of acpi0, which means
>> > you can't use any of the standard bus_alloc_resource() methods like
>> > bus_alloc_resource_any() but would have to manually use BUS_ALLOC_RESOURCE
>> > with the ACPI0004 device as the explicit first argument.  

Re: Add support for ACPI Module Device ACPI0004?

[John Baldwin]

On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin  wrote:
> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin  wrote:
> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
> >> >> > Sent: Thursday, April 20, 2017 02:34
> >> >> > > Can we add the support of "ACPI0004" with the below one-line change?
> >> >> > >
> >> >> > >  acpi_sysres_probe(device_t dev)
> >> >> > >  {
> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
> >> >> > > "ACPI0004", NULL };
> >> >> > >
> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
> >> >> > though we
> >> >> > in turn allow any child of acpi0 to suballocate those ranges (since 
> >> >> > historically
> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by things 
> >> >> > like the
> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in 
> >> >> > the ACPI
> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
> >> >> > particular, it
> >> >> > seems that 004 should only allow direct children to suballocate?  This
> >> >> > change might work, but it will allow more devices to allocate the 
> >> >> > ranges in
> >> >> >  _CRS than otherwise.
> >> >> >
> >> >> > Do you have an acpidump from a guest system that contains an ACPI0004
> >> >> > node that you can share?
> >> >> >
> >> >> > John Baldwin
> >> >>
> >> >> Hi John,
> >> >> Thanks for the help!
> >> >>
> >> >> Please see the attached file, which is got by
> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> >> >>
> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> >> >> "VMBus" (VMBS).
> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
> >> >> see the length of the MMIO range in the dumped asl code, it does have
> >> >> a 512MB MMIO range [0xFE000, 0xF].
> >> >>
> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
> >> >> With the above one-line change, I can first find the child device
> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> >> >>
> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
> >> >> we can add a new small driver for ACPI0004, just like we added VMBus
> >> >> driver as a child device of acpi0?
> >> >
> >> > Hmmm, so looking at this, the "right" thing is probably to have a device
> >> > driver for the ACPI0004 device that parses its _CRS and then allows its
> >> > child devices to sub-allocate resources from the ranges in _CRS.  
> >> > However,
> >> > this would mean make VMBus be a child of the ACPI0004 device.  Suppose
> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' 
> >> > device
> >> > would need to create a child device for all of its child devices.  Right
> >> > now acpi0 also creates devices for them which is somewhat messy (acpi0
> >> > creates child devices anywhere in its namespace that have a valid _HID).
> >> > You can find those duplicates and remove them during acpi_module0's 
> >> > attach
> >> > routine before creating its own child device_t devices.  (We associate
> >> > a device_t with each Handle when creating device_t's for ACPI handles
> >> > which is how you can find the old device that is a direct child of acpi0
> >> > so that it can be removed).
> >>
> >> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
> >> we did to the hyper-v's pcib0.
> >
> > The acpi_pci driver used to do the remove/reassociate part.  What acpi0
> > should probably be doing is only creating device_t nodes for immediate
> > children.  This would require an ACPI-aware isa0 for LPC devices below
> > the ISA bus in the ACPI namespace.  We haven't done that in part because
> > BIOS vendors are not always consistent in placing LPC devices under an
> > ISA bus.  However, you otherwise have no good way to find your parent
> > ACPI0004 device.  You could perhaps find your ACPI handle, ask for its
> > parent handle, then ask for the device_t of that handle to find the
> > ACPI0004 device, but then you'd need to have all your bus_alloc_resource
> > calls go to that device, not your "real" parent of acpi0, which means
> > you can't use any of the standard bus_alloc_resource() methods like
> > bus_alloc_resource_any() but would have to manually use BUS_ALLOC_RESOURCE
> > with the ACPI0004 device as the explicit first argument.  It is primarily
> > the ability to let ACPI0004's driver transparently intercept all the
> > resource allocation so it can manage that is the reason for "VMBus"
> > to be a child of ACPI0004 

Re: Add support for ACPI Module Device ACPI0004?

[Sepherosa Ziehau]

On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin  wrote:
> On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
>> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin  wrote:
>> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>> >> > From: John Baldwin [mailto:j...@freebsd.org]
>> >> > Sent: Thursday, April 20, 2017 02:34
>> >> > > Can we add the support of "ACPI0004" with the below one-line change?
>> >> > >
>> >> > >  acpi_sysres_probe(device_t dev)
>> >> > >  {
>> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
>> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", 
>> >> > > NULL };
>> >> > >
>> >> > Hmm, so the role of C01 and C02 is to reserve system resources, though 
>> >> > we
>> >> > in turn allow any child of acpi0 to suballocate those ranges (since 
>> >> > historically
>> >> > c01 and c02 tend to allocate I/O ranges that are then used by things 
>> >> > like the
>> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in 
>> >> > the ACPI
>> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
>> >> > particular, it
>> >> > seems that 004 should only allow direct children to suballocate?  This
>> >> > change might work, but it will allow more devices to allocate the 
>> >> > ranges in
>> >> >  _CRS than otherwise.
>> >> >
>> >> > Do you have an acpidump from a guest system that contains an ACPI0004
>> >> > node that you can share?
>> >> >
>> >> > John Baldwin
>> >>
>> >> Hi John,
>> >> Thanks for the help!
>> >>
>> >> Please see the attached file, which is got by
>> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>> >>
>> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>> >> "VMBus" (VMBS).
>> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
>> >> see the length of the MMIO range in the dumped asl code, it does have
>> >> a 512MB MMIO range [0xFE000, 0xF].
>> >>
>> >> It looks FreeBSD can't detect ACPI0004 automatically.
>> >> With the above one-line change, I can first find the child device
>> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>> >>
>> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
>> >> we can add a new small driver for ACPI0004, just like we added VMBus
>> >> driver as a child device of acpi0?
>> >
>> > Hmmm, so looking at this, the "right" thing is probably to have a device
>> > driver for the ACPI0004 device that parses its _CRS and then allows its
>> > child devices to sub-allocate resources from the ranges in _CRS.  However,
>> > this would mean make VMBus be a child of the ACPI0004 device.  Suppose
>> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device
>> > would need to create a child device for all of its child devices.  Right
>> > now acpi0 also creates devices for them which is somewhat messy (acpi0
>> > creates child devices anywhere in its namespace that have a valid _HID).
>> > You can find those duplicates and remove them during acpi_module0's attach
>> > routine before creating its own child device_t devices.  (We associate
>> > a device_t with each Handle when creating device_t's for ACPI handles
>> > which is how you can find the old device that is a direct child of acpi0
>> > so that it can be removed).
>>
>> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
>> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
>> we did to the hyper-v's pcib0.
>
> The acpi_pci driver used to do the remove/reassociate part.  What acpi0
> should probably be doing is only creating device_t nodes for immediate
> children.  This would require an ACPI-aware isa0 for LPC devices below
> the ISA bus in the ACPI namespace.  We haven't done that in part because
> BIOS vendors are not always consistent in placing LPC devices under an
> ISA bus.  However, you otherwise have no good way to find your parent
> ACPI0004 device.  You could perhaps find your ACPI handle, ask for its
> parent handle, then ask for the device_t of that handle to find the
> ACPI0004 device, but then you'd need to have all your bus_alloc_resource
> calls go to that device, not your "real" parent of acpi0, which means
> you can't use any of the standard bus_alloc_resource() methods like
> bus_alloc_resource_any() but would have to manually use BUS_ALLOC_RESOURCE
> with the ACPI0004 device as the explicit first argument.  It is primarily
> the ability to let ACPI0004's driver transparently intercept all the
> resource allocation so it can manage that is the reason for "VMBus"
> to be a child of ACPI0004 rather than its sibling.

Well, there could be more then one ACPI0004 typed devices, which could
not form a device tree for vmbus.

Thanks,
sephe

-- 
Tomorrow Will Never Die
___
freebsd-current@freebsd.org mailing list

RE: Add support for ACPI Module Device ACPI0004?

[Dexuan Cui]

> From: John Baldwin
> Sent: Thursday, April 27, 2017 00:14
> On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> > On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin  wrote:
> > > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> > >> > From: John Baldwin [mailto:j...@freebsd.org]
> > >> > Sent: Thursday, April 20, 2017 02:34
> > >> > > Can we add the support of "ACPI0004" with the below one-line
> change?
> > >> > >
> > >> > >  acpi_sysres_probe(device_t dev)
> > >> > >  {
> > >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> > >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004",
> NULL };
> > >> > >
> > >> > Hmm, so the role of C01 and C02 is to reserve system resources,
> though we
> > >> > in turn allow any child of acpi0 to suballocate those ranges (since
> historically
> > >> > c01 and c02 tend to allocate I/O ranges that are then used by things
> like the
> > >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in
> the ACPI
> > >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
> > >> > particular, it
> > >> > seems that 004 should only allow direct children to suballocate?  This
> > >> > change might work, but it will allow more devices to allocate the
> ranges in
> > >> >  _CRS than otherwise.
> > >> >
> > >> > Do you have an acpidump from a guest system that contains an
> ACPI0004
> > >> > node that you can share?
> > >> >
> > >> > John Baldwin
> > >>
> > >> Hi John,
> > >> Thanks for the help!
> > >>
> > >> Please see the attached file, which is got by
> > >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> > >>
> > >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> > >> "VMBus" (VMBS).
> > >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
> > >> see the length of the MMIO range in the dumped asl code, it does have
> > >> a 512MB MMIO range [0xFE000, 0xF].
> > >>
> > >> It looks FreeBSD can't detect ACPI0004 automatically.
> > >> With the above one-line change, I can first find the child device
> > >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> > >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> > >>
> > >> If you think we shouldn't touch acpi_sysresource0 here, I guess
> > >> we can add a new small driver for ACPI0004, just like we added VMBus
> > >> driver as a child device of acpi0?
> > >
> > > Hmmm, so looking at this, the "right" thing is probably to have a device
> > > driver for the ACPI0004 device that parses its _CRS and then allows its
> > > child devices to sub-allocate resources from the ranges in _CRS.  However,
> > > this would mean make VMBus be a child of the ACPI0004 device.
> Suppose
> > > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0'
> device
> > > would need to create a child device for all of its child devices.  Right
> > > now acpi0 also creates devices for them which is somewhat messy (acpi0
> > > creates child devices anywhere in its namespace that have a valid _HID).
> > > You can find those duplicates and remove them during acpi_module0's
> attach
> > > routine before creating its own child device_t devices.  (We associate
> > > a device_t with each Handle when creating device_t's for ACPI handles
> > > which is how you can find the old device that is a direct child of acpi0
> > > so that it can be removed).
> >
> > The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
> > hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
> > we did to the hyper-v's pcib0.
> 
> The acpi_pci driver used to do the remove/reassociate part.  What acpi0
> should probably be doing is only creating device_t nodes for immediate
> children.  This would require an ACPI-aware isa0 for LPC devices below
> the ISA bus in the ACPI namespace.  We haven't done that in part because
> BIOS vendors are not always consistent in placing LPC devices under an
> ISA bus.  However, you otherwise have no good way to find your parent
> ACPI0004 device.  You could perhaps find your ACPI handle, ask for its
> parent handle, then ask for the device_t of that handle to find the
> ACPI0004 device, but then you'd need to have all your bus_alloc_resource
> calls go to that device, not your "real" parent of acpi0, which means
> you can't use any of the standard bus_alloc_resource() methods like
> bus_alloc_resource_any() but would have to manually use
> BUS_ALLOC_RESOURCE
> with the ACPI0004 device as the explicit first argument.  It is primarily
> the ability to let ACPI0004's driver transparently intercept all the
> resource allocation so it can manage that is the reason for "VMBus"
> to be a child of ACPI0004 rather than its sibling.
> 
> --
> John Baldwin

Hi John,
Thank you for the detailed analysis, but IMHO this seems too complex? :-)

Can we just add a small driver for ACPI0004 like this:
https://reviews.freebsd.org/D10531

This way, we only 

Re: Add support for ACPI Module Device ACPI0004?

[John Baldwin]

On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin  wrote:
> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> >> > From: John Baldwin [mailto:j...@freebsd.org]
> >> > Sent: Thursday, April 20, 2017 02:34
> >> > > Can we add the support of "ACPI0004" with the below one-line change?
> >> > >
> >> > >  acpi_sysres_probe(device_t dev)
> >> > >  {
> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", 
> >> > > NULL };
> >> > >
> >> > Hmm, so the role of C01 and C02 is to reserve system resources, though we
> >> > in turn allow any child of acpi0 to suballocate those ranges (since 
> >> > historically
> >> > c01 and c02 tend to allocate I/O ranges that are then used by things 
> >> > like the
> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in the 
> >> > ACPI
> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
> >> > particular, it
> >> > seems that 004 should only allow direct children to suballocate?  This
> >> > change might work, but it will allow more devices to allocate the ranges 
> >> > in
> >> >  _CRS than otherwise.
> >> >
> >> > Do you have an acpidump from a guest system that contains an ACPI0004
> >> > node that you can share?
> >> >
> >> > John Baldwin
> >>
> >> Hi John,
> >> Thanks for the help!
> >>
> >> Please see the attached file, which is got by
> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> >>
> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> >> "VMBus" (VMBS).
> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
> >> see the length of the MMIO range in the dumped asl code, it does have
> >> a 512MB MMIO range [0xFE000, 0xF].
> >>
> >> It looks FreeBSD can't detect ACPI0004 automatically.
> >> With the above one-line change, I can first find the child device
> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> >>
> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
> >> we can add a new small driver for ACPI0004, just like we added VMBus
> >> driver as a child device of acpi0?
> >
> > Hmmm, so looking at this, the "right" thing is probably to have a device
> > driver for the ACPI0004 device that parses its _CRS and then allows its
> > child devices to sub-allocate resources from the ranges in _CRS.  However,
> > this would mean make VMBus be a child of the ACPI0004 device.  Suppose
> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device
> > would need to create a child device for all of its child devices.  Right
> > now acpi0 also creates devices for them which is somewhat messy (acpi0
> > creates child devices anywhere in its namespace that have a valid _HID).
> > You can find those duplicates and remove them during acpi_module0's attach
> > routine before creating its own child device_t devices.  (We associate
> > a device_t with each Handle when creating device_t's for ACPI handles
> > which is how you can find the old device that is a direct child of acpi0
> > so that it can be removed).
> 
> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
> we did to the hyper-v's pcib0.

The acpi_pci driver used to do the remove/reassociate part.  What acpi0
should probably be doing is only creating device_t nodes for immediate
children.  This would require an ACPI-aware isa0 for LPC devices below
the ISA bus in the ACPI namespace.  We haven't done that in part because
BIOS vendors are not always consistent in placing LPC devices under an
ISA bus.  However, you otherwise have no good way to find your parent
ACPI0004 device.  You could perhaps find your ACPI handle, ask for its
parent handle, then ask for the device_t of that handle to find the
ACPI0004 device, but then you'd need to have all your bus_alloc_resource
calls go to that device, not your "real" parent of acpi0, which means
you can't use any of the standard bus_alloc_resource() methods like
bus_alloc_resource_any() but would have to manually use BUS_ALLOC_RESOURCE
with the ACPI0004 device as the explicit first argument.  It is primarily
the ability to let ACPI0004's driver transparently intercept all the
resource allocation so it can manage that is the reason for "VMBus"
to be a child of ACPI0004 rather than its sibling.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Add support for ACPI Module Device ACPI0004?

[Sepherosa Ziehau]

On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin  wrote:
> On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>> > From: John Baldwin [mailto:j...@freebsd.org]
>> > Sent: Thursday, April 20, 2017 02:34
>> > > Can we add the support of "ACPI0004" with the below one-line change?
>> > >
>> > >  acpi_sysres_probe(device_t dev)
>> > >  {
>> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
>> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", 
>> > > NULL };
>> > >
>> > Hmm, so the role of C01 and C02 is to reserve system resources, though we
>> > in turn allow any child of acpi0 to suballocate those ranges (since 
>> > historically
>> > c01 and c02 tend to allocate I/O ranges that are then used by things like 
>> > the
>> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in the 
>> > ACPI
>> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In particular, 
>> > it
>> > seems that 004 should only allow direct children to suballocate?  This
>> > change might work, but it will allow more devices to allocate the ranges in
>> >  _CRS than otherwise.
>> >
>> > Do you have an acpidump from a guest system that contains an ACPI0004
>> > node that you can share?
>> >
>> > John Baldwin
>>
>> Hi John,
>> Thanks for the help!
>>
>> Please see the attached file, which is got by
>> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>>
>> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>> "VMBus" (VMBS).
>> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
>> see the length of the MMIO range in the dumped asl code, it does have
>> a 512MB MMIO range [0xFE000, 0xF].
>>
>> It looks FreeBSD can't detect ACPI0004 automatically.
>> With the above one-line change, I can first find the child device
>> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>>
>> If you think we shouldn't touch acpi_sysresource0 here, I guess
>> we can add a new small driver for ACPI0004, just like we added VMBus
>> driver as a child device of acpi0?
>
> Hmmm, so looking at this, the "right" thing is probably to have a device
> driver for the ACPI0004 device that parses its _CRS and then allows its
> child devices to sub-allocate resources from the ranges in _CRS.  However,
> this would mean make VMBus be a child of the ACPI0004 device.  Suppose
> we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device
> would need to create a child device for all of its child devices.  Right
> now acpi0 also creates devices for them which is somewhat messy (acpi0
> creates child devices anywhere in its namespace that have a valid _HID).
> You can find those duplicates and remove them during acpi_module0's attach
> routine before creating its own child device_t devices.  (We associate
> a device_t with each Handle when creating device_t's for ACPI handles
> which is how you can find the old device that is a direct child of acpi0
> so that it can be removed).

The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
we did to the hyper-v's pcib0.

Thanks,
sephe

-- 
Tomorrow Will Never Die
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Add support for ACPI Module Device ACPI0004?

[John Baldwin]

On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> > From: John Baldwin [mailto:j...@freebsd.org]
> > Sent: Thursday, April 20, 2017 02:34
> > > Can we add the support of "ACPI0004" with the below one-line change?
> > >
> > >  acpi_sysres_probe(device_t dev)
> > >  {
> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL 
> > > };
> > >
> > Hmm, so the role of C01 and C02 is to reserve system resources, though we
> > in turn allow any child of acpi0 to suballocate those ranges (since 
> > historically
> > c01 and c02 tend to allocate I/O ranges that are then used by things like 
> > the
> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in the 
> > ACPI
> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In particular, it
> > seems that 004 should only allow direct children to suballocate?  This
> > change might work, but it will allow more devices to allocate the ranges in
> >  _CRS than otherwise.
> > 
> > Do you have an acpidump from a guest system that contains an ACPI0004
> > node that you can share?
> > 
> > John Baldwin
> 
> Hi John,
> Thanks for the help!
> 
> Please see the attached file, which is got by
> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> 
> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> "VMBus" (VMBS). 
> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
> see the length of the MMIO range in the dumped asl code, it does have
> a 512MB MMIO range [0xFE000, 0xF].
> 
> It looks FreeBSD can't detect ACPI0004 automatically.
> With the above one-line change, I can first find the child device 
> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> 
> If you think we shouldn't touch acpi_sysresource0 here, I guess
> we can add a new small driver for ACPI0004, just like we added VMBus
> driver as a child device of acpi0?

Hmmm, so looking at this, the "right" thing is probably to have a device
driver for the ACPI0004 device that parses its _CRS and then allows its
child devices to sub-allocate resources from the ranges in _CRS.  However,
this would mean make VMBus be a child of the ACPI0004 device.  Suppose
we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device
would need to create a child device for all of its child devices.  Right
now acpi0 also creates devices for them which is somewhat messy (acpi0
creates child devices anywhere in its namespace that have a valid _HID).
You can find those duplicates and remove them during acpi_module0's attach
routine before creating its own child device_t devices.  (We associate
a device_t with each Handle when creating device_t's for ACPI handles
which is how you can find the old device that is a direct child of acpi0
so that it can be removed).

Then when you are the "VMBus" device_t your parent is the ACPI0004 device
so you can easily talk to it to obtain resources (probably ACPI0004 can
just intercept bus_if.m resource methods to manage the resources).

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Add support for ACPI Module Device ACPI0004?

[Dexuan Cui]

> From: John Baldwin [mailto:j...@freebsd.org]
> Sent: Thursday, April 20, 2017 02:34
> > Can we add the support of "ACPI0004" with the below one-line change?
> >
> >  acpi_sysres_probe(device_t dev)
> >  {
> > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL };
> >
> Hmm, so the role of C01 and C02 is to reserve system resources, though we
> in turn allow any child of acpi0 to suballocate those ranges (since 
> historically
> c01 and c02 tend to allocate I/O ranges that are then used by things like the
> EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in the ACPI
> 6.1 spec it's not quite clear that ACPI0004 is like that?  In particular, it
> seems that 004 should only allow direct children to suballocate?  This
> change might work, but it will allow more devices to allocate the ranges in
>  _CRS than otherwise.
> 
> Do you have an acpidump from a guest system that contains an ACPI0004
> node that you can share?
> 
> John Baldwin

Hi John,
Thanks for the help!

Please see the attached file, which is got by
"acpidump -dt | gzip -c9 > acpidump.dt.gz"

In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
"VMBus" (VMBS). 
It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
see the length of the MMIO range in the dumped asl code, it does have
a 512MB MMIO range [0xFE000, 0xF].

It looks FreeBSD can't detect ACPI0004 automatically.
With the above one-line change, I can first find the child device 
acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.

If you think we shouldn't touch acpi_sysresource0 here, I guess
we can add a new small driver for ACPI0004, just like we added VMBus
driver as a child device of acpi0?

-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Add support for ACPI Module Device ACPI0004?

[John Baldwin]

On Wednesday, April 19, 2017 12:26:51 PM Dexuan Cui wrote:
> The ACPI firmware of Hyper-V UEFI VM has a Module Device whose Hardware
> ID is "ACPI0004".  The module device has a _CRS object defining some MMIO
> ranges, which are needed when physical PCIe devices are passed through
> to the VM.
> 
> Currently it looks FreeBSD doesn't make use of the ACPI module device and
> hence the _CRS object can't be easily retrieved by Hyper-V VMBus driver.
> 
> Can we add the support of "ACPI0004" with the below one-line change?
> 
> Looking forward to your suggestion!
> 
> --- a/sys/dev/acpica/acpi_resource.c
> +++ b/sys/dev/acpica/acpi_resource.c
> @@ -653,7 +653,7 @@ MODULE_DEPEND(acpi_sysresource, acpi, 1, 1, 1);
>  static int
>  acpi_sysres_probe(device_t dev)
>  {
> -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL };
> 
>  if (acpi_disabled("sysresource") ||
> ACPI_ID_PROBE(device_get_parent(dev), dev, sysres_ids) == NULL)

Hmm, so the role of C01 and C02 is to reserve system resources, though we
in turn allow any child of acpi0 to suballocate those ranges (since historically
c01 and c02 tend to allocate I/O ranges that are then used by things like the
EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in the ACPI
6.1 spec it's not quite clear that ACPI0004 is like that?  In particular, it
seems that 004 should only allow direct children to suballocate?  This change
might work, but it will allow more devices to allocate the ranges in _CRS
than otherwise.

Do you have an acpidump from a guest system that contains an ACPI0004 node
that you can share?

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"