[Libvir] PATCH: support Xen 3.0.5

[Atsushi SAKAI]

Hi, Dan

Thank you for submitting patch!
I am eased to see this. Since I can test on current xen-unstable.
Anyway I will test on with this patch.

Thanks
Atsushi SAKAI

"Daniel P. Berrange" <berrange at redhat.com> wrote:

> I've been doing some testing with current xen-unstable (ie what will very
> shortly be 3.0.5) and came across a whole bunch of things which needed
> fixing - some expected, others not expected. The attached patch addresses
> the following issues:
> 
>   - Many of the hypercalls have their structs changed so that int64_t
>     or 'foo *' members are always 64-bit aligned even on 32-bit platforms.
>     This is part of the work to allow 32-bit Dom0/DomU to work on 64-bit
>     hypervisor. 
> 
>     For the int64_t types I had to annotate with __attribute__((aligned(8))).
>     This did not work for pointer data types, so I for those I had to do
>     a more complex hack with
> 
>         union {
>            foo *v;
>            int64_t pad __attribute__((aligned(8)))
>         }
> 
>     This matches what is done in the public (BSD licensed) Xen HV header
>     files.
> 
>     We already had ways to deal with v0  vs v2  hypercalls structs. This
>     change is still techincally v2, but just a minor revision of the
>     domctl or sysctl interfaces. Thus I have named the extra structs
>     v2d5 or v2s3  to indicated hypercall version 2, domctl version 5
>     or hypercall version 2, sysctl version 3 respectively.
> 
>   - The 'flags' field in the getdomaininfo hypercall now has an extra flag
>     defined '(1<<1)' which was previously not used, is now used to indicate
>     that the guest is HVM. Thus when fetching domain state, we have to mask
>     out that flag, otherwise we'll never match the correct paused/running/
>     blocked/etc states.
> 
>   - In the xenHypervisorNumOfDomains method, under certain scenarios we
>     will re-try the hypercall, allocating a bigger memory buffer. Well
>     due to the ABI alignment changes we hit that scenario everytime, and
>     ended up allocating a multi-GB buffer :-) The fixed structs sort this
>     out, but as a preventative measure for any future HV changes the patch
>     will break out of the loop at the 10,000 guest mark to avoid allocating
>     GB of memory.
> 
>   - The unified Xen driver broke the GetVCPUs method - it was mistakenly
>     checking for return value == 0, instead of > 0. Trivial fix.
>   
>   - The method to open the XenD connection was calling xenDaemonGetVersion
>     to test if the connection succeeded. But then also calling the
>     xend_detect_config_version which does pretty much same thing. So I
>     removed the former, and now we only do the latter as a 'ping' test 
>     when opening. This removes 1 HTTP GET which is worthwhile performance
>     boost given how horrifically slow XenD is.
> 
>   - The HVM SEXPR for configuring the VNC / SDL graphics is no longere
>     part of the (image) block. it now matches the PVFB graphics config
>     and is an explicit  (vfb)  block within the (devices) block.
>     So if xend_config_format >= 4 we use the new style config - this
>     is assuming upstream XenD is patched to increment xend_config_format
>     from 3 to 4 - I send a patch & am confident it will be applied
>     very shortly.
> 
>   - The QEMU device model allows a user to specify multiple devices
>     for the boot order, eg  'andc' to indicated 'floppy', 'network'
>     'cdrom', 'disk'. We assumed it was a single letter only. I now
>     serialize this into multiple <boot dev='XXX'/> elements, ordered
>     according to priority. The XML -> SEXPR conversion allows the
>     same.
> 
> 
> I've tested all this on a 32-bit Dom0 running on 32-bit HV, and 64-bit HV,
> but not tested a 64-bit Dom0 on 64-bit HV. I'm pretty sure it'll work,but
> if anyone is runnning 64-on-64 please test this patch.
> 
> Regards,
> 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  -=|