[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7 3770
On Tue, Sep 4, 2012 at 10:09 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>> The big issue I'm having running xen is that I can't use it since xen can't >>>> get the cpu capabilities. >>> >>> What "cpu capabilities"? I just looked at your original mail again, >>> and I cannot see what failure you're referring to (in fact, I'm not >>> able to spot any failure in that log at all). And of course you didn't >>> even attach a hypervisor log. What am I missing? >> >> These are all the xen and virt-manager logs: >> >> http://dl.dropbox.com/u/12579112/hypervisor.log >> http://dl.dropbox.com/u/12579112/qemu-dm-Windows7.log >> http://dl.dropbox.com/u/12579112/virt-manager.log >> http://dl.dropbox.com/u/12579112/xen-hotplug.log >> http://dl.dropbox.com/u/12579112/xend.log >> http://dl.dropbox.com/u/12579112/xend-debug.log >> http://dl.dropbox.com/u/12579112/xenstored-trace.log.gz >> >> In the virt-manager logs you can see an instance of kvm and an instance of >> xen. >> See the difference in the cpu capabilities detected. > > Sorry, no, I can't. I don't see any trace of KVM in there. Also I > fail to see how this relates to the wording of the subject of > this thread. Hmmm, I just checked it again and certainly, it doesn't mention kvm, it just says qemu. From the virt-manager log, the kvm entry: [Thu, 30 Aug 2012 02:32:24 virt-manager 4483] DEBUG (connection:1239) qemu:///system capabilities: <capabilities> <host> <uuid>90022b03-3404-1305-6006-130700080009</uuid> <cpu> <arch>x86_64</arch> <model>Westmere</model> <vendor>Intel</vendor> <topology sockets='1' cores='4' threads='2'/> <feature name='rdtscp'/> <feature name='x2apic'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu> <power_management> <suspend_mem/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> </host> >From the same log, this time the xen entry: [Thu, 30 Aug 2012 02:32:24 virt-manager 4483] DEBUG (connection:1239) xen:/// capabilities: <capabilities> <host> <cpu> <arch>x86_64</arch> <features> <pae/> </features> </cpu> <power_management> <suspend_mem/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>xenmigr</uri_transport> </uri_transports> </migration_features> </host> >> As far as the hypervisor goes, the only error logged is: >> (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of >> mfn xxxxxx: c=c000000000000002 t=7400000000000001 > That doesn't look good, but I can't tell you much about it. I > wouldn't expect you to use shadow mode anyway on a Core-i7 - > are you intentionally turning off HAP for your guests? Nope, not intentionally. > Or is all of this thread really about virt-manager shortcomings > rather than problems in Xen (in which case you likely picked the > wrong mailing list)? Well, I wanted to check and compare xen to the other solutions I had used so far. I used virt-manager because it supports xen and I already used it. But the issue I had with the cpu not being detected leaves no trace of error anywhere, hence I didn't know what to check. If you believe this might be a virt-manager problem, not xen's, I will try creating a xmdomain.cfg by hand. -- Javier Marcet <jmarcet@xxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |