On Thu, Sep 28, 2006 at 05:22:08PM -0400, Daniel Veillard wrote: > On Thu, Sep 28, 2006 at 09:43:19PM +0100, Daniel P. Berrange wrote: > > On Thu, Sep 28, 2006 at 07:20:35PM +0100, Daniel P. Berrange wrote: > > > > > > Urm, but this has now broken things on 32-bit 3.0.3 based Xen HV. > > > > > > # virsh dominfo Domain-0 | grep CPU > > > CPU(s): 115 > > > > > > And also > > > > > > # virsh vcpuinfo Domain-0 > > > libvir: Xen error : failed Xen syscall ioctl 3166208 > > > > > > Looks like we need different versions of this struct depending on which > > > Xen we're working against. > > > > This is really quite a nasty problem, because the struct is passed into from > > numerous locations in the xen_internal.h code & I didn't want to cover the > > entire source with conditionals. > > > > So what I've done is declared a new xen_v2_domaininfo struct which is > > the same as xen_v0_domaininfo, but with Jim's patch reverted again. > > Then provide two unions > > Okay, I really expected they didn't broke that data structure too, > sigh ... Yeah go ahead that seems the less uglier possible ! Ok, I comitted this to CVS now. > I wonder why I didn't catch that, maybe my 3.0.3 test was done on an x86_64, Luck. On one of my 32-bit 3.0.3 boxes the 0.1.6 appeared to work fine for the basic operations - it was just giving bogus data (eg, 153 cpus). Depending on how many domains were running & what their data was things either silently worked (but bogus data), or completely crashed & burned. Anyway, I've now tested this on both versions of HV, and run through valgrind too as an extra sanity check. Lets just hope Xen doesn't break ABI yet again in the future.... 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 -=|