Xen devel - Nov 2006 - bi-modal backends - fronend mode detection

Does anyone have a good suggestion how to have the backends (for
which I just created bi-modal functionality, so they can [on x86 for
now] support both 32-bit and 64-bit domUs) learn the mode of the
connecting frontends.

(Backends using blkif and tpmif need this, pci and networking seem
to be unaffected.)

Thanks, Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Jan Beulich wrote:
> (Backends using blkif and tpmif need this, pci and networking seem
> to be unaffected.)
Just tested networking, works fine indeed.

cheers,
  Gerd

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 3/11/06 15:16, "Jan Beulich" <jbeulich@novell.com> wrote:
> Does anyone have a good suggestion how to have the backends (for
> which I just created bi-modal functionality, so they can [on x86 for
> now] support both 32-bit and 64-bit domUs) learn the mode of the
> connecting frontends.
> 
> (Backends using blkif and tpmif need this, pci and networking seem
> to be unaffected.)
Maybe using a new hypercall makes sense, to discover what Xen thinks is the
mode of VCPU0. We''ll need something similar for HVM guests in the long
term,
so making the decision at domain-build time doesn''t really work.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 3/11/06 8:43 pm, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk>
wrote:
>> Does anyone have a good suggestion how to have the backends (for
>> which I just created bi-modal functionality, so they can [on x86 for
>> now] support both 32-bit and 64-bit domUs) learn the mode of the
>> connecting frontends.
>> 
>> (Backends using blkif and tpmif need this, pci and networking seem
>> to be unaffected.)
> 
> Maybe using a new hypercall makes sense, to discover what Xen thinks is the
> mode of VCPU0. We''ll need something similar for HVM guests in the
long term,
> so making the decision at domain-build time doesn''t really work.
Actually this doesn''t necessarily work reliably. We don''t know
what mode the
HVM guest will happen to be running in when we query it via a hypercall. We
should add an address-bits field to the frontend device-info directory. This
can be filled in by frontend drivers, and also by the tools when creating PV
guests. In the absence of the address-bits field, backend can assume native
bit width or 32-bit width, whichever seems likely to work with most older
HVM clients.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 04.11.06 08:51
>>>
>On 3/11/06 8:43 pm, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk>
wrote:
>
>>> Does anyone have a good suggestion how to have the backends (for
>>> which I just created bi-modal functionality, so they can [on x86
for
>>> now] support both 32-bit and 64-bit domUs) learn the mode of the
>>> connecting frontends.
>>> 
>>> (Backends using blkif and tpmif need this, pci and networking seem
>>> to be unaffected.)
>> 
>> Maybe using a new hypercall makes sense, to discover what Xen thinks is
the
>> mode of VCPU0. We''ll need something similar for HVM guests in
the long term,
>> so making the decision at domain-build time doesn''t really
work.
>
>Actually this doesn''t necessarily work reliably. We don''t
know what mode the
>HVM guest will happen to be running in when we query it via a hypercall. We
>should add an address-bits field to the frontend device-info directory. This
>can be filled in by frontend drivers, and also by the tools when creating PV
>guests. In the absence of the address-bits field, backend can assume native
>bit width or 32-bit width, whichever seems likely to work with most older
>HVM clients.
Hmm, I specifically wanted to try to not touch the front ends at all, so that
to them the addition of the 32on64 capability is transparent (obviously, soon
we should want to support migrating a 32-bit domU between a pure 32-bit
setup and a mixed-mode one, which wouldn''t work for pre-existing domU-s
if they had to report extra info). At latest at the point where the front end
connects it should be possible to reliably determine the guest''s mode,
shouldn''t it? Or else, why would you think this is unreliable?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> Actually this doesn''t necessarily work reliably. We don''t
know what mode the
> HVM guest will happen to be running in when we query it via a hypercall. We
> should add an address-bits field to the frontend device-info directory.
This
> can be filled in by frontend drivers, and also by the tools when creating
PV
> guests. In the absence of the address-bits field, backend can assume native
> bit width or 32-bit width, whichever seems likely to work with most older
> HVM clients.
We have that issue for PV domains too (32-on-64 starts working now),
which is more problematic as we have both 32bit and 64bit distros in the
wild, which of course don''t add info to xenstore indicating the
protocol
variant.

For the pv-on-hvm case we maybe have the chance to fix it up in a sane
way before plenty of systems use it we do it quickly, for example by
requiring guests adding the info to the xenstore.  I''d go with some
"protocol" instead of "address bits" field, giving numbers
"1" and "2"
to the current 32bit and 64bit structs and leaving the door open to
introduce some new protocol "3" at some point in the future.

cheers,
  Gerd

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 6/11/06 08:30, "Jan Beulich" <jbeulich@novell.com> wrote:
> Hmm, I specifically wanted to try to not touch the front ends at all, so
that
> to them the addition of the 32on64 capability is transparent (obviously,
soon
> we should want to support migrating a 32-bit domU between a pure 32-bit
> setup and a mixed-mode one, which wouldn''t work for pre-existing
domU-s
> if they had to report extra info).
For PV guests the tool stack will always know the guest mode and can fill in
xenstore information automatically, both on initial build and on restore. So
it matters not a jot whether the frontends are modified in this case.

The only issue then is for PV-on-HVM drivers, and there''s simply not a
big
installed base of those yet. The creases are still being ironed out.
> At latest at the point where the front end
> connects it should be possible to reliably determine the guest''s
mode,
> shouldn''t it? Or else, why would you think this is unreliable?
What would you key off? EFER.LME? It would probably work okay, although
I''m
sure we could come up with theoretical situations where it wouldn''t,
but
most guests (including driver domains) are not privileged to obtain the
state of other guests. So this would require a skanky hypercall hack.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel