Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size

[Anthony Liguori]

"Daniel P. Berrange" <address@hidden> writes:

> On Mon, Aug 20, 2012 at 04:48:24PM -0500, Anthony Liguori wrote:
>> "Daniel P. Berrange" <address@hidden> writes:
>> 
>> > From: "Daniel P. Berrange" <address@hidden>
>> >
>> > Add a 'query-target' QAPI command to allow management applications
>> > to determine what target architecture a QEMU binary is emulating
>> > without having to parse the binary name or -help output
>> >
>> >   $ qmp-shell -p /tmp/qemu
>> >   (QEMU) query-target
>> >   {   u'return': {   u'arch': u'x86_64', u'bits': 64}}
>> 
>> "bits" is really ambiguous.  What it means in QEMU (specifically the
>> value you are returning) is probably not what you expect it to mean.
>
> My intent was to indicate the pointer word size for the architecture.
> eg 64 for x86_64, ppc64, etc, and 32 and i686, ppc, etc. Probably
> should have called it 'wordsize' or something like that

So this is physical address size which doesn't necessarily correspond to
whether you can run a "64-bit" OS or not.  As Peter mentioned, i386 can
have a larger physical address size even though it's limited to 32-bit
guests.

We really don't need to use a physical address size < 64-bit anymore.
It's just a matter of time before someone comes in and fixes
TARGET_PHYS_ADDR_BITS to 64 which ought to significantly reduce the
build time since we don't need to duplicate objects anymore.

So yeah, removing 'bits' is probably a good idea.

>   # virsh capabilities
>   ....snip...
>   <guest>
>     <os_type>hvm</os_type>
>     <arch name='arm'>
>       <wordsize>32</wordsize>
>       <emulator>/bin/qemu-system-arm</emulator>
>   ...
>
> Currently we just have a table of arch name -> wordsize mapping
> data in libvirt. I figured if I was adding a 'query-target' command
> to QEMU, we might as well include this info too. It is not critical
> though if you'd rather we omitted it though.

Does anyone actually use wordsize that libvirt reports?  What decisions
are made with that information?

I'd much rather QEMU provide this kind of information to libvirt but
understanding how it's used is important to figure out what to expose.

Regards,

Anthony Liguori

>
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|