[Libvir] unsigned long
I just saw an email about unsigned long and max memory fly by along with a comment like "32-bit will never have more than 'X' Gb" ... This raises an obvious question: is libvirt explictly not 32/64 clean? On Solaris we build everything 32-bit by default unless there is a reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit kernel, then we have a problem. IMO an API should *always* use explicitly-sized integers when they contain range or size values (or use size_t etc.). Not doing so is both dangerous and confusing... (Xen does indeed have this problem, so we run all their tools with native word size. Currently we always use a 32-bit libvirt for 'virt-install', and it does seem to work fine. It would be a pity for this to change). cheers john
On Tue, Sep 11, 2007 at 05:49:08PM +0100, John Levon wrote:
I just saw an email about unsigned long and max memory fly by along with a comment like "32-bit will never have more than 'X' Gb" ...
This raises an obvious question: is libvirt explictly not 32/64 clean? On Solaris we build everything 32-bit by default unless there is a reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit kernel, then we have a problem.
Indeed. This scenario of 64-bit HV with 32-bit Dom0 userspace is entirely possible on Linux too. In PPC world its actually more efficient to use 32-bit userspace unless a particular app needs 64-bit memory addressing - most of the Fedora PPC rpms are 32-bit for this reason even on PPC64 platforms.
IMO an API should *always* use explicitly-sized integers when they contain range or size values (or use size_t etc.). Not doing so is both dangerous and confusing...
We've got an issue with some existing APIs using 'unsigned long' for memory values in KB. This may eventually force us to implement parallel APIs for these functions taking a 'long long'. We should not introduce any new APIs which are 'unsigned long' unless we know absolutely that 32-bits is enough even on a 64-bit system.
(Xen does indeed have this problem, so we run all their tools with native word size. Currently we always use a 32-bit libvirt for 'virt-install', and it does seem to work fine. It would be a pity for this to change).
We definitely need to support 32-bit tools on 64-bit HV Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Wed, Sep 12, 2007 at 03:08:32AM +0100, Daniel P. Berrange wrote:
We definitely need to support 32-bit tools on 64-bit HV
Thanks. Mark Johnson pointed out that we get away with a 32-bit virt-install right now simply because the hypercall libvirt backend fails, and falls back to calling into xend. In general this works well, but seems to have at least one issue that means we might need to create a 64-bit virt-{install,manager} ... regards john
On Wed, Sep 12, 2007 at 03:40:49AM +0100, John Levon wrote:
On Wed, Sep 12, 2007 at 03:08:32AM +0100, Daniel P. Berrange wrote:
We definitely need to support 32-bit tools on 64-bit HV
Thanks. Mark Johnson pointed out that we get away with a 32-bit virt-install right now simply because the hypercall libvirt backend fails, and falls back to calling into xend. In general this works well, but seems to have at least one issue that means we might need to create a 64-bit virt-{install,manager} ...
That's odd - to be able to run a 32-bit userspace on 64-bit HV you must be running a Xen 3.1 release or later. If using that, then libvirt should have automatically detected the hypervisor ABI which is 32/64 invariant. ie it ought to be working ! Your problem could be a compatability issue between the Solaris & Linux Xen ABIs which we're getting wrong. You really want to be letting libvirt use the HV because for calls such as listing guests, getting domain stats we get x100 to x1000 lower overheads from talking to the HV instead of XenD. Talking to XenD you'll quickly see XenD and XenStoreD start to take up considerable CPU time in Dom0 with even a few guests being monitored by virt-manager. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Wed, Sep 12, 2007 at 03:50:23AM +0100, Daniel P. Berrange wrote:
Thanks. Mark Johnson pointed out that we get away with a 32-bit virt-install right now simply because the hypercall libvirt backend fails, and falls back to calling into xend. In general this works well, but seems to have at least one issue that means we might need to create a 64-bit virt-{install,manager} ...
That's odd - to be able to run a 32-bit userspace on 64-bit HV you must be running a Xen 3.1 release or later. If using that, then libvirt should
We're using 3.0.4. I believe that virt-install is only using calls that can be supplied by the xend backend, so the fact that the hypercall backend doesn't work doesn't matter.
You really want to be letting libvirt use the HV because for calls such as listing guests, getting domain stats we get x100 to x1000 lower overheads from talking to the HV instead of XenD. Talking to XenD you'll quickly see
Right. A 3.1 upgrade is planned soon, and we'll probably just do this to resolve the issue. regards, john
On Tue, Sep 11, 2007 at 05:49:08PM +0100, John Levon wrote:
I just saw an email about unsigned long and max memory fly by along with a comment like "32-bit will never have more than 'X' Gb" ...
This raises an obvious question: is libvirt explictly not 32/64 clean? On Solaris we build everything 32-bit by default unless there is a reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit kernel, then we have a problem.
Okay, I didn't realize that. Could you check what part of the API which are currently a problem w.r.t. this ? It would be good to have a list, and okay we should use long long for the NUMA cell free query API... Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, Sep 12, 2007 at 02:20:21AM -0400, Daniel Veillard wrote:
I just saw an email about unsigned long and max memory fly by along with a comment like "32-bit will never have more than 'X' Gb" ...
This raises an obvious question: is libvirt explictly not 32/64 clean? On Solaris we build everything 32-bit by default unless there is a reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit kernel, then we have a problem.
Okay, I didn't realize that. Could you check what part of the API which are currently a problem w.r.t. this ? It would be good to have a list, and okay we should use long long for the NUMA cell free query API...
That's a good question. We should indeed do an audit so we can be aware of problems. Hopefully we'll find time to do a quick sweep as move up to more recent versions... regards john
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
John Levon