Re: APEI: Can not request iomem region for GARs

Bjorn Helgaas
2011-08-29T14:48:52Z

On Sun, Aug 28, 2011 at 7:27 PM, Huang Ying <ying.huang@intel.com> wrote:
> On 08/26/2011 09:43 PM, Bjorn Helgaas wrote:
>> On Thu, Aug 25, 2011 at 10:13 PM, Huang Ying <ying.huang@intel.com> wrote:
>>> Hi, Pavel,
>>>
>>> Sorry,  there is a minor issue in the patch.  Do you have time to try
>>> the updated version attached.
>>
>> I think Yinghai's patch is a better approach (though it needs a changelog).
>>
>> The ACPI NVS space should not be marked as "busy" by the e820 code in
>> the iomem_resource tree.
>>
>> It's way too complicated to mess around with registering NVS space and
>> trying to deal with it specially in APEI.
>
> ACPI NVS is different, it can be used only by firmware, and its
> interpreter, such as ACPI AML interpreter and APEI interpreter.  It can
> not be used by ordinary driver.  If my understanding is correct, this is
> why ACPI NVS is marked as busy.

I don't understand why ACPI NVS is different. If we reserve it in
iomem_resource (without marking it busy), it's already unavailable to
anything else unless you know something connected to the NVS region.

The only way to allocate space inside NVS is to first discover the
ACPI NVS resource, so you could pass it to request_resource() or
allocate_resource() as the "root" to allocate from. There's no
mechanism for locating that resource, so it's already protected in
that sense.

To use request_mem_region() (which marks the region busy), you all you
need is an address. The only way for a driver to learn an address
inside NVS is from the ACPI tables. So I think it's effectively
limited to APEI there, too.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html