[Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved load/unload ops

[Daniel Kiper]

On Mon, Mar 11, 2013 at 02:27:26PM +0000, Andrew Cooper wrote:
> On 11/03/13 14:13, Daniel Kiper wrote:
> > On Mon, Mar 11, 2013 at 01:43:02PM +0000, David Vrabel wrote:
> >> On 11/03/13 13:30, Daniel Kiper wrote:
> >>> On Mon, Mar 11, 2013 at 01:21:30PM +0000, David Vrabel wrote:
> >>>> On 11/03/13 11:17, Daniel Kiper wrote:
> >>>>> Heh... It looks that there is a misunderstanding. At first I thought
> >>>>> that David was going to replace purgatory functionality by switching
> >>>>> from 64-bit to 32-bit in kexec_reloc. But later I realized that
> >>>>> I missed Xen 64-bit/dom 32-bit case. Now I agree that this switch
> >>>>> must stay as is. However, now I think that there is another
> >>>>> small mistake which should be fixed. Please look above.
> >>>> Which mistake?  I'm not sure what you're referring to.
> >>> I thought about that:
> >>>
> >>> if ( image->arch == EM_386 )
> >>>   reloc_flags |= KEXEC_RELOC_FLAG_COMPAT;
> >>>
> >>> It should be change to:
> >>>
> >>> if ( is_pv_32on64_domain(dom0) )
> >>>   reloc_flags |= KEXEC_RELOC_FLAG_COMPAT;
> >> This isn't a mistake but a deliberate improvement to the old interface.
> > I am still not convinced.
> >
> >> It is clearer and more useful for this sub-architecture to be explicitly
> >> supplied in the kexec_load call than implicitly through some other
> >> side-channel.
> > First of all you do not need to pass any info about architecure to
> > new kernel or something like that (please check my previous emails).
>
> Yes - you really do.  Guessing the architecture of a blob of code is
> insane, and any current interface which relies on this guessing is
> broken by design.

Which interface do you mean? Old Xen? kexec-tools? purgatory?

Why do you need to enforce architecture? purgatory starts new kernel
image like BIOS does it. What is wrong with that? Do you set something
in BIOS to differentiate between 32-bit and 64-bit system?

> > If any then there is another questions. What do you do if you need
> > second or third argument?. You redefine kexec interface once again.
> > For what? Additionally, currently there are a lot of stuff passed
> > to new kernel via purgatory. And purgatory is called by your
> > interface too...
> >
> >> If we go with what you suggest then you prevent kexec from being used
> >> by: a) PVH dom0s; b) suitably privileged service domains; c) 32-bit
> > Maybe for PVH should be different check. However,
> > until now we do not have it in Xen yet.
> >
> >> guests wanting to load an image with a 64-bit entry point; and d)
> > Once again:
> >
> > old_kernel (Xen) -> purgatory (native mode) -> new_kernel
> >
> > purgatory architecture is same as kexec-tools architecture. If you
> > use dom0 i386 it means that kexec-tools is (and must be) i386 too.
> > We do not support Xen i386 anymore. It means that my condition is
> > correct.
> >
> > Daniel
>
> And what happens when kexec-tools is using ia32-libs under a 64bit dom0?
> That would also break.

Hmmm... Once I have done some tests with hypercalls called on 64-bit
system running 32-bit binaries. I was not able to run them properly.
Probably there is an issue with arguments. However, I have not time
to test it deeper. Please correct me if I am wrong. If I am wrong then
condition should be changed to something different. In this case your
and my proposal will be not correct for all cases for sure.

> The logic is very simple.
>
> If the blob passed in kexec_load claims to be 32bit, Xen will switch
> into 32bit mode before executing it.  If the blob claims to be 64 bit

Davids condition is wrong for Xen/dom0/binaries 64-bit case with 32-bit
kernel image. purgatory will crash or somthing like that because
it is 64-bit and it was called in 32-bit mode.

Daniel