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@xxxxxxxxxx> 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 -=|