>>> On 06.11.12 at 13:55, Josh Triplett <j...@joshtriplett.org> wrote: > On Tue, Nov 06, 2012 at 08:57:06AM +0000, Jan Beulich wrote: >> The question here is how to properly invalidate that data then: >> So far I was assuming that clearing the valid bit would be the way >> to go, as the specification says nothing on e.g. the image address >> being zero having any specific meaning. I need to do that in Xen, >> at least for the time being, as I'm not inclined to postpone >> indefinitely the use of boot services memory for normal memory >> allocations (which we would have to do if we wanted Dom0 to >> be able to access the image pointed to here). > > This doesn't postpone the use of boot services memory indefinitely; the > BGRT driver copies the image out, and the kernel then frees boot > services memory. That does introduce a delay in the use of boot > services memory, but not an indefinite one.
If and when Dom0 tells the hypervisor that it's done using that data is unknown from the hypervisor perspective, so for Xen this _is_ indefinitely. >> I was quite bad a design decision to allow (and even suggest) >> the image to live in boot services memory - one can't generally >> expect the ACPI parser to become available in an OS before >> setting up memory allocation. To Linux this already has turned >> out to be a problem, on Xen dealing with this would turn out >> even more cumbersome. > > What problems has this caused? None so far - I'm trying to prevent any from occurring. Or if you're referring to my use of the term "problems" above - I was referring to the fact that for this very reason the treatment of boot services memory had to be changed in Linux. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
