Re: [Qemu-devel] [PATCH] tcg: Remove stack protection from helper functions
Peter Maydell peter.mayd...@linaro.org writes: The answer is that the edge cases basically never match. No CPU architecture does handling of NaNs and input denormals and output denormals and underflow checks and all the rest of it in exactly the same way as anybody else. (In particular x86 is pretty crazy, Can you clarify this? IEEE754 is pretty strict on how all these things are handled and to my knowledge all serious x86 are fully IEEE compliant. Or are you refering to the x87 80bits expansion? While useful that's not used anymore with SSE. On the other hand qemu is not very good at it, e.g. with x87 it doesn't even pass paranoia. -Andi
Re: [Qemu-devel] [PATCH 5/8] tcg: Add interpreter for bytecode
I think it also improves branch target prediction - if you have a tight loop of a few opcodes the predictor can guess where you're headed (since there is a separate lookup key for each opcode), whereas with the original code, there's a single key which cannot be used to predict the branch target. At least usually. I caught at least one version of gcc to CSE the jump instruction into a common location in one of my interpreters :-( But not all do it at least, and I hope gcc gets fixed. It's still faster for other reasons usually. -Andi
Re: [Qemu-devel] [PATCH 5/8] tcg: Add interpreter for bytecode
You generally want CSE, yes? So you can't blame gcc for getting it wrong sometimes. There are cases where CSE pessimizes the code, .e.g when it increases memory pressure too much or caches something that is easier recomputed. This is just another one. BTW I checked again and the problem seems to be fixed in gcc 4.6, still there in 4.5, at least in my example. -Andi
Re: [Qemu-devel] [PATCH 5/8] tcg: Add interpreter for bytecode
Stefan Weil w...@mail.berlios.de writes:
+
+switch (opc) {
+case INDEX_op_end:
+case INDEX_op_nop:
+break;
You could probably get some more speed out of this by using a threaded
interpreter with gcc's computed goto extension. That's typically
significantly faster than a plain switch in a loop.
static void *ops[] = {
op1,
op2,
...
};
#define NEXT() goto *ops[*tb_ptr++];
op1:
...
NEXT();
-Andi
--
a...@linux.intel.com -- Speaking for myself only
Re: [Qemu-devel] IO errors in guest caused by LTP dio test
On Mon, Jun 27, 2011 at 05:59:41PM +0200, Kevin Wolf wrote: Am 23.06.2011 01:36, schrieb Andi Kleen: Running LTP testcases/kernel/io/direct_io/test_dma_thread_diotest7 causes IO errors in the guest. There are no IO errors on the host. Kernel Linux 3.0.0-rc* Using a standard emulated IDE -hda image. Couldn't reproduce this in a quick test with a random guest I had available. What is your complete qemu command line? Is the problem new -m 1500M -smp 2 \ -hda ~/qemu/suse-11.1-64.img\ -kernel arch/x86/boot/bzImage -append root=/dev/sda1 debug $EXTRA $@ Could it be related to the image? suse11.3-64.img: Qemu Image, Format: Qcow , Version: 1 , Disk Size could be: 83886080 * 256 bytes with the 3.0 RCs or does it also happen with kernels that my existing guests are likely to have in use - say, the F15 kernel? It happened on older kernels too. I guess with virtio-blk you don't see the problems? Will try later. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [Qemu-devel] [PATCH v4][ 5/7] guest agent: add guest agent RPCs/commands
Michael Roth mdr...@linux.vnet.ibm.com writes:
+
+int64_t qmp_guest_file_open(const char *filename, const char *mode, Error
**err)
+{
+FILE *fh;
+int fd, ret;
+int64_t id = -1;
+
+if (!logging_enabled()) {
+error_set(err, QERR_QGA_LOGGING_FAILED);
+goto out;
+}
+slog(guest-file-open called, filename: %s, mode: %s, filename, mode);
+fh = fopen(filename, mode);
+if (!fh) {
+error_set(err, QERR_OPEN_FILE_FAILED, filename);
+goto out;
+}
Does this really allow a guest to open any host file ?!?
Have you considered all the security implications of that?
-Andi
--
a...@linux.intel.com -- Speaking for myself only
Re: [Qemu-devel] qemu user x86 working?
On Sat, Feb 12, 2011 at 10:08:26AM +0200, Blue Swirl wrote: On Sat, Feb 12, 2011 at 12:27 AM, Andi Kleen a...@linux.intel.com wrote: I don't have any problems running a statically linked x86_64 helloworld program in an i386 chroot. Dynamically linked programs try to use wrong libraries, but at least running /lib64/ld-linux-x86-64.so.2 directly works. static binary segfaults too. I wonder if it's some setup on my system. I tried disabling the usual suspects like address randomization, but that didn't change things. Or could it be the compiler (gcc 4.5)? I don't think so, but that could be ruled out. What happens if you try to run some known ld-linux-x86-64.so.2? It seems to be something with the glibc on the fedora box. If I copy an static executable from a older suse it works on the fedora system. I ran into some issues replacing ld-linux though, so I didn't test the fedora gcc output with a different glibc. The last blocks of qemu.log produced by using -d in_asm,out_asm could reveal something, please try. Is that enough? Don't see anything obvious 0x0040008117e7: shr$0x3,%ecx 0x0040008117ea: test $0x4,%dl 0x0040008117ed: mov%ecx,%ecx 0x0040008117ef: rep stos %rax,%es:(%rdi) OUT: [size=184] 0x602104c0: mov0x10(%r14),%rbp 0x602104c4: mov%ebp,%ebp 0x602104c6: xor%ebx,%ebx 0x602104c8: mov%ebx,%ebx 0x602104ca: mov%ebp,%ebp 0x602104cc: shr$0x3,%rbp 0x602104d0: mov%ebp,%ebp 0x602104d2: mov0x10(%r14),%r12 0x602104d6: and$0x4,%r12d 0x602104da: mov%ebp,%ebp 0x602104dc: mov%rbp,%r13 0x602104df: mov$0x16,%r15d 0x602104e5: mov%r15d,0xa0(%r14) 0x602104ec: mov%r12,0x98(%r14) 0x602104f3: mov%rbx,(%r14) 0x602104f6: mov%rbp,0x8(%r14) 0x602104fa: test %r13,%r13 0x602104fd: jne0x60210528 0x60210503: jmpq 0x60210508 0x60210508: mov$0x40008117f2,%rbp 0x60210512: mov%rbp,0x80(%r14) 0x60210519: mov$0x7fe2d7c139e1,%rax 0x60210523: jmpq 0x622324ce 0x60210528: mov(%r14),%rbp 0x6021052b: mov0x38(%r14),%rbx 0x6021052f: mov%rbp,(%rbx) 0x60210532: movslq 0xa4(%r14),%rbp 0x60210539: shl$0x3,%rbp 0x6021053d: mov0x38(%r14),%rbx 0x60210541: add%rbp,%rbx 0x60210544: mov0x8(%r14),%rbp 0x60210548: dec%rbp 0x6021054b: mov%rbp,0x8(%r14) 0x6021054f: mov%rbx,0x38(%r14) 0x60210553: jmpq 0x60210558 0x60210558: mov$0x40008117ef,%rbp 0x60210562: mov%rbp,0x80(%r14) 0x60210569: mov$0x7fe2d7c139e0,%rax 0x60210573: jmpq 0x622324ce IN: 0x0040008117ef: rep stos %rax,%es:(%rdi) OUT: [size=130] 0x60210580: mov0x8(%r14),%rbp 0x60210584: test %rbp,%rbp 0x60210587: jne0x602105b2 0x6021058d: jmpq 0x60210592 0x60210592: mov$0x40008117f2,%rbp 0x6021059c: mov%rbp,0x80(%r14) 0x602105a3: mov$0x7fe2d7c13a59,%rax 0x602105ad: jmpq 0x622324ce 0x602105b2: mov(%r14),%rbp 0x602105b5: mov0x38(%r14),%rbx 0x602105b9: mov%rbp,(%rbx) 0x602105bc: movslq 0xa4(%r14),%rbp 0x602105c3: shl$0x3,%rbp 0x602105c7: mov0x38(%r14),%rbx 0x602105cb: add%rbp,%rbx 0x602105ce: mov0x8(%r14),%rbp 0x602105d2: dec%rbp 0x602105d5: mov%rbp,0x8(%r14) 0x602105d9: mov%rbx,0x38(%r14) 0x602105dd: jmpq 0x602105e2 0x602105e2: mov$0x40008117ef,%rbp 0x602105ec: mov%rbp,0x80(%r14) 0x602105f3: mov$0x7fe2d7c13a58,%rax 0x602105fd: jmpq 0x622324ce IN: 0x0040008117f2: jne0x4000811850 OUT: [size=104] 0x60210610: mov0xa0(%r14),%edi 0x60210617: callq 0x60095060 0x6021061c: mov%eax,%ebp 0x6021061e: shr$0x6,%rbp 0x60210622: and$0x1,%ebp 0x60210625: test %rbp,%rbp 0x60210628: je 0x60210653 0x6021062e: jmpq 0x60210633 0x60210633: mov$0x40008117f4,%rbp 0x6021063d: mov%rbp,0x80(%r14) 0x60210644: mov$0x7fe2d7c13ad0,%rax 0x6021064e: jmpq 0x622324ce 0x60210653: jmpq 0x60210658 0x60210658: mov$0x4000811850,%rbp 0x60210662: mov%rbp,0x80(%r14) 0x60210669: mov$0x7fe2d7c13ad1,%rax 0x60210673: jmpq 0x622324ce IN: 0x0040008117f4: test $0x2,%dl 0x0040008117f7: jne0x4000811838 OUT: [size=116] 0x60210680: mov0x10(%r14),%rbp 0x60210684: and$0x2,%ebp 0x60210687: mov%rbp,%rbx 0x6021068a: movzbl %bl,%ebx 0x6021068d: mov$0x16,%r12d 0x60210693: mov%r12d,0xa0(%r14) 0x6021069a: mov%rbp,0x98(%r14) 0x602106a1: test %rbx,%rbx 0x602106a4: jne0x602106cf 0x602106aa: jmpq 0x602106af 0x602106af: mov$0x40008117f9,%rbp 0x602106b9: mov%rbp,0x80(%r14) 0x602106c0: mov$0x7fe2d7c13b48,%rax 0x602106ca: jmpq 0x622324ce 0x602106cf: jmpq 0x602106d4 0x602106d4: mov$0x4000811838,%rbp 0x602106de: mov%rbp,0x80(%r14) 0x602106e5: mov$0x7fe2d7c13b49,%rax 0x602106ef: jmpq 0x622324ce IN: 0x0040008117f9: and$0x1,%edx 0x0040008117fc: jne0x4000811830
[Qemu-devel] qemu user x86 working?
Hi, Is the linux-user qemu for x86-64/i386 supposed to work? For example running it with a simple hello world on FC14 in gdb: /home/ak/tsrc/hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped [Thread debugging using libthread_db enabled] ERROR: ioctl(SNDCTL_DSP_MAPINBUF): target=0x80085013 host=0x80105013 ERROR: ioctl(SNDCTL_DSP_MAPOUTBUF): target=0x80085014 host=0x80105014 Program received signal SIGSEGV, Segmentation fault. 0x6021f854 in static_code_gen_buffer () (gdb) disp/3i $pc 1: x/3i $pc = 0x6021f854 static_code_gen_buffer+162660: mov(%rbx),%rbp 0x6021f857 static_code_gen_buffer+162663: mov0x28(%r14),%rbx 0x6021f85b static_code_gen_buffer+162667: add$0xff88,%rbx (gdb) p $rbx $2 = 0 I tested a few releases back, 0.13 and also 14-rc0 and they all segfault, although they are not all in the same place. The qemu-user shipped by Fedora also seems to have the same problem. Is this a known issue or am I doing something obviously wrong? Thanks, -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [Qemu-devel] qemu user x86 working?
I don't have any problems running a statically linked x86_64 helloworld program in an i386 chroot. Dynamically linked programs try to use wrong libraries, but at least running /lib64/ld-linux-x86-64.so.2 directly works. static binary segfaults too. I wonder if it's some setup on my system. I tried disabling the usual suspects like address randomization, but that didn't change things. Or could it be the compiler (gcc 4.5)? I remember using this quite some time ago (years). -Andi
[Qemu-devel] [PATCH] Don't declare XSAVE as supported
Don't declare XSAVE as supported
i386 cpuid.c currently claims XSAVE is supported in the CPUID filter,
but that's not true: Only FXSAVE is supported. Remove that bit
from the filter.
Signed-off-by: Andi Kleen a...@linux.intel.com
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 6a0f7ca..4251a29 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -241,11 +241,11 @@ typedef struct x86_def_t {
/* missing:
CPUID_VME, CPUID_DTS, CPUID_SS, CPUID_HT, CPUID_TM, CPUID_PBE */
#define TCG_EXT_FEATURES (CPUID_EXT_SSE3 | CPUID_EXT_MONITOR | \
- CPUID_EXT_CX16 | CPUID_EXT_POPCNT | CPUID_EXT_XSAVE | \
+ CPUID_EXT_CX16 | CPUID_EXT_POPCNT | \
CPUID_EXT_HYPERVISOR)
/* missing:
CPUID_EXT_DTES64, CPUID_EXT_DSCPL, CPUID_EXT_VMX, CPUID_EXT_EST,
- CPUID_EXT_TM2, CPUID_EXT_XTPR, CPUID_EXT_PDCM */
+ CPUID_EXT_TM2, CPUID_EXT_XTPR, CPUID_EXT_PDCM, CPUID_EXT_XSAVE */
#define TCG_EXT2_FEATURES ((TCG_FEATURES EXT2_FEATURE_MASK) | \
CPUID_EXT2_NX | CPUID_EXT2_MMXEXT | CPUID_EXT2_RDTSCP | \
CPUID_EXT2_3DNOW | CPUID_EXT2_3DNOWEXT)
[Qemu-devel] [PATCH] Add more boundary checking to sse3/4 parsing
Add more boundary checking to sse3/4 parsing
s?sse3 uses tables with only two entries per op, but it is indexed
with b1 which can contain variables upto 3. This happens when ssse3
or sse4 are used with REP* prefixes.
Add boundary checking for this case.
Signed-off-by: Andi Kleen a...@linux.intel.com
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 1336d6f..aae0374 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -3472,6 +3472,8 @@ static void gen_sse(DisasContext *s, int b, target_ulong
pc_start, int rex_r)
case 0x171: /* shift xmm, im */
case 0x172:
case 0x173:
+if (b1 = 2)
+ goto illegal_op;
val = ldub_code(s-pc++);
if (is_xmm) {
gen_op_movl_T0_im(val);
@@ -3699,6 +3701,8 @@ static void gen_sse(DisasContext *s, int b, target_ulong
pc_start, int rex_r)
rm = modrm 7;
reg = ((modrm 3) 7) | rex_r;
mod = (modrm 6) 3;
+if (b1 = 2)
+goto illegal_op;
sse_op2 = sse_op_table6[b].op[b1];
if (!sse_op2)
@@ -3798,6 +3802,8 @@ static void gen_sse(DisasContext *s, int b, target_ulong
pc_start, int rex_r)
rm = modrm 7;
reg = ((modrm 3) 7) | rex_r;
mod = (modrm 6) 3;
+if (b1 = 2)
+goto illegal_op;
sse_op2 = sse_op_table7[b].op[b1];
if (!sse_op2)
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Peter Lieven p...@dlh.net writes: Starting mail service (Postfix) NMI Watchdog detected LOCKUP on CPU 0 You could simply turn off the NMI watchdog (nmi_watchdog=0 at the kernel command line) Perhaps the PMU emulation is not complete and nmi watchdog needs PMU. It's not really needed normally. -Andi -- a...@linux.intel.com -- Speaking for myself only.
[Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Juan Quintela quint...@redhat.com writes: - networking: man, setting networking is a mess, libvirt just does it for you. Agreed it's messy, but isn't this something that the standard qemu command line tool could potentially do better by itself? I don't see why you need a wrapper for that. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [kvm-devel] [Qemu-devel] [PATCH 3/4] Add support for HPET periodic timer.
On Wed, Aug 22, 2007 at 10:03:32AM +0300, Avi Kivity wrote: Maybe the kernel is using the timer, so userspace can't. Just a guess. HPET has multiple timers (variable, but typically 2 or 4). The kernel only uses timer 0. It's possible someone else in user space is using it though. Try lsof /dev/hpet -Andi
Re: [kvm-devel] [Qemu-devel] [PATCH 3/4] Add support for HPET periodic timer.
$ dmesg |grep -i hpet ACPI: HPET 7D5B6AE0, 0038 (r1 A M I OEMHPET 5000708 MSFT 97) ACPI: HPET id: 0x8086a301 base: 0xfed0 hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 hpet0: 4 64-bit timers, 14318180 Hz hpet_resources: 0xfed0 is busy What kernel version was that? There was a bug that caused this pre .22 -Andi
