| Message ID | 9a0e5021a612951c4174c45099edc8a4fb5bd3bb.1677091168.git.demi@invisiblethingslab.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Call SetVirtualAddressMap() by default | expand |
On 22.02.2023 20:14, Demi Marie Obenour wrote: > To quote Andrew Cooper: > >> I know we've had this argument before, but not calling >> SetVirtualAddressMap() isn't a viable option. It's a prerequisite to >> function on literally millions of devices > > Qubes OS has been shipping EFI_SET_VIRTUAL_ADDRESS_MAP for years, and I > believe OpenXT and EVE ship it as well. Mark EFI_SET_VIRTUAL_ADDRESS_MAP > as SUPPORTED and enable it by default. This is insufficient justification. The main reason why we don't call it is because it can be called only once. Any entity taking over later (e.g. via kexec) can't do anything anymore about the virtual address associations once set. Hence what's needed to justify a change like this is an explanation of why this restriction is not really an issue to anyone in any case. Jan
On Thu, Feb 23, 2023 at 11:16:28AM +0100, Jan Beulich wrote: > On 22.02.2023 20:14, Demi Marie Obenour wrote: > > To quote Andrew Cooper: > > > >> I know we've had this argument before, but not calling > >> SetVirtualAddressMap() isn't a viable option. It's a prerequisite to > >> function on literally millions of devices > > > > Qubes OS has been shipping EFI_SET_VIRTUAL_ADDRESS_MAP for years, and I > > believe OpenXT and EVE ship it as well. Mark EFI_SET_VIRTUAL_ADDRESS_MAP > > as SUPPORTED and enable it by default. > > This is insufficient justification. The main reason why we don't call > it is because it can be called only once. Any entity taking over later > (e.g. via kexec) can't do anything anymore about the virtual address > associations once set. Hence what's needed to justify a change like > this is an explanation of why this restriction is not really an issue > to anyone in any case. AFAIR from the discussion about the original patch, kexec under Xen does not preserve runtime services working anyway, so this limitation is more about some possible kexec implementation in the future, not actually breaking something right now. And since Linux calls SetVirtualAddressMap() _and_ supports kexec just fine, it's definitely possible to design this future kexec extension to work after SetVirtualAddressMap() too. Relevant parts of that older discussion: - https://lore.kernel.org/all/272a9354-bcb4-50a4-a251-6a453221d6e3@citrix.com/T/#u - https://lore.kernel.org/all/20191009235725.GT8065@mail-itl/T/#u
On 23.02.2023 14:08, Marek Marczykowski-Górecki wrote: > On Thu, Feb 23, 2023 at 11:16:28AM +0100, Jan Beulich wrote: >> On 22.02.2023 20:14, Demi Marie Obenour wrote: >>> To quote Andrew Cooper: >>> >>>> I know we've had this argument before, but not calling >>>> SetVirtualAddressMap() isn't a viable option. It's a prerequisite to >>>> function on literally millions of devices >>> >>> Qubes OS has been shipping EFI_SET_VIRTUAL_ADDRESS_MAP for years, and I >>> believe OpenXT and EVE ship it as well. Mark EFI_SET_VIRTUAL_ADDRESS_MAP >>> as SUPPORTED and enable it by default. >> >> This is insufficient justification. The main reason why we don't call >> it is because it can be called only once. Any entity taking over later >> (e.g. via kexec) can't do anything anymore about the virtual address >> associations once set. Hence what's needed to justify a change like >> this is an explanation of why this restriction is not really an issue >> to anyone in any case. > > AFAIR from the discussion about the original patch, kexec under Xen does > not preserve runtime services working anyway, so this limitation is more > about some possible kexec implementation in the future, not actually > breaking something right now. And since Linux calls > SetVirtualAddressMap() _and_ supports kexec just fine, it's definitely > possible to design this future kexec extension to work after > SetVirtualAddressMap() too. > > Relevant parts of that older discussion: > - https://lore.kernel.org/all/272a9354-bcb4-50a4-a251-6a453221d6e3@citrix.com/T/#u > - https://lore.kernel.org/all/20191009235725.GT8065@mail-itl/T/#u Well, there are various statements there without further reference. I'm having a hard time seeing how a full-fledged Linux could do well without runtime services, or without being able to set the virtual address map to its liking. If they can, then a question would be why they need to set the virtual address map in the first place (yes, there is this supposed "firmware bugs" argument, which unfortunately I lack any proof of; at the very least I'm unaware of bug reports against Xen boiling down to us not making this call). Plus maybe they can merely because old and new OS are similar enough in their (virtual) memory layout? IOW kexec-ing to Linux for crash dumping purposes is just one (important) example of the functionality that needs retaining. Once we get better PVH Dom0 support, maybe other Dom0 OSes surface with entirely different needs. As said back then - part of the reason why in the original implementation I've avoided making this call is because of the fear of closing possible roads we may need to take in the future. Jan
On Thu, Feb 23, 2023 at 02:21:11PM +0100, Jan Beulich wrote: > On 23.02.2023 14:08, Marek Marczykowski-Górecki wrote: > > On Thu, Feb 23, 2023 at 11:16:28AM +0100, Jan Beulich wrote: > >> On 22.02.2023 20:14, Demi Marie Obenour wrote: > >>> To quote Andrew Cooper: > >>> > >>>> I know we've had this argument before, but not calling > >>>> SetVirtualAddressMap() isn't a viable option. It's a prerequisite to > >>>> function on literally millions of devices > >>> > >>> Qubes OS has been shipping EFI_SET_VIRTUAL_ADDRESS_MAP for years, and I > >>> believe OpenXT and EVE ship it as well. Mark EFI_SET_VIRTUAL_ADDRESS_MAP > >>> as SUPPORTED and enable it by default. > >> > >> This is insufficient justification. The main reason why we don't call > >> it is because it can be called only once. Any entity taking over later > >> (e.g. via kexec) can't do anything anymore about the virtual address > >> associations once set. Hence what's needed to justify a change like > >> this is an explanation of why this restriction is not really an issue > >> to anyone in any case. > > > > AFAIR from the discussion about the original patch, kexec under Xen does > > not preserve runtime services working anyway, so this limitation is more > > about some possible kexec implementation in the future, not actually > > breaking something right now. And since Linux calls > > SetVirtualAddressMap() _and_ supports kexec just fine, it's definitely > > possible to design this future kexec extension to work after > > SetVirtualAddressMap() too. > > > > Relevant parts of that older discussion: > > - https://lore.kernel.org/all/272a9354-bcb4-50a4-a251-6a453221d6e3@citrix.com/T/#u > > - https://lore.kernel.org/all/20191009235725.GT8065@mail-itl/T/#u > > Well, there are various statements there without further reference. I'm > having a hard time seeing how a full-fledged Linux could do well without > runtime services, or without being able to set the virtual address map > to its liking. If they can, then a question would be why they need to > set the virtual address map in the first place (yes, there is this > supposed "firmware bugs" argument, which unfortunately I lack any proof > of; at the very least I'm unaware of bug reports against Xen boiling > down to us not making this call). The second link points at a thread of one of such bug reports. The first link points at thread, where initial message contains list of systems affected. If that is not enough, I can point you also dig up (at least) tens of Qubes users reporting similar issues in the past. I'm sure Andrew could do the same about XenServer (which is why "mapbs" workaround exists). > Plus maybe they can merely because old > and new OS are similar enough in their (virtual) memory layout? IOW > kexec-ing to Linux for crash dumping purposes is just one (important) > example of the functionality that needs retaining. It works just fine with Xen calling SetVirtualAddressMap(). SetVirtualAddressMap() is relevant only for using runtime services, and you don't need them for crash dumps. In fact, runtime services are not accessible to post-kexec Linux anyway, so this call doesn't change anything. Additionally, given most stuff works just fine with efi=no-rs proves it isn't severe limitation, if it really would need to be there - but as Andrew noted, given Linux example, it doesn't really need to be the case - it may simply require a bit more thinking when adding runtime services capability past kexec. > Once we get better > PVH Dom0 support, maybe other Dom0 OSes surface with entirely different > needs. I find this claim rather weird. Runtime services are a thing that Xen needs to call, not some domain. And Xen has control over its memory layout. _If_ PVH dom0 would really turn out to be incompatible with SetVirtualAddressMap() call by Xen (which I highly doubt), then some alternative for that case can be made. But that's only speculation. > As said back then - part of the reason why in the original > implementation I've avoided making this call is because of the fear of > closing possible roads we may need to take in the future. Yet, not calling SetVirtualAddressMap() leads to actual issues _right now_, not in some hypothetical undefined future.
On 23.02.2023 14:56, Marek Marczykowski-Górecki wrote: > On Thu, Feb 23, 2023 at 02:21:11PM +0100, Jan Beulich wrote: >> On 23.02.2023 14:08, Marek Marczykowski-Górecki wrote: >>> On Thu, Feb 23, 2023 at 11:16:28AM +0100, Jan Beulich wrote: >>>> On 22.02.2023 20:14, Demi Marie Obenour wrote: >>>>> To quote Andrew Cooper: >>>>> >>>>>> I know we've had this argument before, but not calling >>>>>> SetVirtualAddressMap() isn't a viable option. It's a prerequisite to >>>>>> function on literally millions of devices >>>>> >>>>> Qubes OS has been shipping EFI_SET_VIRTUAL_ADDRESS_MAP for years, and I >>>>> believe OpenXT and EVE ship it as well. Mark EFI_SET_VIRTUAL_ADDRESS_MAP >>>>> as SUPPORTED and enable it by default. >>>> >>>> This is insufficient justification. The main reason why we don't call >>>> it is because it can be called only once. Any entity taking over later >>>> (e.g. via kexec) can't do anything anymore about the virtual address >>>> associations once set. Hence what's needed to justify a change like >>>> this is an explanation of why this restriction is not really an issue >>>> to anyone in any case. >>> >>> AFAIR from the discussion about the original patch, kexec under Xen does >>> not preserve runtime services working anyway, so this limitation is more >>> about some possible kexec implementation in the future, not actually >>> breaking something right now. And since Linux calls >>> SetVirtualAddressMap() _and_ supports kexec just fine, it's definitely >>> possible to design this future kexec extension to work after >>> SetVirtualAddressMap() too. >>> >>> Relevant parts of that older discussion: >>> - https://lore.kernel.org/all/272a9354-bcb4-50a4-a251-6a453221d6e3@citrix.com/T/#u >>> - https://lore.kernel.org/all/20191009235725.GT8065@mail-itl/T/#u >> >> Well, there are various statements there without further reference. I'm >> having a hard time seeing how a full-fledged Linux could do well without >> runtime services, or without being able to set the virtual address map >> to its liking. If they can, then a question would be why they need to >> set the virtual address map in the first place (yes, there is this >> supposed "firmware bugs" argument, which unfortunately I lack any proof >> of; at the very least I'm unaware of bug reports against Xen boiling >> down to us not making this call). > > The second link points at a thread of one of such bug reports. Hmm, yes, digging through the about two dozen mails, I can see there is a connection to (not) calling SetVirtualAddressMap() there. >> Plus maybe they can merely because old >> and new OS are similar enough in their (virtual) memory layout? IOW >> kexec-ing to Linux for crash dumping purposes is just one (important) >> example of the functionality that needs retaining. > > It works just fine with Xen calling SetVirtualAddressMap(). > SetVirtualAddressMap() is relevant only for using runtime services, and > you don't need them for crash dumps. In fact, runtime services are not > accessible to post-kexec Linux anyway, so this call doesn't change > anything. > Additionally, given most stuff works > just fine with efi=no-rs proves it isn't severe limitation, if it really > would need to be there - but as Andrew noted, given Linux example, it > doesn't really need to be the case - it may simply require a bit more > thinking when adding runtime services capability past kexec. All of what you say here is what I had meant to cover by adding the "(important)", which initially I didn't have. >> Once we get better >> PVH Dom0 support, maybe other Dom0 OSes surface with entirely different >> needs. > > I find this claim rather weird. Runtime services are a thing that Xen > needs to call, not some domain. And Xen has control over its memory > layout. > > _If_ PVH dom0 would really turn out to be incompatible with > SetVirtualAddressMap() call by Xen (which I highly doubt), then some > alternative for that case can be made. But that's only speculation. The remark wasn't about Dom0 itself wanting runtime services access: Dom0 isn't going to be provided such, at least not to the physical EFI's. If such was needed for PVH Dom0, we'd need to wire it to virtual firmware hooks (which in turn may or may not be viewed as against some of the ideas of PVH). The remark was instead meant to point out that such an alternative OS may want to invoke another (native) instance of itself for e.g. crash dumping purposes. >> As said back then - part of the reason why in the original >> implementation I've avoided making this call is because of the fear of >> closing possible roads we may need to take in the future. > > Yet, not calling SetVirtualAddressMap() leads to actual issues _right > now_, not in some hypothetical undefined future. That's the way you, Andrew, and others like to put it. My view at this is that it's not the lack of the call, but the improper implementation of firmware which leads to an apparent need for this call. Like for all other firmware bug workarounds, I'm happy to accept any proposals for workarounds, as long as such workarounds either don't impact spec- compliant systems, or as long as they're off by default. In the case here this would mean that I'm likely to approve a change which converts the EFI_SET_VIRTUAL_ADDRESS_MAP Kconfig to a command line option (as long as it looks technically correct, of course), improving flexibility from the present build-time-only control. (Qubes and other distros would then be free to change the default of that option from "false" to "true", and that would be a pretty easy to maintain local change.) However, part of the reason why originally this wasn't (even meant to be) controllable via Kconfig (or any pre-Kconfig means) was that I don't think the handling of the ->VirtualStart fields is correct for this case in efi_init_memory(): The final layout simply cannot be done there (after SetVirtualAddressMap() was already called). Since I don't think laying out virtual space can be moved ahead, this would mean moving the call to SetVirtualAddressMap() past this layout phase. Yet then we may again end up calling runtime services functions (time ones in particular, but note that I didn't check the order of things, so "may" was deliberate) ahead of calling SetVirtualAddressMap(). Plus, once you look at the layout code, you'll find a number of cases which simply end in an error message. To confess - I was quite happy back at the time that I could use the kexec concern as a justification for not needing to solve these issues right away. These issues would, however, need sorting (by code changes or verbal justification) no matter whether the Kconfig default was to change (or even just the EXPERT dependency to go away), or whether the conversion to a command line option was the way to go. Jan
On Fri, Feb 24, 2023 at 8:20 AM Jan Beulich <jbeulich@suse.com> wrote: > On 23.02.2023 14:56, Marek Marczykowski-Górecki wrote: > > On Thu, Feb 23, 2023 at 02:21:11PM +0100, Jan Beulich wrote: > >> On 23.02.2023 14:08, Marek Marczykowski-Górecki wrote: > >>> On Thu, Feb 23, 2023 at 11:16:28AM +0100, Jan Beulich wrote: > >>>> On 22.02.2023 20:14, Demi Marie Obenour wrote: > >>>>> To quote Andrew Cooper: > >>>>> > >>>>>> I know we've had this argument before, but not calling > >>>>>> SetVirtualAddressMap() isn't a viable option. It's a prerequisite > to > >>>>>> function on literally millions of devices > >>>>> > >>>>> Qubes OS has been shipping EFI_SET_VIRTUAL_ADDRESS_MAP for years, > and I > >>>>> believe OpenXT and EVE ship it as well. Mark > EFI_SET_VIRTUAL_ADDRESS_MAP > >>>>> as SUPPORTED and enable it by default. > >>>> > >>>> This is insufficient justification. The main reason why we don't call > >>>> it is because it can be called only once. Any entity taking over later > >>>> (e.g. via kexec) can't do anything anymore about the virtual address > >>>> associations once set. Hence what's needed to justify a change like > >>>> this is an explanation of why this restriction is not really an issue > >>>> to anyone in any case. > >>> > >>> AFAIR from the discussion about the original patch, kexec under Xen > does > >>> not preserve runtime services working anyway, so this limitation is > more > >>> about some possible kexec implementation in the future, not actually > >>> breaking something right now. And since Linux calls > >>> SetVirtualAddressMap() _and_ supports kexec just fine, it's definitely > >>> possible to design this future kexec extension to work after > >>> SetVirtualAddressMap() too. > >>> > >>> Relevant parts of that older discussion: > >>> - > https://lore.kernel.org/all/272a9354-bcb4-50a4-a251-6a453221d6e3@citrix.com/T/#u > >>> - https://lore.kernel.org/all/20191009235725.GT8065@mail-itl/T/#u > >> > >> Well, there are various statements there without further reference. I'm > >> having a hard time seeing how a full-fledged Linux could do well without > >> runtime services, or without being able to set the virtual address map > >> to its liking. If they can, then a question would be why they need to > >> set the virtual address map in the first place (yes, there is this > >> supposed "firmware bugs" argument, which unfortunately I lack any proof > >> of; at the very least I'm unaware of bug reports against Xen boiling > >> down to us not making this call). > > > > The second link points at a thread of one of such bug reports. > > Hmm, yes, digging through the about two dozen mails, I can see there is a > connection to (not) calling SetVirtualAddressMap() there. > > >> Plus maybe they can merely because old > >> and new OS are similar enough in their (virtual) memory layout? IOW > >> kexec-ing to Linux for crash dumping purposes is just one (important) > >> example of the functionality that needs retaining. > > > > It works just fine with Xen calling SetVirtualAddressMap(). > > SetVirtualAddressMap() is relevant only for using runtime services, and > > you don't need them for crash dumps. In fact, runtime services are not > > accessible to post-kexec Linux anyway, so this call doesn't change > > anything. > > Additionally, given most stuff works > > just fine with efi=no-rs proves it isn't severe limitation, if it really > > would need to be there - but as Andrew noted, given Linux example, it > > doesn't really need to be the case - it may simply require a bit more > > thinking when adding runtime services capability past kexec. > > All of what you say here is what I had meant to cover by adding the > "(important)", which initially I didn't have. > > >> Once we get better > >> PVH Dom0 support, maybe other Dom0 OSes surface with entirely different > >> needs. > > > > I find this claim rather weird. Runtime services are a thing that Xen > > needs to call, not some domain. And Xen has control over its memory > > layout. > > > > _If_ PVH dom0 would really turn out to be incompatible with > > SetVirtualAddressMap() call by Xen (which I highly doubt), then some > > alternative for that case can be made. But that's only speculation. > > The remark wasn't about Dom0 itself wanting runtime services access: > Dom0 isn't going to be provided such, at least not to the physical EFI's. > If such was needed for PVH Dom0, we'd need to wire it to virtual firmware > hooks (which in turn may or may not be viewed as against some of the > ideas of PVH). > > The remark was instead meant to point out that such an alternative OS > may want to invoke another (native) instance of itself for e.g. crash > dumping purposes. > > >> As said back then - part of the reason why in the original > >> implementation I've avoided making this call is because of the fear of > >> closing possible roads we may need to take in the future. > > > > Yet, not calling SetVirtualAddressMap() leads to actual issues _right > > now_, not in some hypothetical undefined future. > > That's the way you, Andrew, and others like to put it. My view at this > is that it's not the lack of the call, but the improper implementation > of firmware which leads to an apparent need for this call. Like for all > other firmware bug workarounds, I'm happy to accept any proposals for > workarounds, as long as such workarounds either don't impact spec- > compliant systems, or as long as they're off by default. But it sounds (reading though this thread) like it doesn't impact any spec-compliant systems -- that is, not any *known* ones, but only hypothetical dom0's which are neither Linux (including kexec) nor NetBSD nor FreeBSD. If we were Microsoft, we could afford to say "we don't support this hardware", and that would be enough to get the manufacturers to change their tune; but we're not. Making it difficult for our users will not fundamentally make vendors write better code. Particularly as my guess is that it's probably mainly a matter of testing: They only do testing on Windows (or maybe Linux if they're particularly keen), both of which seem to call SetVirtualAddressMap(); and so bits of the code accidentally come to rely on it being called. Sure, in a perfect world, developers would read the spec, automatically follow it, and test on all possible hardware; but given how software actually works, it seems inevitable that we're going to have a never-ending stream of bugs because we're behaving differently. So literally the only benefit of your policy is to accommodate hypothetical operating systems, who may need the functionality for unknown reasons. And the cost is to have vanilla Xen not work on loads of real systems. I don't think this is the right decision; and it seems like the sort of general higher-level principle that it would make sense to have a project-wide vote on if discussion failed to reach consensus. (Obviously if there are other technical issues, those would need to be addressed first.) Supposing such a hypothetical operating system appears, is there any reason we can't figure out how to provide it what it needs at that time? -George
On 10.03.2023 17:05, George Dunlap wrote: > On Fri, Feb 24, 2023 at 8:20 AM Jan Beulich <jbeulich@suse.com> wrote: >> On 23.02.2023 14:56, Marek Marczykowski-Górecki wrote: >>> Yet, not calling SetVirtualAddressMap() leads to actual issues _right >>> now_, not in some hypothetical undefined future. >> >> That's the way you, Andrew, and others like to put it. My view at this >> is that it's not the lack of the call, but the improper implementation >> of firmware which leads to an apparent need for this call. Like for all >> other firmware bug workarounds, I'm happy to accept any proposals for >> workarounds, as long as such workarounds either don't impact spec- >> compliant systems, or as long as they're off by default. > > > But it sounds (reading though this thread) like it doesn't impact any > spec-compliant systems -- that is, not any *known* ones, but only > hypothetical dom0's which are neither Linux (including kexec) nor NetBSD > nor FreeBSD. I can't say anything about the BSDs. Originally, when our EFI support was first implemented, kexec would have been affected from all I know. The way it works was changed meanwhile. As to "known" affected systems: Elsewhere on this thread I pointed out that I was happy that, at the time, I had an excuse not to worry about getting our use of SetVirtualAddressMap() correct. Properly establishing virtual addresses before making that call is still an open issue, for which I do not yet see a good solution. Marek saying "It works just fine" can only mean the limited set of systems that were tested. With more of physical address space populated, said problem would arise. Can I point at a particular system? No. But I do know that systems with "odd" memory maps exist (that's what e.g. our PDX abstraction was introduced for), and I anticipate problems there. An intermediate approach might be to call SetVirtualAddressMap() on systems where we can establish a complete virtual address map early enough. (Saying that without looking at the code, so this may not be viable in practice.) But I'm unsure this would improve the overall situation: We'd then test one thing on typical systems and would end up even less certain whether Xen also works on atypical ones. > If we were Microsoft, we could afford to say "we don't support this > hardware", and that would be enough to get the manufacturers to change > their tune; but we're not. Making it difficult for our users will not > fundamentally make vendors write better code. We can certainly agree on the goal of not making it more difficult than necessary for users. Provided reasonable command line option documentation, it shouldn't be overly difficult to establish which workarounds need enabling for a given platform. For known problematic ones we could even enable workarounds by default (just like we do in various cases when EFI does not come into play; most of that was inherited from Linux and hence is rather dated now, though). > Particularly as my guess is that it's probably mainly a matter of testing: > They only do testing on Windows (or maybe Linux if they're particularly > keen), both of which seem to call SetVirtualAddressMap(); and so bits of > the code accidentally come to rely on it being called. Sure, in a perfect > world, developers would read the spec, automatically follow it, and test on > all possible hardware; but given how software actually works, it seems > inevitable that we're going to have a never-ending stream of bugs because > we're behaving differently. > > So literally the only benefit of your policy is to accommodate hypothetical > operating systems, who may need the functionality for unknown reasons. And > the cost is to have vanilla Xen not work on loads of real systems. I don't > think this is the right decision; and it seems like the sort of general > higher-level principle that it would make sense to have a project-wide vote > on if discussion failed to reach consensus. Certainly. I'm pretty sure I would end up in a minority in such an event. Yet if we started to enable random firmware workarounds by default which can have an impact on spec-conforming systems, I guess I would have to seriously consider to step down as the maintainer of our EFI code. But maybe that's what's wanted by others anyway ... > (Obviously if there are other technical issues, those would need to be > addressed first.) > > Supposing such a hypothetical operating system appears, is there any reason > we can't figure out how to provide it what it needs at that time? Well - about everything can be done in software. The question is how much of the necessary road we've ended up closing by going the "account for quirks by default" route, and hence how complicated things would end up being. Jan
diff --git a/xen/common/Kconfig b/xen/common/Kconfig index f1ea3199c8ebdc1e9d0968b9de007f4df44bac79..5b8edb6d81a1296969f968702c5e7f2c775ceba9 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -215,14 +215,15 @@ config KEXEC If unsure, say Y. config EFI_SET_VIRTUAL_ADDRESS_MAP - bool "EFI: call SetVirtualAddressMap()" if EXPERT + bool "EFI: call SetVirtualAddressMap()" + default y ---help--- Call EFI SetVirtualAddressMap() runtime service to setup memory map for further runtime services. According to UEFI spec, it isn't strictly necessary, but many UEFI implementations misbehave when this call is missing. - If unsure, say N. + If unsure, say Y. config XENOPROF def_bool y