search for: cpu_map

...on is not supported by the connection driver: cannot get node CPU data for ppc architecture Below is the output of important files.. cat /proc/cpuinfo processor : 0 cpu : e5500 clock : 1400.000000MHz revision : 2.1 (pvr 8024 1021) bogomips : 75.00 cat /usr/share/libvirt/cpu_map.xml <model name='POWERPC_e5500'> <vendor name='Freescale'/> <pvr value='0x80240000'/> </model> <model name='POWERPC_e6500'> <vendor name='Freescale'/> <pvr value='0x80400000'/&g...

Hi Andrea Thanks for the reply. Below is some more information regarding the same.. uname -a Linux t1040rdb 3.12.37-rt51-QorIQ-SDK-V1.8+gf488de6 #2 SMP Mon Jul 20 14:43:02 IST 2015 ppc GNU/Linux libvirtd --version libvirtd (libvirt) 1.2.13 cat /usr/share/libvirt/cpu_map.xml </arch> <arch name='ppc64'> <model name='POWERPC_e5500'> <vendor name='Freescale'/> <pvr value='0x80240000'/> </model> <model name='POWERPC_e6500'> <vendor name='Freescale...

...he obvious one would be: <cpu><model>cortex-a57</model></cpu> This passes `-cpu host' which is both wrong and likely to be a bug. I tried adding various flags and studying the source, but it's extremely non-obvious how to do this. Also adding the following into cpu_map.xml didn't make any difference: --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -626,6 +626,11 @@ <vendor name='IBM'/> <pvr value='0x004b0100'/> </model> + </arch> + <!-- ARM, 64 bit --> + <arch name='aarch64...

...efinitions you've sent (basically because I'm fairly > certain we have no such mistakes in our code O:-) ). > > But I did that now and indeed, you can see that the difference is only > in the "syscall" feature. You can do that yourselves using the info > from "cpu_map.xml" if you don't believe me ;) > > Martin Martin Many thanks for helping me get to the bottom of this, though could you clarify what you mean when you say that the difference is only in the "syscall" feature? I've looked at cpu_map.xml, and compared the features fo...

...many clients are using vaddr? */ + u32 use_cpt; + /* will point to the higher half of pages */ dma_addr_t *dma_addrs; /* array of base.mem->size pages (+ dma_addr_ts) */ @@ -109,8 +110,6 @@ struct gk20a_instmem { /* Only used by DMA API */ struct dma_attrs attrs; - - void __iomem * (*cpu_map)(struct nvkm_memory *); }; #define gk20a_instmem(p) container_of((p), struct gk20a_instmem, base) @@ -132,46 +131,19 @@ gk20a_instobj_size(struct nvkm_memory *memory) return (u64)gk20a_instobj(memory)->mem.size << 12; } -static void __iomem * -gk20a_instobj_cpu_map_dma(struct nvkm...

...t (basically because I'm fairly > > certain we have no such mistakes in our code O:-) ). > > > > But I did that now and indeed, you can see that the difference is only > > in the "syscall" feature. You can do that yourselves using the info > > from "cpu_map.xml" if you don't believe me ;) > > > > Martin > Martin > > Many thanks for helping me get to the bottom of this, though could you > clarify what you mean when you say that the difference is only in the > "syscall" feature? I've looked at cpu_map.xm...

...gt; Wheezy-i386. The results given by the Wheezy-i386 version seem very >>>>>> wrong (since n270 is an Atom processor). Apart from architecture, the >>>>>> package versions of libvirt-bin are identical: 1.2.1-1~bpo70+1. >>>>>> /usr/share/libvirt/cpu_map.xml files are identical. Is this a known >>>>>> issue? Details for one server are: >>>>>> >>>>>> # cat /proc/cpuinfo| head -n 26 >>>>>> processor : 0 >>>>>> vendor_id : GenuineIntel >>>&gt...

...t; + > /* will point to the higher half of pages */ > dma_addr_t *dma_addrs; > /* array of base.mem->size pages (+ dma_addr_ts) */ > @@ -109,8 +110,6 @@ struct gk20a_instmem { > > /* Only used by DMA API */ > struct dma_attrs attrs; > - > - void __iomem * (*cpu_map)(struct nvkm_memory *); > }; > #define gk20a_instmem(p) container_of((p), struct gk20a_instmem, base) > > @@ -132,46 +131,19 @@ gk20a_instobj_size(struct nvkm_memory *memory) > return (u64)gk20a_instobj(memory)->mem.size << 12; > } > > -static void __iomem...

...for ppc architecture > > > > Below is the output of important files.. > > cat /proc/cpuinfo > processor : 0 > cpu : e5500 > clock : 1400.000000MHz > revision : 2.1 (pvr 8024 1021) > bogomips : 75.00 > > > cat /usr/share/libvirt/cpu_map.xml > > <model name='POWERPC_e5500'> > <vendor name='Freescale'/> > <pvr value='0x80240000'/> > </model> > > <model name='POWERPC_e6500'> > <vendor name='Freescale'/> &gt...

...capabilities' reports the cpu differently on Debian Wheezy-amd64 and Wheezy-i386. The results given by the Wheezy-i386 version seem very wrong (since n270 is an Atom processor). Apart from architecture, the package versions of libvirt-bin are identical: 1.2.1-1~bpo70+1. /usr/share/libvirt/cpu_map.xml files are identical. Is this a known issue? Details for one server are: # cat /proc/cpuinfo| head -n 26 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2650L 0 @ 1.80GHz stepping : 7 microcode :...

...formation regarding the same.. > > > > uname -a > > Linux t1040rdb 3.12.37-rt51-QorIQ-SDK-V1.8+gf488de6 #2 SMP Mon Jul 20 > > 14:43:02 IST 2015 ppc GNU/Linux > > > > libvirtd --version > > libvirtd (libvirt) 1.2.13 > > > > cat /usr/share/libvirt/cpu_map.xml > > > > </arch> > > <arch name='ppc64'> > > <model name='POWERPC_e5500'> > > <vendor name='Freescale'/> > > <pvr value='0x80240000'/> > > </model> > > > &gt...

...de required features: invpcid, erms, bmi2, smep, avx2, bmi1, fsgsbase, movbe, fma Domain installation does not appear to have been successful. I could not resolve this error . Finally i came across the post which say that libvirt cross verifies flags under CPU model present in /usr/share/libvirt/cpu_map.xml and cat /proc/cpuinfo . An yes the flag complained were not present in host proc/cpuinfo. Question 1: Is it really needed for Libvirt to do this check . AS KVM seems to allow support Haswell with native commands . Why libvirt is doing this check then ? As i was not sure where the problem li...

...cpu differently on Debian Wheezy-amd64 and >> Wheezy-i386. The results given by the Wheezy-i386 version seem very >> wrong (since n270 is an Atom processor). Apart from architecture, the >> package versions of libvirt-bin are identical: 1.2.1-1~bpo70+1. >> /usr/share/libvirt/cpu_map.xml files are identical. Is this a known >> issue? Details for one server are: >> >> # cat /proc/cpuinfo| head -n 26 >> processor : 0 >> vendor_id : GenuineIntel >> cpu family : 6 >> model : 45 >> model name : Intel(R)...

...39; reports the cpu differently on Debian Wheezy-amd64 and > Wheezy-i386. The results given by the Wheezy-i386 version seem very > wrong (since n270 is an Atom processor). Apart from architecture, the > package versions of libvirt-bin are identical: 1.2.1-1~bpo70+1. > /usr/share/libvirt/cpu_map.xml files are identical. Is this a known > issue? Details for one server are: > > # cat /proc/cpuinfo| head -n 26 > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 45 > model name : Intel(R) Xeon(R) CPU E5-2650L 0 @ 1.80GHz...

...-amd64 and >>>> Wheezy-i386. The results given by the Wheezy-i386 version seem very >>>> wrong (since n270 is an Atom processor). Apart from architecture, the >>>> package versions of libvirt-bin are identical: 1.2.1-1~bpo70+1. >>>> /usr/share/libvirt/cpu_map.xml files are identical. Is this a known >>>> issue? Details for one server are: >>>> >>>> # cat /proc/cpuinfo| head -n 26 >>>> processor : 0 >>>> vendor_id : GenuineIntel >>>> cpu family : 6 >>>> m...

...r from lscpu output. + */ static void -ignore_errors (void *ignore, virErrorPtr ignore2) +get_vendor (char **lscpu, struct cpu_config *cpu) { - /* empty */ + const char *vendor = get_field (lscpu, "Vendor ID"); + + if (vendor) { + /* Note this mapping comes from /usr/share/libvirt/cpu_map.xml */ + if (STREQ (vendor, "GenuineIntel")) + cpu->vendor = strdup ("Intel"); + else if (STREQ (vendor, "AuthenticAMD")) + cpu->vendor = strdup ("AMD"); + /* Currently aarch64 lscpu has no Vendor ID XXX. */ + } } -static void lib...

...between the processor definitions you've sent (basically because I'm fairly certain we have no such mistakes in our code O:-) ). But I did that now and indeed, you can see that the difference is only in the "syscall" feature. You can do that yourselves using the info from "cpu_map.xml" if you don't believe me ;) Martin > Struan > > >>> Martin > >>> > >>>> Struan > >>>> > >>>> On 03/03/2014 10:00, Martin Kletzander wrote: > >>>>> On Fri, Feb 28, 2014 at 03:45:01PM +0000, St...

...ebian Wheezy-amd64 and > >> Wheezy-i386. The results given by the Wheezy-i386 version seem very > >> wrong (since n270 is an Atom processor). Apart from architecture, the > >> package versions of libvirt-bin are identical: 1.2.1-1~bpo70+1. > >> /usr/share/libvirt/cpu_map.xml files are identical. Is this a known > >> issue? Details for one server are: > >> > >> # cat /proc/cpuinfo| head -n 26 > >> processor : 0 > >> vendor_id : GenuineIntel > >> cpu family : 6 > >> model : 45 &...

...>>> Wheezy-i386. The results given by the Wheezy-i386 version seem very > >>>> wrong (since n270 is an Atom processor). Apart from architecture, the > >>>> package versions of libvirt-bin are identical: 1.2.1-1~bpo70+1. > >>>> /usr/share/libvirt/cpu_map.xml files are identical. Is this a known > >>>> issue? Details for one server are: > >>>> > >>>> # cat /proc/cpuinfo| head -n 26 > >>>> processor : 0 > >>>> vendor_id : GenuineIntel > >>>> cpu fami...

...for the reply. > Below is some more information regarding the same.. > > uname -a > Linux t1040rdb 3.12.37-rt51-QorIQ-SDK-V1.8+gf488de6 #2 SMP Mon Jul 20 > 14:43:02 IST 2015 ppc GNU/Linux > > libvirtd --version > libvirtd (libvirt) 1.2.13 > > cat /usr/share/libvirt/cpu_map.xml > > </arch> > <arch name='ppc64'> > <model name='POWERPC_e5500'> > <vendor name='Freescale'/> > <pvr value='0x80240000'/> > </model> > > <model name='POWERPC_e6500'...