Re: [Xen-devel] [PATCHv9 0/9] Xen: extend kexec hypercall for use with pv-ops kernels

[Daniel Kiper <dkiper@xxxxxxxxxxxx>]

On Wed, Oct 09, 2013 at 05:03:22PM +0100, David Vrabel wrote:
> On 09/10/13 16:26, Daniel Kiper wrote:
> > On Tue, Oct 08, 2013 at 05:55:01PM +0100, David Vrabel wrote:
> >> The series (for Xen 4.4) improves the kexec hypercall by making
> >> Xen responsible for loading and relocating the image.  This allows
> >> kexec to be usable by pv-ops kernels and should allow kexec to be
> >> usable from a HVM or PVH privileged domain.
> >
> > As I can see you taken some sugestions into account. Thanks. But...
> > Why did not you send this patch series to kexec@xxxxxxxxxxxxxxxxxxx
> > and my Oracle address?
>
> I reckoned that the kexec list subscribers were sick of this Xen-only

I do not think so. I have not seen any complains.
Please send next version to kexec list too.

> series by now.  Omitting your Cc was accidental, sorry.

OK.

> > Why did not you implemented kexec hypercall function to get info about
> > loaded images?
>
> Because it is not needed.

OK.

> > 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?

> 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. However, why we do not
care about compatiblity with existing implementation? What is wrong with
that? We used it as a base for our development and we use a lot of code
existing in kexec-tools. Why we dropped these a few xors during our work?
What is wrong with known values here? 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?

> > 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. Anyway, I do not care about saving registers not
used later in relocate_pages() or around it. Additionally, relocate_pages()
is called only once and I do not expect that it will be moved somewhere else.
So I think that some of save and restore instructions are redundant.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel