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

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 08/03/13 12:21, Daniel Kiper wrote:
> On Fri, Mar 08, 2013 at 11:40:44AM +0000, David Vrabel wrote:
>> On 08/03/13 11:23, Daniel Kiper wrote:
>>> On Thu, Feb 21, 2013 at 05:48:11PM +0000, David Vrabel wrote:
>>>>
>>>> +        /* Need to switch to 32-bit mode? */
>>>> +        testq $KEXEC_RELOC_FLAG_COMPAT, %r8
>>>> +        jnz call_32_bit
>>>
>>> Why do you need that? This is not needed because purgatory code
>>> from kexec-tools always switches to 32-bit mode. Please check
>>> kexec-tools/purgatory/arch/x86_64/entry64.S.
>>
>> The sub-architecture is a property of the image.  Why should the tool
>> know or care about the sub-architecture of the hypervisor?
>>
>> The ABI isn't designed only for kexec-tools.
> 
> OK, but I think it is much easier to assume that machine state
> is not changed by kexec syscall/hypercall

What machine state is that?  The one seen by the tools or the guest
kernel or by the hypervisor?

The tools know what mode the image must be called it and it can tell the
hypervisor and the hypervisor can trivial setup the correct mode.

I propose:

* Tools say: "here's an image, call it in mode X".

You suggest:

* Hypervisor implicitly says through some unspecified side channel: "I
only call images in mode Y".
* Tools says: "here's an image. I set it up for mode Y. I hope that
works for you."

Finally, the v1 interface will call images loaded by a 32-bit dom0
kernel in 32-bit mode and we need to do continue to do the same.

> Additionally, you duplicate code which exists and works well.

It's only 17 instructions and 6 bytes of data.

David

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