[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv9 0/9] Xen: extend kexec hypercall for use with pv-ops kernels
On 10/10/13 16:45, Daniel Kiper wrote: > On Wed, Oct 09, 2013 at 05:03:22PM +0100, David Vrabel wrote: >> On 09/10/13 16:26, Daniel Kiper wrote: >>> >>> What about setting GPRs to known value (e.g. 0 like in Linux Kernel) >>> before jumping into purgatory? >> >> I have (repeatedly) explained why and you have not provided a sensible > > What do you mean by that? I have not seen any real explanation. > You were saying only that I am defining an ABI. I do not buy it. > Even you did not reply to my last question: Could you tell me > where do you see an ABI here? I'm going to comment on your points one final time. I am not going to debate with you any further on any of this. The register state on executing the image is undefined (this is the specified ABI), so there is no need to set the registers to any particular value. If the implementation did zero the registers then an image could rely on this. It would then be impossible to change the implementation to do anything other than zero the registers as that would break existing users. Zeroing the register is thus an implicit or defacto ABI (even though we specified the register values as undefined). If the registers are not zeroed then it is highly unlikely that an image could make use of their values and thus if we wish to change the specification to set some register values we can safely do so without breaking existing images. >> reason why they should be zeroed. > > OK, security reasons could be quite difficult to prove in that case and > some may say that they are only theoretical here. There is no security concern here. The image must be fully trusted by the host administrator since it has full access to all of the host's RAM and devices. If you're afraid an image might do something malicious then don't load that image. > However, why we do not care about compatiblity with existing implementation? Xen does diverge from ABI provided by Linux where it makes sense. i.e., where doing so makes for a better ABI or a better implementation. For example, 64-bit images are exec'd with page tables that only cover the image segments (unlike on Linux were the page tables cover all of RAM which has problems as noted by Jan with cachable mapping overlapping with uncachable regions). Compatibility with existing Linux tools is a nice bonus but should not and does not constrain the Xen ABI or implementation. > Are we going to write special purgatory > code for Xen if one day original purgatory require 0 or another known value > in one or more registers? If that happens we can always revist the Xen implementation and consider changing or (or just fix purgatory). >>> By the way, you do not need to save and restore %rdi, %rsi and %rbx >>> in relocate_pages() in xen/arch/x86/x86_64/kexec_reloc.S. >> >> This is done so relocate_pages() behaves like a proper function with the >> standard calling convention. > > If you would like to be inline with GCC (and a few others) calling convetion > then you should save %rbx in relocate_pages() only. %rcx, %rdi and %rsi should > be saved by caller if needed. Yes, I got that wrong, but you're really into trivial nit-picking here which is quite frankly neither helpful nor productive. > Anyway, I do not care about saving registers not > used later in relocate_pages() or around it. This is stupid -- relocate_pages() is called like a function so it should behave like one. Anything else is going to trip up someone else looking at or modifying the code in the future. David _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |