search for: __x86__

Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to

...e::getJITMatchQuality is the interesting point. I have noticed that all the points in the codebase that try to detect x86-64 are currently using the gcc-style "__x86_64__" preprocessor symbol. The Visual Studio compiler, instead, defines _M_X64 (similar to the _M_IX86 define that matches __x86__). Adding a defined(_M_X64) case to all the existing #ifdefs is no big deal, but I notice that two of them (one in X86JitInfo.cpp and one in X86Subtarget.cpp) are guarding inline assembly blocks written in the gcc-style inline assembly syntax. Would adding cases for these assembly blocks that are...

...%w0, %w0, #1\n" > +" stxr %w1, %w0, [%3]\n" > +" cbnz %w1, 1b" > + : "=&r" (result), "=&r" (tmp), "+o" (v) > + : "r" (v) > + : "cc"); > +} > + > #else /* __x86__ */ > static inline void atomic_inc(uint32_t *v) > { > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

...x(registers, value, subleaf); + *rEAX = registers[0]; + *rEBX = registers[1]; + *rECX = registers[2]; + *rEDX = registers[3]; + return false; + #else + return true; + #endif + #else + return true; + #endif +#elif defined(i386) || defined(__i386__) || defined(__x86__) || defined(_M_IX86) + #if defined(__GNUC__) + asm ("movl\t%%ebx, %%esi\n\t" + "cpuid\n\t" + "xchgl\t%%ebx, %%esi\n\t" + : "=a" (*rEAX), + "=S" (*rEBX), + "=c" (*rECX), + "=d&q...

I agree with Tim, you need to implement a GetCpuIDAndInfoEx function in Host.cpp and pass the correct value to ecx. Also you need to verify that 7 is a valid leaf because an invalid leaf is defined to return the highest supported leaf on that processor. So if a processor supports say leaf 6 and not leaf 7, then an access leaf 7 will return the data from leaf 6 causing unrelated bits to be

...DL_EXCLUDE_FREE +#define PAGES_PER_MAPWORD (sizeof(unsigned long) * 8) + +extern int +readpmem(struct DumpInfo *info, unsigned long long paddr, void *bufptr, size_t size); +extern int +readmem_xen(struct DumpInfo *info, unsigned long long vaddr, void *bufptr, + size_t size, char *errmsg); + +#ifdef __x86__ +#define HYPERVISOR_VIRT_START_PAE (0xF5800000UL) +#define HYPERVISOR_VIRT_START (0xFC000000UL) +#define HYPERVISOR_VIRT_END (0xFFFFFFFFUL) +#define DIRECTMAP_VIRT_START (0xFF000000UL) +#define DIRECTMAP_VIRT_END (0xFFC00000UL) + +#define is_xen_vaddr(x) \ + ((x) >= HYPERVISOR_VIRT_START_PAE...

The following patches shave some rough edges off the tools build system to allow cross compiling for at least arm32 and arm64 based on the Debian/Ubuntu multiarch infrastructure. They also add the necessary fixes to build for arm64 (which I have only tried cross, not native). I have posted some instructions on how to compile with these patches on the wiki:

Unlike full virtualization in which the virtual machine provides the same platform interface as running natively on the hardware, paravirtualization requires modification to the guest operating system to work with the platform interface provided by the hypervisor. Xen was designed with performance in mind. Calls to the hypervisor are minimized, batched if necessary, and non-critical codepaths

Unlike full virtualization in which the virtual machine provides the same platform interface as running natively on the hardware, paravirtualization requires modification to the guest operating system to work with the platform interface provided by the hypervisor. Xen was designed with performance in mind. Calls to the hypervisor are minimized, batched if necessary, and non-critical codepaths