[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.