On Sun, Aug 28, 2011 at 7:27 PM, Huang Ying <ying.huang@xxxxxxxxx> wrote: > On 08/26/2011 09:43 PM, Bjorn Helgaas wrote: >> On Thu, Aug 25, 2011 at 10:13 PM, Huang Ying <ying.huang@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
