Re: [Qemu-devel] [PATCH] MIPS interrupts and -icount
On Sun, Jul 25, 2010 at 07:52:18AM +0200, Edgar E. Iglesias wrote:
On Sun, Jul 25, 2010 at 06:44:41AM +0200, Aurelien Jarno wrote:
On Sun, Jul 25, 2010 at 05:08:07AM +0200, Aurelien Jarno wrote:
On Sun, Jul 25, 2010 at 02:07:54AM +0200, Edgar E. Iglesias wrote:
On Sun, Jul 25, 2010 at 12:55:45AM +0200, Aurelien Jarno wrote:
On Thu, Jul 22, 2010 at 01:32:18PM +0200, Edgar E. Iglesias wrote:
Hi,
I'm seeing an error when emulating MIPS guests with -icount.
In cpu_interrupt:
cpu_abort(env, Raised interrupt while not in I/O function);
I am not able to reproduce the issue. Do you have more details how to
reproduce the problem?
You need a machine with devices that raise the hw interrupts. I didn't
see the error on the images on the wiki though. But I've got a machine
here that trigs it easily. Will check if I can publish it and an image.
That would be nice if you can share it.
It seems to me like the MIPS interrupt glue logic between interrupt
controllers and the MIPS core is not modeled correctly.
It seems indeed that sometimes interrupt are triggered while not in
I/O functions, your patch addresses part of the problem.
When hw interrupt pending bits in CP0_Cause are set, the CPU should
see the hw interrupt line as active. The CPU may or may not take the
interrupt based on internal state (global irq mask etc) but the glue
logic shouldn't care about that. Am I missing something here?
I don't think it is correct. On the real hardware, the interrupt line
is
actually active only when all conditions are fulfilled.
The thing to remember is that the interrupts are level triggered. So
if
an interrupt is masked, it should be rejected by the CPU, but could be
triggered again as soon as the interrupt mask is changed.
Agreed, that behaviour is what I'm trying to acheive. The problem now
is that the the level triggered line, prior to CPU masking is beeing
masked
by external logic. IMO it shouldnt. See hw/mips_int.c and cpu-exec.c
prior
to the patch.
Actually all depends if you consider the MIPS interrupt controller part
of the CPU or not. It could be entirely modeled in the CPU, that is in
cpu-exec.c or entirely modeled as a separate controller, that is in
mips_int.c.
If we choose having the interrupt controller as part of the CPU, which
seems to be what you have chosen, the following patch should fix the
remaining issues (and prepare the work for vector interrupt support):
Thanks,
That looks nice, specially the removing of the helper_interrupt_restart
parts :)
I'll test it on my side and send you an ACK.
I've tested this with the same images as before, they still work.
I also created a synthetic testcase for the 2 software interrupt
lines and they seem to behave OK. Our linux port was not so
happy about seeing those raised though, so I had to hack a bit
to see them in action :)
Acked-by: Edgar E. Iglesias ed...@axis.com
Tested-by: Edgar E. Iglesias ed...@axis.com
Would you mind applying your patch on top of mine?
Thanks alot,
Edgar
Thanks for your patience Aurelien,
Edgar
diff --git a/hw/mips_int.c b/hw/mips_int.c
index 80488ba..477f6ab 100644
--- a/hw/mips_int.c
+++ b/hw/mips_int.c
@@ -54,3 +54,12 @@ void cpu_mips_irq_init_cpu(CPUState *env)
env-irq[i] = qi[i];
}
}
+
+void cpu_mips_soft_irq(CPUState *env, int irq, int level)
+{
+if (irq 0 || irq 2) {
+return;
+}
+
+qemu_set_irq(env-irq[irq], level);
+}
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 1578850..b8e6fee 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -597,6 +597,9 @@ void cpu_mips_store_compare (CPUState *env, uint32_t
value);
void cpu_mips_start_count(CPUState *env);
void cpu_mips_stop_count(CPUState *env);
+/* mips_int.c */
+void cpu_mips_soft_irq(CPUState *env, int irq, int level);
+
/* helper.c */
int cpu_mips_handle_mmu_fault (CPUState *env, target_ulong address, int rw,
int mmu_idx, int is_softmmu);
diff --git a/target-mips/helper.h b/target-mips/helper.h
index a6ba75d..cb13fb2 100644
--- a/target-mips/helper.h
+++ b/target-mips/helper.h
@@ -2,7 +2,6 @@
DEF_HELPER_2(raise_exception_err, void, i32, int)
DEF_HELPER_1(raise_exception, void, i32)
-DEF_HELPER_0(interrupt_restart, void)
#ifdef TARGET_MIPS64
DEF_HELPER_3(ldl, tl, tl, tl, int)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index c963224..8482e69 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -46,18 +46,6 @@ void helper_raise_exception (uint32_t exception)
helper_raise_exception_err(exception, 0);
}
-void helper_interrupt_restart (void)
-{
-if
[Qemu-devel] [Bug 587993] Re: qemu-kvm 0.12.4+dfsg-1 from debian squeeze crashes BUG: unable to handle kernel NULL pointer (sym53c8xx)
** Description changed: I use eucalyptus software (1.6.2) on debian squeeze with kvm 0.12.4+dfsg-1 (the same happend with 0.11.1+dfsg-1 ). Kernel 2.6.32-3-amd64. After a few days machines crash. There are no logs in host system. Guest is the same kernel and OS as host. The kvm process use 100% of cpu time. I can not even ping the guest. Everything works - fine with 2.6.30-2-amd64, 2.6.32-trunk-amd64 and 2.6.32-5-amd64. The - problem is only with 2.6.32-3-amd64. Here is the log from virtual + fine with 2.6.30-2-amd64 and 2.6.32-trunk-amd64. The problem is only + with 2.6.32-3-amd64 and 2.6.32-5-amd64. Here is the log from virtual machine: [ 3577.81] sd 0:0:0:0: [sda] ABORT operation started [ 3582.816047] sd 0:0:0:0: ABORT operation timed-out. [ 3582.816781] sd 0:0:0:0: [sda] ABORT operation started [ 3587.816649] sd 0:0:0:0: ABORT operation timed-out. [ 3587.817379] sd 0:0:0:0: [sda] DEVICE RESET operation started [ 3592.816062] sd 0:0:0:0: DEVICE RESET operation timed-out. [ 3592.816882] sd 0:0:0:0: [sda] BUS RESET operation started [ 3592.820056] sym0: SCSI BUS reset detected. [ 3592.831538] sym0: SCSI BUS has been reset. [ 3592.831968] BUG: unable to handle kernel NULL pointer dereference at 0358 [ 3592.832003] IP: [a01147c4] sym_int_sir+0x62f/0x14e0 [sym53c8xx] [ 3592.832003] PGD 5f73e067 PUD 5fa53067 PMD 0 [ 3592.832003] Oops: [#1] SMP [ 3592.832003] last sysfs file: /sys/devices/pci:00/:00:05.0/host0/target0:0:0/0:0:0:0/vendor [ 3592.832003] CPU 0 [ 3592.832003] Modules linked in: dm_mod openafs(P) ext2 snd_pcsp snd_pcm snd_timer serio_raw i2c_piix4 snd virtio_balloon evdev i2c_core soundcore psmouse button processor snd_page_alloc ext3 jbd mbcache sd_mod crc_t10dif ata_generic libata ide_pci_generic sym53c8xx scsi_transport_spi thermal piix uhci_hcd ehci_hcd floppy thermal_sys scsi_mod virtio_pci virtio_ring virtio e1000 ide_core usbcore nls_base [last unloaded: scsi_wait_scan] [ 3592.832003] Pid: 193, comm: scsi_eh_0 Tainted: P 2.6.32-3-amd64 #1 Bochs [ 3592.832003] RIP: 0010:[a01147c4] [a01147c4] sym_int_sir+0x62f/0x14e0 [sym53c8xx] [ 3592.832003] RSP: 0018:880001803cb0 EFLAGS: 00010287 [ 3592.832003] RAX: 000a RBX: 000b RCX: 5f410090 [ 3592.832003] RDX: RSI: 88005c450800 RDI: c9a5e006 [ 3592.832003] RBP: 88005f41 R08: R09: [ 3592.832003] R10: 003a R11: 813b871e R12: 88005f410090 [ 3592.832003] R13: 0084 R14: R15: 0001 [ 3592.832003] FS: () GS:88000180() knlGS: [ 3592.832003] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [ 3592.832003] CR2: 0358 CR3: 5e269000 CR4: 06f0 [ 3592.832003] DR0: DR1: DR2: [ 3592.832003] DR3: DR6: 0ff0 DR7: 0400 [ 3592.832003] Process scsi_eh_0 (pid: 193, threadinfo 88005f6fa000, task 88005f697880) [ 3592.832003] Stack: [ 3592.832003] 88005f3fd000 0130 [ 3592.832003] 0 88005f407710 c9a64710 ff10 81195301 [ 3592.832003] 0 0010 00010212 880001803d18 0018 [ 3592.832003] Call Trace: [ 3592.832003] IRQ [ 3592.832003] [81195301] ? __memcpy_toio+0x9/0x19 [ 3592.832003] [a01164ed] ? sym_interrupt+0x46c/0x6a3 [sym53c8xx] [ 3592.832003] [8103fea0] ? update_curr+0xa6/0x147 [ 3592.832003] [a010fbde] ? sym53c8xx_intr+0x43/0x6a [sym53c8xx] [ 3592.832003] [81093bfc] ? handle_IRQ_event+0x58/0x126 [ 3592.832003] [810954e2] ? handle_fasteoi_irq+0x7d/0xb5 [ 3592.832003] [81013957] ? handle_irq+0x17/0x1d [ 3592.832003] [81012fb1] ? do_IRQ+0x57/0xb6 [ 3592.832003] [810114d3] ? ret_from_intr+0x0/0x11 [ 3592.832003] [81053903] ? __do_softirq+0x6e/0x19f [ 3592.832003] [8106fa87] ? tick_dev_program_event+0x2d/0x95 [ 3592.832003] [81011cac] ? call_softirq+0x1c/0x30 [ 3592.832003] [81013903] ? do_softirq+0x3f/0x7c [ 3592.832003] [810537e1] ? irq_exit+0x36/0x76 [ 3592.832003] [81025837] ? smp_apic_timer_interrupt+0x87/0x95 [ 3592.832003] [81011673] ? apic_timer_interrupt+0x13/0x20 [ 3592.832003] EOI [ 3592.832003] [8118e009] ? delay_tsc+0x0/0x73 [ 3592.832003] [a010f900] ? sym_eh_handler+0x22e/0x2e2 [sym53c8xx] [ 3592.832003] [a008e5de] ? scsi_try_bus_reset+0x50/0xd9 [scsi_mod] [ 3592.832003] [a008f565] ? scsi_eh_ready_devs+0x50c/0x781 [scsi_mod] [ 3592.832003] [a008fd6b] ? scsi_error_handler+0x3c1/0x5b5 [scsi_mod] [
[Qemu-devel] Old DGUX Machine and Adaptec SCSI PCI Controller
Hello all, We have an old DG/UX machine (2 actually), in production use (scary, I know). These days I am trying to virtualize/emulate those machines. As we cannot upgrade / reinstall the applications on a different platfrom, I am trying to boot it up (DD'ed all the drives as images) and use it as is. Attempts with Qemu are going O.K for now, got the bootloader working, but it doesn't load up the kernel/sytem, probably because it excpects the original Adaptec SCSI PCI Controller of the disks. Currently, these DGUX machines only support Qlogic and Adaptec, no IDE whatsoever and no LSI. Any way Qemu will support anything like that? I got to know these DGUX machines very well, and know all the logs locations and sys/hw info. If you need anything, including system/boot image, let me know. Thanks a lot for reading, Adam
Re: [Qemu-devel] [PATCH] MIPS interrupts and -icount
On Sun, Jul 25, 2010 at 09:21:48AM +0200, Edgar E. Iglesias wrote: On Sun, Jul 25, 2010 at 07:52:18AM +0200, Edgar E. Iglesias wrote: On Sun, Jul 25, 2010 at 06:44:41AM +0200, Aurelien Jarno wrote: On Sun, Jul 25, 2010 at 05:08:07AM +0200, Aurelien Jarno wrote: On Sun, Jul 25, 2010 at 02:07:54AM +0200, Edgar E. Iglesias wrote: On Sun, Jul 25, 2010 at 12:55:45AM +0200, Aurelien Jarno wrote: On Thu, Jul 22, 2010 at 01:32:18PM +0200, Edgar E. Iglesias wrote: Hi, I'm seeing an error when emulating MIPS guests with -icount. In cpu_interrupt: cpu_abort(env, Raised interrupt while not in I/O function); I am not able to reproduce the issue. Do you have more details how to reproduce the problem? You need a machine with devices that raise the hw interrupts. I didn't see the error on the images on the wiki though. But I've got a machine here that trigs it easily. Will check if I can publish it and an image. That would be nice if you can share it. It seems to me like the MIPS interrupt glue logic between interrupt controllers and the MIPS core is not modeled correctly. It seems indeed that sometimes interrupt are triggered while not in I/O functions, your patch addresses part of the problem. When hw interrupt pending bits in CP0_Cause are set, the CPU should see the hw interrupt line as active. The CPU may or may not take the interrupt based on internal state (global irq mask etc) but the glue logic shouldn't care about that. Am I missing something here? I don't think it is correct. On the real hardware, the interrupt line is actually active only when all conditions are fulfilled. The thing to remember is that the interrupts are level triggered. So if an interrupt is masked, it should be rejected by the CPU, but could be triggered again as soon as the interrupt mask is changed. Agreed, that behaviour is what I'm trying to acheive. The problem now is that the the level triggered line, prior to CPU masking is beeing masked by external logic. IMO it shouldnt. See hw/mips_int.c and cpu-exec.c prior to the patch. Actually all depends if you consider the MIPS interrupt controller part of the CPU or not. It could be entirely modeled in the CPU, that is in cpu-exec.c or entirely modeled as a separate controller, that is in mips_int.c. If we choose having the interrupt controller as part of the CPU, which seems to be what you have chosen, the following patch should fix the remaining issues (and prepare the work for vector interrupt support): Thanks, That looks nice, specially the removing of the helper_interrupt_restart parts :) I'll test it on my side and send you an ACK. I've tested this with the same images as before, they still work. I also created a synthetic testcase for the 2 software interrupt lines and they seem to behave OK. Our linux port was not so happy about seeing those raised though, so I had to hack a bit to see them in action :) Acked-by: Edgar E. Iglesias ed...@axis.com Tested-by: Edgar E. Iglesias ed...@axis.com Would you mind applying your patch on top of mine? Thanks for the tests, I have just applied it. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 0/4] Replace u_int8_t, u_int16_t, u_int32_t, u_int64_t by standard int types
On Thu, Jul 22, 2010 at 10:15:20PM +0200, Stefan Weil wrote: There is no need to have a second set of integral types. Replace them by the standard types from stdint.h. [PATCH 1/4] block: Replace u_int8_t, u_int16_t, u_int32_t, u_int64_t by standard int types [PATCH 2/4] tests: Replace u_int8_t, u_int16_t, u_int32_t, u_int64_t by standard int types [PATCH 3/4] slirp: Replace u_int8_t, u_int16_t, u_int32_t, u_int64_t by standard int types [PATCH 4/4] slirp: Remove declarations which are no longer needed Thanks, all applied. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [patch] add cscope.* to .gitignore
On Fri, Jul 23, 2010 at 02:59:52PM +0900, Jun Koi wrote: we have make cscope, therefore that makes sense to have cscope.* in .gitignore. Signed-off-by: Jun Koi junkoi2...@gmail.com Thanks, applied. diff --git a/.gitignore b/.gitignore index a32b7c4..ec6f89f 100644 --- a/.gitignore +++ b/.gitignore @@ -53,3 +53,4 @@ pc-bios/optionrom/linuxboot.bin pc-bios/optionrom/multiboot.bin pc-bios/optionrom/multiboot.raw .stgit-* +cscope.* -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH] Close socket file descriptor when qemu_accept fails
On Sat, Jul 24, 2010 at 01:03:07PM +0300, Shahar Havivi wrote:
Signed-off-by: Shahar Havivi shah...@redhat.com
---
migration-tcp.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
Thanks, applied.
diff --git a/migration-tcp.c b/migration-tcp.c
index 78b56dc..b55f419 100644
--- a/migration-tcp.c
+++ b/migration-tcp.c
@@ -151,7 +151,7 @@ static void tcp_accept_incoming_migration(void *opaque)
if (c == -1) {
fprintf(stderr, could not accept migration connection\n);
-return;
+goto out2;
}
f = qemu_fopen_socket(c);
@@ -163,9 +163,10 @@ static void tcp_accept_incoming_migration(void *opaque)
process_incoming_migration(f);
qemu_fclose(f);
out:
+close(c);
+out2:
qemu_set_fd_handler2(s, NULL, NULL, NULL, NULL);
close(s);
-close(c);
}
int tcp_start_incoming_migration(const char *host_port)
--
1.7.1.1
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [patch] use gen_update_cc_op()
On Sun, Jul 25, 2010 at 12:30:03PM +0900, Jun Koi wrote:
this patch simplifies target-i386/translate.c a bit by replacing some
code with gen_update_cc_op()
Signed-off-by: Jun Koi junkoi2...@gmail.com
Thanks, applied.
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 9543298..7b6e3c2 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -2310,10 +2310,7 @@ static inline void gen_jcc(DisasContext *s, int b,
int l1, l2, cc_op;
cc_op = s-cc_op;
-if (s-cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s-cc_op);
-s-cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
if (s-jmp_opt) {
l1 = gen_new_label();
gen_jcc1(s, cc_op, b, l1);
@@ -2724,10 +2721,7 @@ static void gen_eob(DisasContext *s)
static void gen_jmp_tb(DisasContext *s, target_ulong eip, int tb_num)
{
if (s-jmp_opt) {
-if (s-cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s-cc_op);
-s-cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_goto_tb(s, tb_num, eip);
s-is_jmp = DISAS_TB_JUMP;
} else {
@@ -6901,10 +6895,7 @@ static target_ulong disas_insn(DisasContext *s,
target_ulong pc_start)
if (!s-pe) {
gen_exception(s, EXCP0D_GPF, pc_start - s-cs_base);
} else {
-if (s-cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s-cc_op);
-s-cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(pc_start - s-cs_base);
gen_helper_sysenter();
gen_eob(s);
@@ -6917,10 +6908,7 @@ static target_ulong disas_insn(DisasContext *s,
target_ulong pc_start)
if (!s-pe) {
gen_exception(s, EXCP0D_GPF, pc_start - s-cs_base);
} else {
-if (s-cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s-cc_op);
-s-cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(pc_start - s-cs_base);
gen_helper_sysexit(tcg_const_i32(dflag));
gen_eob(s);
@@ -6929,10 +6917,7 @@ static target_ulong disas_insn(DisasContext *s,
target_ulong pc_start)
#ifdef TARGET_X86_64
case 0x105: /* syscall */
/* XXX: is it usable in real mode ? */
-if (s-cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s-cc_op);
-s-cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(pc_start - s-cs_base);
gen_helper_syscall(tcg_const_i32(s-pc - pc_start));
gen_eob(s);
@@ -6941,10 +6926,7 @@ static target_ulong disas_insn(DisasContext *s,
target_ulong pc_start)
if (!s-pe) {
gen_exception(s, EXCP0D_GPF, pc_start - s-cs_base);
} else {
-if (s-cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s-cc_op);
-s-cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(pc_start - s-cs_base);
gen_helper_sysret(tcg_const_i32(s-dflag));
/* condition codes are modified only in long mode */
@@ -7085,10 +7067,7 @@ static target_ulong disas_insn(DisasContext *s,
target_ulong pc_start)
if (!(s-cpuid_ext_features CPUID_EXT_MONITOR) ||
s-cpl != 0)
goto illegal_op;
-if (s-cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s-cc_op);
-s-cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(pc_start - s-cs_base);
gen_helper_mwait(tcg_const_i32(s-pc - pc_start));
gen_eob(s);
@@ -7613,10 +7592,7 @@ static target_ulong disas_insn(DisasContext *s,
target_ulong pc_start)
gen_svm_check_intercept(s, pc_start, SVM_EXIT_RSM);
if (!(s-flags HF_SMM_MASK))
goto illegal_op;
-if (s-cc_op != CC_OP_DYNAMIC) {
-gen_op_set_cc_op(s-cc_op);
-s-cc_op = CC_OP_DYNAMIC;
-}
+gen_update_cc_op(s);
gen_jmp_im(s-pc - s-cs_base);
gen_helper_rsm();
gen_eob(s);
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Re: Release of COREMU, a scalable and portable full-system emulator
On 07/23/2010 01:02 PM, Stefan Hajnoczi wrote:
In fact, we solve this problem through a really simple method.
In our prototype, we removed this piece of code like this:
void *qemu_get_ram_ptr(ram_addr_t addr)
{
..
/* Move this entry to to start of the list. */
#ifndef CONFIG_COREMU
/* Different core can access this function at the same time.
* For coremu, disable this optimization to avoid data race.
* XXX or use spin lock here if performance impact is big. */
if (prev) {
prev-next = block-next;
block-next = *prevp;
*prevp = block;
}
#endif
return block-host + (addr - block-offset);
}
CONFIG_COREMU is defined when TCG parallel mode is configured.
And the list is more likely to be read only without hotplug device, so
we don't use a lock to protect it.
Reimplement this list with a lock free list is also reasonable, but
seems unnecessary. :-)
Ah, good :).
For this one in particular, you could just use circular lists (without a
head node, unlike the Linux kernel's list data type, as there's always
a RAM entry) and start iteration at prev.
Paolo
[Qemu-devel] [PATCH] Ignore writes of perf reg (cp15 with crm == 12)
On ARMv7, ignore writes to cp15 with crm == 12; these are to setup perf
counters which we don't have.
---
target-arm/helper.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 2dd64d9..865829f 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1457,6 +1457,8 @@ void HELPER(set_cp15)(CPUState *env, uint32_t insn,
uint32_t val)
}
break;
case 9:
+if (arm_feature(env, ARM_FEATURE_V7) crm == 12)
+break; /* Perf counters. */
if (arm_feature(env, ARM_FEATURE_OMAPCP))
break;
switch (crm) {
--
1.7.1
Re: [Qemu-devel] Old DGUX Machine and Adaptec SCSI PCI Controller
On 07/25/2010 04:08 PM, DG UX wrote: Currently, these DGUX machines only support Qlogic and Adaptec, no IDE whatsoever and no LSI. Any way Qemu will support anything like that? I got to know these DGUX machines very well, and know all the logs locations and sys/hw info. If you need anything, including system/boot image, let me know. You'll need to find the hardware specifications for one of these cards, then find/fund someone to implement them. It shouldn't be too difficult. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
[Qemu-devel] [Bug 586175] Re: Windows XP/2003 doesn't boot
I have this problem as well. I'm installing using a slightly different situation -- I'm restoring a WinXP/Win2k3 backup that was made with fsarchiver -- but essentially I run across the same issue namely that boot fails when mbr tries to boot the first partition. In my case I use install-mbr from the mbr package but have also tried to install the windows mbr from the boot cd without success. Here are the steps I've taken and the partial fix I've discovered. First, let me say that these steps worked perfectly in 9.10. In fact, I can move the raw image from 9.10 to 10.04 and boot it without problem. That was initially how I got these restores to work; I installed on a Karmic laptop and moved the raw image to Lucid. Install Notes: Install Procedure (for karmic or lucid): 1. boot system to image to rescuecd and backup xp or win2k3 using fsarchiver: fsarchiver savefs /some/remote/location/win.fsa /dev/sda1 2. on kvm host create restore disk: lvcreate -L10GB -n win vg 3. boot virt with rescuecd kvm -m 1024 -cdrom rescuecd.iso -hda /dev/vg/win -boot d 3. partition disk (entire disk, one partition, active): fdisk /dev/sda commands: o n p 1 [] [] t 7 a 1 w 4. restore archive: fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1 5. install mbr: install-mbr /dev/sda 6. halt virt and reboot to image: kvm -m 1024 -hda /dev/vg/win At this point, the image will boot in 9.10. But following the same steps in lucid it will hang after the mbr boots the first partition. I tried everything I could think of and all the different steps found on the web including repairing the mbr changing disk types and boot options to no avail. What was odd for me is that the resulting image created on karmic would boot on lucid which indicated to me that once the install was completed successfully whatever kvm was doing didn't matter -- it was just the creation of the mbr or file system in the kvm boot that was at fault. My next step at this point was to install hexedit and compare the two resulting images. Specifically, the mbr at the beginning of the disk and the ntfs partition starting at sector 63. On the net there is some talk about changing 0x7E1A to 'FF' -- which is supposed to indicate disk geometry of the ntfs partition. There were three values that were different at this point in the ntfs file region -- 0x8E18, 0x7E1A, and 0x7E1C. The first two did not seem to have any effect. But changing 0x7E1C to the value of '3F' would result in the image booting properly. Evidently this is the part of the NTFS file system that records the starting sector of the partition. This change successfully booted all my test cases restores with a single partition. OK, so at this point I backtracked and did just steps 1-4 on both Karmic and Lucid but instead of booting to a rescuecd in the virt I used kpartx to mount the raw file system: 1. make backup fsarchiver savefs win.fsa /dev/sda1 2. create disk lvcreate -L10GB -n win vg 3. partition fdisk /dev/vg/win 4. mount to loop, restore, detach kpartx -av /dev/vg/win fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1 kpartx -dv /dev/loop0 5. install mbr install-mbr /dev/vg/win At this point, unfortunately, these steps will not boot on either karmic or lucid -- the boot section of the ntfs partition does not seem to write correctly (0x8E18, 0x7E1A, and 0x7E1C are all '00'). However, if you change 0x7E1C to '3F', these resulting images will boot fine: 6. after hexedit, boot, success kvm -m 1024 -hda /dev/vg/win Hope this helps track down this issue. My feeling here is that this is not an issue with the mbr but rather the creation of the ntfs file system. And it does seem that the disk geometry presented by the version of kvm in lucid is different enough from karmic to cause the ntfs file system incorrectly write sector 0x7E1C thus causing the resulting image to hang at boot. -- Windows XP/2003 doesn't boot https://bugs.launchpad.net/bugs/586175 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Status in Debian GNU/Linux: New Status in Fedora: Unknown Bug description: Hello everyone, my qemu doesn't boot any Windows XP/2003 installations if I try to boot the image. If I boot the install cd first, it's boot manager counts down and triggers the boot on it's own. That's kinda stupid. I'm using libvirt, but even by a simple qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on it won't boot. Qemu hangs at the message Booting from Hard Disk... I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). It's a server, that means I'm using VNC as the primary graphic output but i don't think it should be an issue.
[Qemu-devel] [PATCH] Fix -snapshot deleting images on disk change
Block device change command did not copy BDRV_O_SNAPSHOT flag. Thus
the new image did not have this flag and the file got deleted during
opening.
Fix by copying BDRV_O_SNAPSHOT flag.
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
block.c|5 +
block.h|1 +
blockdev.c |1 +
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index f837876..14cfed1 100644
--- a/block.c
+++ b/block.c
@@ -1800,6 +1800,11 @@ int bdrv_can_snapshot(BlockDriverState *bs)
return 1;
}
+int bdrv_is_snapshot(BlockDriverState *bs)
+{
+return !!(bs-open_flags BDRV_O_SNAPSHOT);
+}
+
BlockDriverState *bdrv_snapshots(void)
{
BlockDriverState *bs;
diff --git a/block.h b/block.h
index c2a7e4c..db131a3 100644
--- a/block.h
+++ b/block.h
@@ -202,6 +202,7 @@ const char
*bdrv_get_encrypted_filename(BlockDriverState *bs);
void bdrv_get_backing_filename(BlockDriverState *bs,
char *filename, int filename_size);
int bdrv_can_snapshot(BlockDriverState *bs);
+int bdrv_is_snapshot(BlockDriverState *bs);
BlockDriverState *bdrv_snapshots(void);
int bdrv_snapshot_create(BlockDriverState *bs,
QEMUSnapshotInfo *sn_info);
diff --git a/blockdev.c b/blockdev.c
index 0a9dec3..01e402b 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -590,6 +590,7 @@ int do_change_block(Monitor *mon, const char *device,
return -1;
}
bdrv_flags = bdrv_is_read_only(bs) ? 0 : BDRV_O_RDWR;
+bdrv_flags |= bdrv_is_snapshot(bs) ? BDRV_O_SNAPSHOT : 0;
if (bdrv_open(bs, filename, bdrv_flags, drv) 0) {
qerror_report(QERR_OPEN_FILE_FAILED, filename);
return -1;
--
1.6.2.4
Re: [Qemu-devel] [PATCH] Fix -snapshot deleting CDROM images
On Sat, Jul 24, 2010 at 12:03 PM, Markus Armbruster arm...@redhat.com wrote: Blue Swirl blauwir...@gmail.com writes: Command line flag '-snapshot' was setting the drive flag 'snapshot' for all drives. Therefore also CDROM devices were incorrectly marked with BDRV_O_SNAPSHOT. Thus the backing images were accidentally deleted at bdrv_open time, for example when changing the image with monitor 'change' command. Fix by adding a separate 'global_snapshot' drive flag for use when the command line flag '-snapshot' is used. Also add some extra checks and suppress a kraxelian notation. This patch doesn't feel right to me. The bug you observed is that snapshot=on does something stupid for a certain kind of drive: bdrv_open_common() removes a temporary file that isn't temporary. That bug needs fixing. Your patch does not fix it. Instead, it attempts to avoid the bug: snapshot=on now fails with media=cdrom, and the new -drive option global_snapshot=on gets silently ignored with media=cdrom. Why is media=cdrom the only case where the bug can bite? Because other media types are not removable. Why not fix bdrv_open_common()? I've just submitted a new version with a different approach. I think the following case is still suspicious: the only device is changed to one whose format does not support snapshots. It's unrelated to this bug though. Another annoyance I noticed is that changing block.h forces all files to be recompiled. I didn't find the culprit easily.
Re: [Qemu-devel] memory trace with qemu
Thanks for your awnsers. Stean, after I find the right place to capture the reads and writes I'll definitely try your trace tool. Until now, this is what i found: I am using the x86-64 target, and I know that, for instance, lots of reads pass here: target-i386/translate.c gen_op_ld_T1_A0() This function calls gen_op_ld_v, that calls a tcg function according to the operand size. Lets assume tcg_gen_qemu_ld8u() is called, which is defined at tcg/tcg-op.h Here I find myself lost again, because this function (in i386) calls tcg_gen_op3i_i32, which APPARENTLY does nothing... Where the code that access the main memory is being generated? 2010/7/24 Stefan Hajnoczi stefa...@gmail.com On Sat, Jul 24, 2010 at 3:17 AM, Yufei Chen cyfde...@gmail.com wrote: On Fri, Jul 23, 2010 at 2:15 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Jul 23, 2010 at 4:12 AM, Mulyadi Santosa mulyadi.sant...@gmail.com wrote: Hi... On Fri, Jul 23, 2010 at 05:30, Eduardo Cruz eduardohmdac...@gmail.com wrote: Hello, I need qemu to keep track of all the memory access made by the guest, including read, write and the instruction fetches. I don't think Qemu can provide cycle number information. But other information are all available. AFAIK there are lots of experiments on this and has produces working patches...at least from the posting of the creator. There is even a patch floating to start creating trace framework a while ago. Thanks Mulyadi, I think you are referring to the tracing work that Prerna Saxena and I are doing. Here is the documentation: http://repo.or.cz/w/qemu/stefanha.git/blob/tracing:/docs/tracing.txt The patches apply to qemu.git. You can define trace events in the trace-events file and then call them from places in the code. There is a script to pretty-print the binary trace file that QEMU produces. Eduardo, if you think this might be what you're looking for, please give it a try. I am on #qemu and #kvm IRC if you need any help. Any feedback will be valuable to us as we prepare these patches for submission to qemu.git. I believe the tracing framework answers the Any ideas of how I can record these information with qemu? part of your question :). I don't have experience in the TCG, so I can't give advice on how to best get at the memory accesses, but I hope this helps you one step further. Can this framework trace memory access event? I guess this would be more difficult to do in KVM than in TCG. No, it can't trace memory accesses. It provides you with the ability to put trace events into QEMU, but there is current no pre-defined trace event for memory access. If you find the right spot to in TCG it should be easy to add a trace event there. I agree, with KVM is would be more difficult and perhaps defeat the point of KVM :). Stefan Stefan perhaps you could dig a little deeper in qemu archieve? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- Best regards, Chen Yufei -- Eduardo Henrique Molina da Cruz MSc student Parallel and Distributed Processing Group Federal University of Rio Grande do Sul (UFRGS)
[Qemu-devel] [Bug 586175] Re: Windows XP/2003 doesn't boot
** Also affects: ubuntu Importance: Undecided Status: New ** Package changed: ubuntu = qemu-kvm (Ubuntu) -- Windows XP/2003 doesn't boot https://bugs.launchpad.net/bugs/586175 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Status in “qemu-kvm” package in Ubuntu: New Status in Debian GNU/Linux: New Status in Fedora: Unknown Bug description: Hello everyone, my qemu doesn't boot any Windows XP/2003 installations if I try to boot the image. If I boot the install cd first, it's boot manager counts down and triggers the boot on it's own. That's kinda stupid. I'm using libvirt, but even by a simple qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on it won't boot. Qemu hangs at the message Booting from Hard Disk... I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). It's a server, that means I'm using VNC as the primary graphic output but i don't think it should be an issue.
[Qemu-devel] [Bug 599617] Re: qemu fail to parse command -net none
This issue has gone with qemu-kvm commit d4adede84de96d631f2c6eff2c01eae00b14a110. ** Changed in: qemu Status: Invalid = Fix Released ** Changed in: qemu-kvm (Ubuntu) Status: Triaged = Fix Released -- qemu fail to parse command -net none https://bugs.launchpad.net/bugs/599617 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Fix Released Status in “qemu-kvm” package in Ubuntu: Fix Released Bug description: Host OS:ia32e Guest OS :32e and pae kvm.git Commit:a63e16c655f9e68d49d6fae4275ffda16b1888b2 qemu-kvm Commit:97011c7fce92f8c0928c9e94e9896f0dca1bdeb9 Host Kernel Version:2.6.35-rc3 Bug detailed description: -- when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -net none to boot up a guest, guest cannot boot up. and no error message displayed.
[Qemu-devel] [Bug 597932] Re: qemu fail to parse command line with -pcidevice B:D.F
Now we use new command to do VT-d device assignment: qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -device pci-assign,host=00:19.0 ** Changed in: qemu Status: New = Fix Released -- qemu fail to parse command line with -pcidevice B:D.F https://bugs.launchpad.net/bugs/597932 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Fix Released Bug description: Host OS:ia32e Guest OS :32e and pae kvm.git Commit:a63e16c655f9e68d49d6fae4275ffda16b1888b2 qemu-kvm Commit:97011c7fce92f8c0928c9e94e9896f0dca1bdeb9 Host Kernel Version:2.6.35-rc3 Hardware:Gulftown-HEDT Bug detailed description: -- when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 to assign a nic to guest, guest cannot boot up, and display error message: qemu-system-x86_64: Parameter 'id' expects an identifier Identifiers consist of letters, digits, '-', '.', '_', starting with a letter. pcidevice argument parse error; please check the help text for usage Could not add assigned device host=00:19.0 It's caused by commit: b560a9ab9be06afcbb78b3791ab836dad208a239. It took 00:19.0 alike form as illegal. Reproduce steps: 1. boot up into host 2. use pcistub hide a nic: #sh pcistub.sh -h 00:19.0 3. when use command qemu-system_x86 -smp 2 -m 1024 -hda /path/to/img -pcidevice host=00:19.0 to assign a nic to guest
Re: [Qemu-devel] memory trace with qemu
On Mon, Jul 26, 2010 at 6:21 AM, Eduardo Cruz eduardohmdac...@gmail.com wrote: Thanks for your awnsers. Stean, after I find the right place to capture the reads and writes I'll definitely try your trace tool. Until now, this is what i found: I am using the x86-64 target, and I know that, for instance, lots of reads pass here: target-i386/translate.c gen_op_ld_T1_A0() This function calls gen_op_ld_v, that calls a tcg function according to the operand size. Lets assume tcg_gen_qemu_ld8u() is called, which is defined at tcg/tcg-op.h Here I find myself lost again, because this function (in i386) calls tcg_gen_op3i_i32, which APPARENTLY does nothing... Where the code that access the main memory is being generated? Please take a look at tcg_out_qemu_ld and tcg_out_qemu_st, also take a look at tcg_out_op. 2010/7/24 Stefan Hajnoczi stefa...@gmail.com On Sat, Jul 24, 2010 at 3:17 AM, Yufei Chen cyfde...@gmail.com wrote: On Fri, Jul 23, 2010 at 2:15 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Jul 23, 2010 at 4:12 AM, Mulyadi Santosa mulyadi.sant...@gmail.com wrote: Hi... On Fri, Jul 23, 2010 at 05:30, Eduardo Cruz eduardohmdac...@gmail.com wrote: Hello, I need qemu to keep track of all the memory access made by the guest, including read, write and the instruction fetches. I don't think Qemu can provide cycle number information. But other information are all available. AFAIK there are lots of experiments on this and has produces working patches...at least from the posting of the creator. There is even a patch floating to start creating trace framework a while ago. Thanks Mulyadi, I think you are referring to the tracing work that Prerna Saxena and I are doing. Here is the documentation: http://repo.or.cz/w/qemu/stefanha.git/blob/tracing:/docs/tracing.txt The patches apply to qemu.git. You can define trace events in the trace-events file and then call them from places in the code. There is a script to pretty-print the binary trace file that QEMU produces. Eduardo, if you think this might be what you're looking for, please give it a try. I am on #qemu and #kvm IRC if you need any help. Any feedback will be valuable to us as we prepare these patches for submission to qemu.git. I believe the tracing framework answers the Any ideas of how I can record these information with qemu? part of your question :). I don't have experience in the TCG, so I can't give advice on how to best get at the memory accesses, but I hope this helps you one step further. Can this framework trace memory access event? I guess this would be more difficult to do in KVM than in TCG. No, it can't trace memory accesses. It provides you with the ability to put trace events into QEMU, but there is current no pre-defined trace event for memory access. If you find the right spot to in TCG it should be easy to add a trace event there. I agree, with KVM is would be more difficult and perhaps defeat the point of KVM :). Stefan Stefan perhaps you could dig a little deeper in qemu archieve? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- Best regards, Chen Yufei -- Eduardo Henrique Molina da Cruz MSc student Parallel and Distributed Processing Group Federal University of Rio Grande do Sul (UFRGS) -- Best regards, Chen Yufei
[Qemu-devel] [Bug 604872] Re: qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm
Tested with Maverick's vmlinuz-2.6.35-10-versatile and I'm still able to reproduce the problem (qemu cdcf9153e5e17dde340135fee5dcc7c299f2d4f5 this time). -- qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm https://bugs.launchpad.net/bugs/604872 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: Triaged Bug description: Binary package hint: qemu-kvm As I'm now implementing the support for creating a rootstock rootfs without requiring root, I need to run the deboostrap' second stage inside a VM, to correctly install the packages into the rootfs. qemu-system-arm fails right after debootstrap finish the second stage, giving a segmentation fault. Command: qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel vmlinuz -no-reboot -nographic -drive file=qemu-armel-201007122016.img,aio=native,cache=none -m 256 -append 'console=ttyAMA0,115200n8 root=/dev/sda rw mem=256M devtmpfs.mount=0 init=/bin/installer' Uncompressing Linux. done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-21-versatile (bui...@cushaw) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu Fri Apr 16 08:14:53 UTC 2010 (Ubuntu 2.6.32-21.32-versatile 2.6.32.11+drm33.2) ... I: Base system installed successfully. I: Starting basic services in VM Segmentation fault (core dumped) [492816.197352] qemu-system-arm[16024]: segfault at cf6ba8fc ip cf6ba8fc sp 7fffd0e68680 error 14 Image: * rootfs: http://rsalveti.net/pub/ubuntu/rootstock/qemu-armel-201007122016.img (md5 1d063ac8a65c798bb004cd1c4c7970c5) * kernel: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/vmlinuz I'm able to reproduce the bug on Maverick (amd64) and Lucid (x86). Maverick qemu-kvm-extras: 0.12.4+noroms-0ubuntu4 Lucid qemu-kvm-extras: 0.12.3+noroms-0ubuntu9.2 ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: qemu-kvm-extras 0.12.4+noroms-0ubuntu4 ProcVersionSignature: Ubuntu 2.6.35-6.9-generic 2.6.35-rc3 Uname: Linux 2.6.35-6-generic x86_64 Architecture: amd64 Date: Mon Jul 12 18:55:35 2010 InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100427.1) KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD MachineType: LENOVO 2764CTO PccardctlIdent: Socket 0: no product info available PccardctlStatus: Socket 0: no card ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.35-6-generic root=/dev/mapper/primary-root ro crashkernel=384M-2G:64M,2G-:128M quiet splash ProcEnviron: LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: qemu-kvm dmi.bios.date: 04/19/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 7UET86WW (3.16 ) dmi.board.name: 2764CTO dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr7UET86WW(3.16):bd04/19/2010:svnLENOVO:pn2764CTO:pvrThinkPadT400:rvnLENOVO:rn2764CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 2764CTO dmi.product.version: ThinkPad T400 dmi.sys.vendor: LENOVO
[Qemu-devel] QEMU-MIPS64
Hi, I am trying to add support for mips64 user mode emulation in QEMU.I have written the code for loading mips64 ELF.The problem is when QEMU executes translation blocks,it generates TLB load exception on one TB and calls host_signal_handler().Could any one plz help??
[Qemu-devel] [PATCH] block migration: replace tabs by spaces.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
block-migration.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 8eda307..0bfdb73 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -346,7 +346,7 @@ static int mig_save_device_dirty(Monitor *mon, QEMUFile *f,
blk-iov.iov_len = nr_sectors * BDRV_SECTOR_SIZE;
qemu_iovec_init_external(blk-qiov, blk-iov, 1);
- blk-time = qemu_get_clock_ns(rt_clock);
+blk-time = qemu_get_clock_ns(rt_clock);
blk-aiocb = bdrv_aio_readv(bmds-bs, sector, blk-qiov,
nr_sectors, blk_mig_read_cb, blk);
@@ -449,13 +449,13 @@ static int is_stage2_completed(void)
if (block_mig_state.bulk_completed == 1) {
remaining_dirty = get_remaining_dirty();
- if (remaining_dirty == 0) {
- return 1;
- }
+if (remaining_dirty == 0) {
+return 1;
+}
- bwidth = compute_read_bwidth();
+bwidth = compute_read_bwidth();
- if ((remaining_dirty / bwidth) =
+if ((remaining_dirty / bwidth) =
migrate_max_downtime()) {
/* finish stage2 because we think that we can finish remaing work
below max_downtime */
--
1.7.1.1
[Qemu-devel] [PATCH 0/2] seabios: pciinit: fix bar allocation
This patch set fixes pci bar allocation. Cam Macdonell reported that there was something wrong with 64bit/32bit 512M BAR. This addresses his report. Isaku Yamahata (2): seabios: pciinit: fix 64bit bar initilization. seabios: pciinit: fix overflow when bar allocation. src/pciinit.c | 56 1 files changed, 36 insertions(+), 20 deletions(-)
[Qemu-devel] [PATCH 1/2] seabios: pciinit: fix 64bit bar initilization.
When 64bit bar allocation failed, leave it untouched as 32bit bar case.
There is no point to set higher bit to all 1, it is just leftover from
debug code.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
src/pciinit.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/pciinit.c b/src/pciinit.c
index b110531..f75e552 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -116,12 +116,8 @@ static int pci_bios_allocate_region(u16 bdf, int
region_num)
int is_64bit = !(val PCI_BASE_ADDRESS_SPACE_IO)
(val PCI_BASE_ADDRESS_MEM_TYPE_MASK) == PCI_BASE_ADDRESS_MEM_TYPE_64;
-if (is_64bit) {
-if (size 0) {
-pci_config_writel(bdf, ofs + 4, 0);
-} else {
-pci_config_writel(bdf, ofs + 4, ~0);
-}
+if (is_64bit size 0) {
+pci_config_writel(bdf, ofs + 4, 0);
}
return is_64bit;
}
--
1.7.1.1
[Qemu-devel] [PATCH 2/2] seabios: pciinit: fix overflow when bar allocation.
When allocating bar, overflow can occur.
So add overflow check and don't allocate bar if overflowed.
Overflow check is ugly, but necessary.
Another suggested way is to change related variables u64 from u32
thus overflow can't occur because the related value are all u32 addressable.
Anyway even with u64, it is necessary to the resulted value max_u32.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
src/pciinit.c | 48 ++--
1 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/src/pciinit.c b/src/pciinit.c
index f75e552..9be895c 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -49,6 +49,12 @@ static void pci_set_io_region_addr(u16 bdf, int region_num,
u32 addr)
dprintf(1, region %d: 0x%08x\n, region_num, addr);
}
+static inline int pci_bar_overflow(u32 addr, u32 size)
+{
+return (ALIGN(addr, size) addr) ||
+(ALIGN(addr, size) + size ALIGN(addr, size));
+}
+
/*
* return value
* 0: 32bit BAR
@@ -78,7 +84,8 @@ static int pci_bios_allocate_region(u16 bdf, int region_num)
if (val != 0) {
if (val PCI_BASE_ADDRESS_SPACE_IO) {
paddr = pci_bios_io_addr;
-if (ALIGN(*paddr, size) + size = 64 * 1024) {
+if (pci_bar_overflow(*paddr, size) ||
+ALIGN(*paddr, size) + size = 64 * 1024) {
dprintf(1,
io region of (bdf 0x%x bar %d) can't be mapped.\n,
bdf, region_num);
@@ -90,7 +97,8 @@ static int pci_bios_allocate_region(u16 bdf, int region_num)
/* If pci_bios_prefmem_addr == 0, keep old behaviour */
pci_bios_prefmem_addr != 0) {
paddr = pci_bios_prefmem_addr;
-if (ALIGN(*paddr, size) + size = BUILD_PCIPREFMEM_END) {
+if (pci_bar_overflow(*paddr, size) ||
+ALIGN(*paddr, size) + size = BUILD_PCIPREFMEM_END) {
dprintf(1,
prefmem region of (bdf 0x%x bar %d) can't be mapped.
decrease BUILD_PCIMEM_SIZE and recompile. size %x\n,
@@ -99,7 +107,8 @@ static int pci_bios_allocate_region(u16 bdf, int region_num)
}
} else {
paddr = pci_bios_mem_addr;
-if (ALIGN(*paddr, size) + size = BUILD_PCIMEM_END) {
+if (pci_bar_overflow(*paddr, size) ||
+ALIGN(*paddr, size) + size = BUILD_PCIMEM_END) {
dprintf(1,
mem region of (bdf 0x%x bar %d) can't be mapped.
increase BUILD_PCIMEM_SIZE and recompile. size %x\n,
@@ -152,6 +161,12 @@ static const struct pci_device_id pci_isa_bridge_tbl[] = {
PCI_DEVICE_END
};
+static inline int pci_addr_overflow(u32 old, u32 base, u32 addr, u32 end)
+{
+/* if without overflow, old = base = addr = end */
+return (old base) || (base addr) || (addr end);
+}
+
#define PCI_IO_ALIGN4096
#define PCI_IO_SHIFT8
#define PCI_MEMORY_ALIGN(1UL 20)
@@ -184,36 +199,41 @@ static void pci_bios_init_device_bridge(u16 bdf, void
*arg)
pci_bios_init_device_in_bus(secbus);
}
-pci_bios_io_addr = ALIGN(pci_bios_io_addr, PCI_IO_ALIGN);
-pci_bios_mem_addr = ALIGN(pci_bios_mem_addr, PCI_MEMORY_ALIGN);
-pci_bios_prefmem_addr =
-ALIGN(pci_bios_prefmem_addr, PCI_PREF_MEMORY_ALIGN);
-
-u32 io_end = pci_bios_io_addr;
-if (io_end == io_base) {
+u32 io_end = ALIGN(pci_bios_io_addr, PCI_IO_ALIGN);
+if (pci_addr_overflow(io_old, io_base, pci_bios_io_addr, io_end) ||
+io_end == io_base) {
pci_bios_io_addr = io_old;
io_base = 0x;
io_end = 1;
+} else {
+pci_bios_io_addr = io_end;
}
pci_config_writeb(bdf, PCI_IO_BASE, io_base PCI_IO_SHIFT);
pci_config_writew(bdf, PCI_IO_BASE_UPPER16, 0);
pci_config_writeb(bdf, PCI_IO_LIMIT, (io_end - 1) PCI_IO_SHIFT);
pci_config_writew(bdf, PCI_IO_LIMIT_UPPER16, 0);
-u32 mem_end = pci_bios_mem_addr;
-if (mem_end == mem_base) {
+u32 mem_end = ALIGN(pci_bios_mem_addr, PCI_MEMORY_ALIGN);
+if (pci_addr_overflow(mem_old, mem_base, pci_bios_mem_addr, mem_end) ||
+mem_end == mem_base) {
pci_bios_mem_addr = mem_old;
mem_base = 0x;
mem_end = 1;
+} else {
+pci_bios_io_addr = mem_end;
}
pci_config_writew(bdf, PCI_MEMORY_BASE, mem_base PCI_MEMORY_SHIFT);
pci_config_writew(bdf, PCI_MEMORY_LIMIT, (mem_end -1) PCI_MEMORY_SHIFT);
-u32 prefmem_end = pci_bios_prefmem_addr;
-if (prefmem_end == prefmem_base) {
+u32 prefmem_end = ALIGN(pci_bios_prefmem_addr, PCI_PREF_MEMORY_ALIGN);
+if (pci_addr_overflow(prefmem_old, prefmem_base,
+ pci_bios_prefmem_addr, prefmem_end) ||
+prefmem_end == prefmem_base) {
pci_bios_prefmem_addr = prefmem_old;
prefmem_base = 0x;
