| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] bi-modal backends - fronend mode detection
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 04.11.06 08:51 >>>
>On 3/11/06 8:43 pm, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home