[PATCH,RFC 0/17] 32-on-64 work progress

[PATCH,RFC 0/17] 32-on-64 work progress

[Jan Beulich]

In an attempt to get some feedback on the ways I'm currently implementing
this, I'm sending the set of patches as I currently have them. These permit
a 32-bit PAE Linux dom0 kernel to come up on a 64-bit hypervisor, but
progress only goes this far currently (very early during invocation of the
first user mode code page table permissions aren't set correctly yet, making
Xen kill the guest).

Jan

Re: [PATCH,RFC 0/17] 32-on-64 work progress

[Gerd Hoffmann]

Jan Beulich wrote:
> In an attempt to get some feedback on the ways I'm currently implementing
> this, I'm sending the set of patches as I currently have them. These permit
> a 32-bit PAE Linux dom0 kernel to come up on a 64-bit hypervisor, but
> progress only goes this far currently (very early during invocation of the
> first user mode code page table permissions aren't set correctly yet, making
> Xen kill the guest).

Patches don't apply for me, which changeset these patches are based on?

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: [PATCH,RFC 0/17] 32-on-64 work progress

[Jan Beulich]

>>> Gerd Hoffmann <kraxel@suse.de> 05.10.06 11:41 >>>
>Jan Beulich wrote:
>> In an attempt to get some feedback on the ways I'm currently implementing
>> this, I'm sending the set of patches as I currently have them. These permit
>> a 32-bit PAE Linux dom0 kernel to come up on a 64-bit hypervisor, but
>> progress only goes this far currently (very early during invocation of the
>> first user mode code page table permissions aren't set correctly yet, making
>> Xen kill the guest).
>
>Patches don't apply for me, which changeset these patches are based on?

11690. They may depend on a few changes posted earlier (and not in the
tree, yet), and I also didn't specifically check whether they would conflict
with any of the few changes I always do right away after snapshotting
the tree. There shouldn't be many conflicts, though. I didn't do that
because the intention was mainly to have people look at the conceptual
aspects, since, as I pointed out, things don't fully work, yet (though for
the problem mentioned yesterday I already know the fix, I just wasn't
able to implement this so far as I was given a higher priority job for today).

Jan

Re: [PATCH,RFC 0/17] 32-on-64 work progress

[Gerd Hoffmann]

  Hi,

>>> In an attempt to get some feedback on the ways I'm currently implementing
>>> this, I'm sending the set of patches as I currently have them. These permit
>>> a 32-bit PAE Linux dom0 kernel to come up on a 64-bit hypervisor, but
>>> progress only goes this far currently (very early during invocation of the
>>> first user mode code page table permissions aren't set correctly yet, making
>>> Xen kill the guest).

Do you have any plans how domU bootup is going to work?  Especially how
hypercalls where one domain (typically dom0) changes the state of
another domain are supposed to work?  That includes the complete
XEN_DOMCTL_* family, also some memory management hypercalls such as
mach2phys and pagetable updates, maybe more.  These are used by the
domain tools to create a new domain and somehow must handle the case
that we want be able to build 32bit guest domains from a 64bit dom0 (and
visa versa?).

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: [PATCH,RFC 0/17] 32-on-64 work progress

[Keir Fraser]

On 11/10/06 10:11, "Gerd Hoffmann" <kraxel@suse.de> wrote:

>>>> In an attempt to get some feedback on the ways I'm currently implementing
>>>> this, I'm sending the set of patches as I currently have them. These permit
>>>> a 32-bit PAE Linux dom0 kernel to come up on a 64-bit hypervisor, but
>>>> progress only goes this far currently (very early during invocation of the
>>>> first user mode code page table permissions aren't set correctly yet,
>>>> making
>>>> Xen kill the guest).
> 
> Do you have any plans how domU bootup is going to work?  Especially how
> hypercalls where one domain (typically dom0) changes the state of
> another domain are supposed to work?  That includes the complete
> XEN_DOMCTL_* family, also some memory management hypercalls such as
> mach2phys and pagetable updates, maybe more.  These are used by the
> domain tools to create a new domain and somehow must handle the case
> that we want be able to build 32bit guest domains from a 64bit dom0 (and
> visa versa?).

The tools are going to have to know that they are building a 32p-on-64
guest. What problems do you perceive?

 -- Keir

Re: [PATCH,RFC 0/17] 32-on-64 work progress

[Gerd Hoffmann]

Keir Fraser wrote:
> On 11/10/06 10:11, "Gerd Hoffmann" <kraxel@suse.de> wrote:
> 
>> Do you have any plans how domU bootup is going to work?  Especially how
>> hypercalls where one domain (typically dom0) changes the state of
>> another domain are supposed to work?  That includes the complete
>> XEN_DOMCTL_* family, also some memory management hypercalls such as
>> mach2phys and pagetable updates, maybe more.  These are used by the
>> domain tools to create a new domain and somehow must handle the case
>> that we want be able to build 32bit guest domains from a 64bit dom0 (and
>> visa versa?).
> 
> The tools are going to have to know that they are building a 32p-on-64
> guest. What problems do you perceive?

Sure, they have to know.  Question is what do you pass in when changing
a 32bit guest from 64bit dom0.  The 32bit struct?  The 64bit struct?  I
think in many cases both will work just fine and we have just have to
pick one way.  XEN_DOMCTL_setvcpucontext is a icky one though, the 64bit
 struct isn't a superset of the 32bit struct, so we probably have to
pass the 32bit version for 32bit guests.

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: [PATCH,RFC 0/17] 32-on-64 work progress

[Keir Fraser]

On 11/10/06 11:16, "Gerd Hoffmann" <kraxel@suse.de> wrote:

> Sure, they have to know.  Question is what do you pass in when changing
> a 32bit guest from 64bit dom0.  The 32bit struct?  The 64bit struct?

In general, the 64b struct. ABI shims in Xen will be selected based on the
execution mode of the caller, not that subject domain (if there is one).

> think in many cases both will work just fine and we have just have to
> pick one way.  XEN_DOMCTL_setvcpucontext is a icky one though, the 64bit
>  struct isn't a superset of the 32bit struct, so we probably have to
> pass the 32bit version for 32bit guests.

In this case we extend the semantics of get/setvcpucontext to say that you
pass a pointer to a vcpu_context structure corresponding to the execution
mode of the subject.

 -- Keir

Re: [PATCH,RFC 0/17] 32-on-64 work progress

[Jan Beulich]

>>> Gerd Hoffmann <kraxel@suse.de> 10/11/06 11:11 AM >>>
>>>> In an attempt to get some feedback on the ways I'm currently implementing
>>>> this, I'm sending the set of patches as I currently have them. These permit
>>>> a 32-bit PAE Linux dom0 kernel to come up on a 64-bit hypervisor, but
>>>> progress only goes this far currently (very early during invocation of the
>>>> first user mode code page table permissions aren't set correctly yet, making
>>>> Xen kill the guest).
>
>Do you have any plans how domU bootup is going to work?  Especially how
>hypercalls where one domain (typically dom0) changes the state of
>another domain are supposed to work?  That includes the complete
>XEN_DOMCTL_* family, also some memory management hypercalls such as
>mach2phys and pagetable updates, maybe more.  These are used by the
>domain tools to create a new domain and somehow must handle the case
>that we want be able to build 32bit guest domains from a 64bit dom0 (and
>visa versa?).

I didn't spend thoughts on the tools side - Emmanuel was expected to
work from that side I think. surely what you say needs to be considered
(and for the part of those hypercalls already implemented should already be,
minus any bugs or oversights)

Jan

Re: [PATCH,RFC 0/17] 32-on-64 work progress

[Gerd Hoffmann]

  Hi,

> I didn't spend thoughts on the tools side - Emmanuel was expected to
> work from that side I think. surely what you say needs to be considered
> (and for the part of those hypercalls already implemented should already be,
> minus any bugs or oversights)

How do they work?  Using the native version of dom0 (as suggested by
Keir) for those hypercalls where it is possible?  How do you handle
setvcpucontest, where the 64bit struct isn't a superset of the 32bit
version?  I think for at least that one, maybe also others, we have to
pass compat structs through native hypercalls.  And maybe also visa
versa, so you can boot 64bit guests when running 32bit dom0 (within some
limits of course ...).

My current stack of patches (which also includes some other bits) is here:
http://www.suse.de/~kraxel/patches/kraxel-unstable-zweiblum-hg11751-quilt/

Alot of the domain builder code can handle non-native guests already,
the hypercalls which actually boot the domain are still missing though.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg