Re: [Qemu-devel] [kvmarm] [RFC] Virtio-desktop: Virtio-based virtual desktop
On Fri, Jan 25, 2013 at 08:31:54PM +0100, Alexander Graf wrote: On 25.01.2013, at 20:04, Blue Swirl wrote: On Thu, Jan 24, 2013 at 6:10 AM, Anup Patel anup.pa...@linaro.org wrote: Hi All, How about having a generic Virtio-based machine for emulating a virtual desktop ? I have also thought about this, current virtio design is not very clean. On the downside, pure no-legacy approach might not work well if you want the host to give control of a host device to guest (VFIO like pass through using IOMMUs). I know folks have already thought about this and probably also tried something or other on this front but, it will be good to know the downsides. Virtio-desktop can be a separate specification describing a virtual desktop. Of-course we cannot avoid few architecture dependent virtual devices in but the Virtio-desktop specification will try to keep minimum possible architecture dependent devices. As per our thoughts, a Virtio-desktop will have two kinds of devices: 1. Architecture dependent devices: This devices will be emulated in-kernel by architecture specific code of KVM or Xen or Some other hypervisor. a) Virtualized CPU b) Virtualized PIC (i.e. in-kernel architecture specific emulation of irqchip) c) Virtualized Timer (i.e. in-kernel architecture specific emulation of timer chip) I think reusing PIC and timer design is not the most optimal. What a PV aware OS really wants is to wake up because of an external event or at some specific point of time (or after a specific delay) and easy way to manage the VM clock without timer tick counting. With a tickless approach, it would need the timer events as rarely as possible. Perhaps a better approach would be to introduce a way for the guest to subscribe to a list of external events (including time), which would be fed to it via something like reverse hypercall (or just use legacy interrupts). Preferably it should be possible to pass any events through a stack of guests to the end consumer guest and even applications in a guest. This approach falls apart once hardware vendors implement timer interrupts inside a guest context (which Intel and IIUC ARM are doing). At that point, it's actually more efficient to do real timer calls to real hardware. Same with irq chip. Implementing PV irqchip today is going backwards. PV is bad. We only do it when we have to. Not doing PV where we don't have to is exactly the reason KVM is superior to Xen. Exactly. Implementing PV for something that does not require PV (for performance reasons mostly) is trading tested guest code, to untested, and unwritten, one. -- Gleb.
Re: [Qemu-devel] [kvmarm] [RFC] Virtio-desktop: Virtio-based virtual desktop
On Sun, Jan 27, 2013 at 8:20 AM, Gleb Natapov g...@redhat.com wrote: On Fri, Jan 25, 2013 at 08:31:54PM +0100, Alexander Graf wrote: On 25.01.2013, at 20:04, Blue Swirl wrote: On Thu, Jan 24, 2013 at 6:10 AM, Anup Patel anup.pa...@linaro.org wrote: Hi All, How about having a generic Virtio-based machine for emulating a virtual desktop ? I have also thought about this, current virtio design is not very clean. On the downside, pure no-legacy approach might not work well if you want the host to give control of a host device to guest (VFIO like pass through using IOMMUs). I know folks have already thought about this and probably also tried something or other on this front but, it will be good to know the downsides. Virtio-desktop can be a separate specification describing a virtual desktop. Of-course we cannot avoid few architecture dependent virtual devices in but the Virtio-desktop specification will try to keep minimum possible architecture dependent devices. As per our thoughts, a Virtio-desktop will have two kinds of devices: 1. Architecture dependent devices: This devices will be emulated in-kernel by architecture specific code of KVM or Xen or Some other hypervisor. a) Virtualized CPU b) Virtualized PIC (i.e. in-kernel architecture specific emulation of irqchip) c) Virtualized Timer (i.e. in-kernel architecture specific emulation of timer chip) I think reusing PIC and timer design is not the most optimal. What a PV aware OS really wants is to wake up because of an external event or at some specific point of time (or after a specific delay) and easy way to manage the VM clock without timer tick counting. With a tickless approach, it would need the timer events as rarely as possible. Perhaps a better approach would be to introduce a way for the guest to subscribe to a list of external events (including time), which would be fed to it via something like reverse hypercall (or just use legacy interrupts). Preferably it should be possible to pass any events through a stack of guests to the end consumer guest and even applications in a guest. This approach falls apart once hardware vendors implement timer interrupts inside a guest context (which Intel and IIUC ARM are doing). At that point, it's actually more efficient to do real timer calls to real hardware. Same with irq chip. Implementing PV irqchip today is going backwards. I'm not sure this should be the conclusion. Obviously throwing more hardware at virtualization makes it faster and the x86 host will probably also benefit from faster interrupt handling as a side benefit, so emulating the PIC etc. makes sense for now and also in short term (some years from now). But long term, if you could direct the hardware design efforts of major companies and standardization bodies to any direction, is fast emulation of 30 year old technology what would create the fastest architecture in the future? For example, maybe the PIC+LAPIC should be replaced in long term by something that can vector the interrupts to different VCPUs directly, each at different privilege levels? PV is bad. We only do it when we have to. Not doing PV where we don't have to is exactly the reason KVM is superior to Xen. Exactly. Implementing PV for something that does not require PV (for performance reasons mostly) is trading tested guest code, to untested, and unwritten, one. HW acceleration of Xen would just need faster IPC, but that has probably reached max performance ages ago. The legacy driver benefit is a good point, though more so for short term. -- Gleb.
Re: [Qemu-devel] [PATCH] add fd limitations for avoiding a buffer overflow
On Fri, Jan 25, 2013 at 04:14:49PM +0800, Amos Kong wrote:
FD_SET() and FD_CLR() are used to add and remove one descriptor from a
set, the 'fd' should be less than FD_SETSIZE. Glibc will give a warning
and crash the qemu when we set a fd (1024) to a set.
# qemu -device virtio-net-pci,netdev=macvtap_netdev,mac=92:ff:8a:11:fe:57
-netdev tap,id=macvtap_netdev,fd=1024 1024/dev/tap4
*** buffer overflow detected ***: x86_64-softmmu/qemu-system-x86_64
terminated
=== Backtrace: =
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f842a2134a7]
/lib64/libc.so.6(+0x35e9d08620)[0x7f842a211620]
/lib64/libc.so.6(+0x35e9d0a417)[0x7f842a213417]
x86_64-softmmu/qemu-system-x86_64(+0x1901fd)[0x7f842f09f1fd]
x86_64-softmmu/qemu-system-x86_64(+0x198388)[0x7f842f0a7388]
x86_64-softmmu/qemu-system-x86_64(main+0xfa9)[0x7f842ef897a9]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f842a12aa05]
x86_64-softmmu/qemu-system-x86_64(+0x7ed49)[0x7f842ef8dd49]
=== Memory map:
This is simply because we are using select for polling, right?
This patch added limitations when init tap device and set fd handler
for synchronous IO.
Signed-off-by: Amos Kong ak...@redhat.com
---
iohandler.c |3 +++
net/tap.c |3 ++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/iohandler.c b/iohandler.c
index 2523adc..c22edab 100644
--- a/iohandler.c
+++ b/iohandler.c
@@ -66,6 +66,9 @@ int qemu_set_fd_handler2(int fd,
}
}
} else {
+if (fd = FD_SETSIZE) {
+return 1;
+}
QLIST_FOREACH(ioh, io_handlers, next) {
if (ioh-fd == fd)
goto found;
diff --git a/net/tap.c b/net/tap.c
index eb40c42..be856dd 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -618,7 +618,8 @@ int net_init_tap(const NetClientOptions *opts, const char
*name,
}
fd = monitor_handle_fd_param(cur_mon, tap-fd);
-if (fd == -1) {
+if (fd == -1 || fd = FD_SETSIZE) {
+error_report(Invalid fd : %d, fd);
return -1;
}
The fd is actually valid. It's simply too high.
And if this triggered it's quite possibly that
the fd passed in is 1023 but the moment we try to
allocate our own fd, it will be 1024 so boom.
So maybe, the right thing to do here is to use poll or epoll?
--
1.7.1
[Qemu-devel] [RFC 10/19] target-alpha: Refactor debug output macros
Make LOG_DISAS() arguments compile-testable even if disabled.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-alpha/translate.c | 12 ++--
1 Datei geändert, 6 Zeilen hinzugefügt(+), 6 Zeilen entfernt(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index f687b95..c1da5bf 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -26,14 +26,14 @@
#define GEN_HELPER 1
#include helper.h
-#undef ALPHA_DEBUG_DISAS
+#define ALPHA_DEBUG_DISAS 0
#define CONFIG_SOFTFLOAT_INLINE
-#ifdef ALPHA_DEBUG_DISAS
-# define LOG_DISAS(...) qemu_log_mask(CPU_LOG_TB_IN_ASM, ## __VA_ARGS__)
-#else
-# define LOG_DISAS(...) do { } while (0)
-#endif
+#define LOG_DISAS(...) G_STMT_START \
+if (ALPHA_DEBUG_DISAS) { \
+qemu_log_mask(CPU_LOG_TB_IN_ASM, ## __VA_ARGS__); \
+} \
+G_STMT_END
typedef struct DisasContext DisasContext;
struct DisasContext {
--
1.7.10.4
[Qemu-devel] [RFC 14/19] target-microblaze: Refactor debug output macros
Make debug output compile-testable even if disabled.
Drop unused D(x) macros.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-microblaze/helper.c| 25 ++---
target-microblaze/mmu.c | 28 +---
target-microblaze/op_helper.c |2 --
target-microblaze/translate.c | 11 +--
4 Dateien geändert, 40 Zeilen hinzugefügt(+), 26 Zeilen entfernt(-)
diff --git a/target-microblaze/helper.c b/target-microblaze/helper.c
index 97aedc5..6467164 100644
--- a/target-microblaze/helper.c
+++ b/target-microblaze/helper.c
@@ -21,8 +21,19 @@
#include cpu.h
#include qemu/host-utils.h
-#define D(x)
-#define DMMU(x)
+#define DEBUG_MB 0
+#define DEBUG_MB_MMU 0
+
+#define D_LOG(...) G_STMT_START \
+if (DEBUG_MB) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
+#define MMU_LOG(...) G_STMT_START \
+if (DEBUG_MB_MMU) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
#if defined(CONFIG_USER_ONLY)
@@ -70,13 +81,13 @@ int cpu_mb_handle_mmu_fault (CPUMBState *env, target_ulong
address, int rw,
vaddr = address TARGET_PAGE_MASK;
paddr = lu.paddr + vaddr - lu.vaddr;
-DMMU(qemu_log(MMU map mmu=%d v=%x p=%x prot=%x\n,
- mmu_idx, vaddr, paddr, lu.prot));
+MMU_LOG(MMU map mmu=%d v=%x p=%x prot=%x\n,
+mmu_idx, vaddr, paddr, lu.prot);
tlb_set_page(env, vaddr, paddr, lu.prot, mmu_idx,
TARGET_PAGE_SIZE);
r = 0;
} else {
env-sregs[SR_EAR] = address;
-DMMU(qemu_log(mmu=%d miss v=%x\n, mmu_idx, address));
+MMU_LOG(mmu=%d miss v=%x\n, mmu_idx, address);
switch (lu.err) {
case ERR_PROT:
@@ -156,7 +167,7 @@ void do_interrupt(CPUMBState *env)
env-sregs[SR_ESR] = ~(1 12);
/* Exception breaks branch + dslot sequence? */
if (env-iflags D_FLAG) {
-D(qemu_log(D_FLAG set at exception bimm=%d\n, env-bimm));
+D_LOG(D_FLAG set at exception bimm=%d\n, env-bimm);
env-sregs[SR_ESR] |= 1 12 ;
env-sregs[SR_BTR] = env-btarget;
@@ -171,7 +182,7 @@ void do_interrupt(CPUMBState *env)
log_cpu_state_mask(CPU_LOG_INT, env, 0);
}
} else if (env-iflags IMM_FLAG) {
-D(qemu_log(IMM_FLAG set at exception\n));
+D_LOG(IMM_FLAG set at exception\n);
env-regs[17] -= 4;
}
diff --git a/target-microblaze/mmu.c b/target-microblaze/mmu.c
index 53ad263..6df74b9 100644
--- a/target-microblaze/mmu.c
+++ b/target-microblaze/mmu.c
@@ -20,7 +20,13 @@
#include cpu.h
-#define D(x)
+#define DEBUG_MB 0
+
+#define D_LOG(...) G_STMT_START \
+if (DEBUG_MB) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
static unsigned int tlb_decode_size(unsigned int f)
{
@@ -87,7 +93,7 @@ unsigned int mmu_translate(struct microblaze_mmu *mmu,
/* Lookup and decode. */
t = mmu-rams[RAM_TAG][i];
-D(qemu_log(TLB %d valid=%d\n, i, t TLB_VALID));
+D_LOG(TLB %d valid=%d\n, i, t TLB_VALID);
if (t TLB_VALID) {
tlb_size = tlb_decode_size((t TLB_PAGESZ_MASK) 7);
if (tlb_size TARGET_PAGE_SIZE) {
@@ -98,14 +104,14 @@ unsigned int mmu_translate(struct microblaze_mmu *mmu,
mask = ~(tlb_size - 1);
tlb_tag = t TLB_EPN_MASK;
if ((vaddr mask) != (tlb_tag mask)) {
-D(qemu_log(TLB %d vaddr=%x != tag=%x\n,
- i, vaddr mask, tlb_tag mask));
+D_LOG(TLB %d vaddr=%x != tag=%x\n,
+ i, vaddr mask, tlb_tag mask);
continue;
}
if (mmu-tids[i]
((mmu-regs[MMU_R_PID] 0xff) != mmu-tids[i])) {
-D(qemu_log(TLB %d pid=%x != tid=%x\n,
- i, mmu-regs[MMU_R_PID], mmu-tids[i]));
+D_LOG(TLB %d pid=%x != tid=%x\n,
+ i, mmu-regs[MMU_R_PID], mmu-tids[i]);
continue;
}
@@ -170,8 +176,8 @@ unsigned int mmu_translate(struct microblaze_mmu *mmu,
}
}
done:
-D(qemu_log(MMU vaddr=%x rw=%d tlb_wr=%d tlb_ex=%d hit=%d\n,
- vaddr, rw, tlb_wr, tlb_ex, hit));
+D_LOG(MMU vaddr=%x rw=%d tlb_wr=%d tlb_ex=%d hit=%d\n,
+ vaddr, rw, tlb_wr, tlb_ex, hit);
return hit;
}
@@ -212,14 +218,14 @@ uint32_t mmu_read(CPUMBState *env, uint32_t rn)
r = env-mmu.regs[rn];
break;
}
-D(qemu_log(%s rn=%d=%x\n, __func__, rn, r));
+D_LOG(%s rn=%d=%x\n, __func__, rn, r);
return r;
}
void mmu_write(CPUMBState *env, uint32_t rn, uint32_t v)
{
unsigned int i;
-D(qemu_log(%s rn=%d=%x old=%x\n, __func__, rn, v, env-mmu.regs[rn]));
+D_LOG(%s rn=%d=%x old=%x\n,
[Qemu-devel] [PATCH for-1.4 06/19] target-s390x: Fix debug output (continued)
Since its introduction in d5a439645a5a70fed5431318c3bce9dc2caa950f
(s390x: helper functions for system emulation) the variable name was
raddr. Fix this.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-s390x/helper.c |4 ++--
1 Datei geändert, 2 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/target-s390x/helper.c b/target-s390x/helper.c
index a6af542..76fd558 100644
--- a/target-s390x/helper.c
+++ b/target-s390x/helper.c
@@ -404,8 +404,8 @@ int cpu_s390x_handle_mmu_fault(CPUS390XState *env,
target_ulong orig_vaddr,
/* check out of RAM access */
if (raddr (ram_size + virtio_size)) {
-DPRINTF(%s: aaddr % PRIx64 ram_size % PRIx64 \n, __func__,
-(uint64_t)aaddr, (uint64_t)ram_size);
+DPRINTF(%s: raddr % PRIx64 ram_size % PRIx64 \n, __func__,
+(uint64_t)raddr, (uint64_t)ram_size);
trigger_pgm_exception(env, PGM_ADDRESSING, ILEN_LATER);
return 1;
}
--
1.7.10.4
[Qemu-devel] [PATCH for-1.4 04/19] target-ppc: Fix build for PPC_DEBUG_DISAS
In r5949 / 76db3ba44ee8db671f804755f13b016eefd13288 (target-ppc: memory
load/store rework) variable little_endian was replaced with ctx.le_mode.
Update the debug code.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-ppc/translate.c |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 798b7ac..37ce55f 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -9698,7 +9698,7 @@ static inline void
gen_intermediate_code_internal(CPUPPCState *env,
}
LOG_DISAS(translate opcode %08x (%02x %02x %02x) (%s)\n,
ctx.opcode, opc1(ctx.opcode), opc2(ctx.opcode),
-opc3(ctx.opcode), little_endian ? little : big);
+opc3(ctx.opcode), ctx.le_mode ? little : big);
if (unlikely(qemu_loglevel_mask(CPU_LOG_TB_OP | CPU_LOG_TB_OP_OPT))) {
tcg_gen_debug_insn_start(ctx.nip);
}
--
1.7.10.4
[Qemu-devel] [RFC 12/19] target-i386: Refactor debug output macros
Make debug output compile-testable even if disabled.
Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Richard Henderson r...@twiddle.net
---
target-i386/helper.c | 33 -
target-i386/kvm.c| 16 +++-
target-i386/seg_helper.c | 20 +++-
3 Dateien geändert, 34 Zeilen hinzugefügt(+), 35 Zeilen entfernt(-)
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 547c25e..aa94289 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -24,7 +24,12 @@
#include monitor/monitor.h
#endif
-//#define DEBUG_MMU
+#define DEBUG_MMU 0
+#define MMU_DPRINTF(...) G_STMT_START \
+if (DEBUG_MMU) { \
+printf(__VA_ARGS__); \
+} \
+G_STMT_END
static void cpu_x86_version(CPUX86State *env, int *family, int *model)
{
@@ -370,9 +375,8 @@ void cpu_x86_set_a20(CPUX86State *env, int a20_state)
{
a20_state = (a20_state != 0);
if (a20_state != ((env-a20_mask 20) 1)) {
-#if defined(DEBUG_MMU)
-printf(A20 update: a20=%d\n, a20_state);
-#endif
+MMU_DPRINTF(A20 update: a20=%d\n, a20_state);
+
/* if the cpu is currently executing code, we must unlink it and
all the potentially executing TB */
cpu_interrupt(env, CPU_INTERRUPT_EXITTB);
@@ -388,9 +392,8 @@ void cpu_x86_update_cr0(CPUX86State *env, uint32_t new_cr0)
{
int pe_state;
-#if defined(DEBUG_MMU)
-printf(CR0 update: CR0=0x%08x\n, new_cr0);
-#endif
+MMU_DPRINTF(CR0 update: CR0=0x%08x\n, new_cr0);
+
if ((new_cr0 (CR0_PG_MASK | CR0_WP_MASK | CR0_PE_MASK)) !=
(env-cr[0] (CR0_PG_MASK | CR0_WP_MASK | CR0_PE_MASK))) {
tlb_flush(env, 1);
@@ -431,18 +434,15 @@ void cpu_x86_update_cr3(CPUX86State *env, target_ulong
new_cr3)
{
env-cr[3] = new_cr3;
if (env-cr[0] CR0_PG_MASK) {
-#if defined(DEBUG_MMU)
-printf(CR3 update: CR3= TARGET_FMT_lx \n, new_cr3);
-#endif
+MMU_DPRINTF(CR3 update: CR3= TARGET_FMT_lx \n, new_cr3);
tlb_flush(env, 0);
}
}
void cpu_x86_update_cr4(CPUX86State *env, uint32_t new_cr4)
{
-#if defined(DEBUG_MMU)
-printf(CR4 update: CR4=%08x\n, (uint32_t)env-cr[4]);
-#endif
+MMU_DPRINTF(CR4 update: CR4=%08x\n, (uint32_t)env-cr[4]);
+
if ((new_cr4 ^ env-cr[4])
(CR4_PGE_MASK | CR4_PAE_MASK | CR4_PSE_MASK |
CR4_SMEP_MASK | CR4_SMAP_MASK)) {
@@ -508,10 +508,9 @@ int cpu_x86_handle_mmu_fault(CPUX86State *env,
target_ulong addr,
target_ulong vaddr, virt_addr;
is_user = mmu_idx == MMU_USER_IDX;
-#if defined(DEBUG_MMU)
-printf(MMU fault: addr= TARGET_FMT_lx w=%d u=%d eip= TARGET_FMT_lx
\n,
- addr, is_write1, is_user, env-eip);
-#endif
+MMU_DPRINTF(MMU fault: addr= TARGET_FMT_lx w=%d u=%d
+ eip= TARGET_FMT_lx \n,
+addr, is_write1, is_user, env-eip);
is_write = is_write1 1;
if (!(env-cr[0] CR0_PG_MASK)) {
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 3acff40..732e5fd 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -34,15 +34,13 @@
#include hyperv.h
#include hw/pci/pci.h
-//#define DEBUG_KVM
-
-#ifdef DEBUG_KVM
-#define DPRINTF(fmt, ...) \
-do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
-#else
-#define DPRINTF(fmt, ...) \
-do { } while (0)
-#endif
+#define DEBUG_KVM 0
+
+#define DPRINTF(fmt, ...) G_STMT_START \
+if (DEBUG_KVM) { \
+fprintf(stderr, fmt, ## __VA_ARGS__); \
+} \
+G_STMT_END
#define MSR_KVM_WALL_CLOCK 0x11
#define MSR_KVM_SYSTEM_TIME 0x12
diff --git a/target-i386/seg_helper.c b/target-i386/seg_helper.c
index 3247dee..b626b68 100644
--- a/target-i386/seg_helper.c
+++ b/target-i386/seg_helper.c
@@ -22,20 +22,22 @@
#include qemu/log.h
#include helper.h
-//#define DEBUG_PCALL
+#define DEBUG_PCALL 0
#if !defined(CONFIG_USER_ONLY)
#include exec/softmmu_exec.h
#endif /* !defined(CONFIG_USER_ONLY) */
-#ifdef DEBUG_PCALL
-# define LOG_PCALL(...) qemu_log_mask(CPU_LOG_PCALL, ## __VA_ARGS__)
-# define LOG_PCALL_STATE(env) \
-log_cpu_state_mask(CPU_LOG_PCALL, (env), CPU_DUMP_CCOP)
-#else
-# define LOG_PCALL(...) do { } while (0)
-# define LOG_PCALL_STATE(env) do { } while (0)
-#endif
+#define LOG_PCALL(...) G_STMT_START \
+if (DEBUG_PCALL) { \
+qemu_log_mask(CPU_LOG_PCALL, ## __VA_ARGS__); \
+} \
+G_STMT_END
+#define LOG_PCALL_STATE(env) G_STMT_START \
+if (DEBUG_PCALL) { \
+log_cpu_state_mask(CPU_LOG_PCALL, (env), CPU_DUMP_CCOP); \
+} \
+G_STMT_END
/* return non zero if error */
static inline int load_segment(CPUX86State *env, uint32_t *e1_ptr,
--
1.7.10.4
[Qemu-devel] [RFC 19/19] target-unicore32: Refactor debug output macros
Make debug output compile-testable even if disabled.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-unicore32/helper.c | 12 ++--
target-unicore32/softmmu.c | 12 ++--
2 Dateien geändert, 12 Zeilen hinzugefügt(+), 12 Zeilen entfernt(-)
diff --git a/target-unicore32/helper.c b/target-unicore32/helper.c
index 5359538..688c985 100644
--- a/target-unicore32/helper.c
+++ b/target-unicore32/helper.c
@@ -17,13 +17,13 @@
#include ui/console.h
#endif
-#undef DEBUG_UC32
+#define DEBUG_UC32 0
-#ifdef DEBUG_UC32
-#define DPRINTF(fmt, ...) printf(%s: fmt , __func__, ## __VA_ARGS__)
-#else
-#define DPRINTF(fmt, ...) do {} while (0)
-#endif
+#define DPRINTF(fmt, ...) G_STMT_START \
+if (DEBUG_UC32) { \
+printf(%s: fmt , __func__, ## __VA_ARGS__); \
+} \
+G_STMT_END
CPUUniCore32State *uc32_cpu_init(const char *cpu_model)
{
diff --git a/target-unicore32/softmmu.c b/target-unicore32/softmmu.c
index fc27100..2ce30d9 100644
--- a/target-unicore32/softmmu.c
+++ b/target-unicore32/softmmu.c
@@ -14,13 +14,13 @@
#include cpu.h
-#undef DEBUG_UC32
+#define DEBUG_UC32 0
-#ifdef DEBUG_UC32
-#define DPRINTF(fmt, ...) printf(%s: fmt , __func__, ## __VA_ARGS__)
-#else
-#define DPRINTF(fmt, ...) do {} while (0)
-#endif
+#define DPRINTF(fmt, ...) G_STMT_START \
+if (DEBUG_UC32) { \
+printf(%s: fmt , __func__, ## __VA_ARGS__); \
+} \
+G_STMT_END
#define SUPERPAGE_SIZE (1 22)
#define UC32_PAGETABLE_READ(1 8)
--
1.7.10.4
Re: [Qemu-devel] [kvmarm] [RFC] Virtio-desktop: Virtio-based virtual desktop
On Sun, Jan 27, 2013 at 10:12:20AM +, Blue Swirl wrote: On Sun, Jan 27, 2013 at 8:20 AM, Gleb Natapov g...@redhat.com wrote: On Fri, Jan 25, 2013 at 08:31:54PM +0100, Alexander Graf wrote: On 25.01.2013, at 20:04, Blue Swirl wrote: On Thu, Jan 24, 2013 at 6:10 AM, Anup Patel anup.pa...@linaro.org wrote: Hi All, How about having a generic Virtio-based machine for emulating a virtual desktop ? I have also thought about this, current virtio design is not very clean. On the downside, pure no-legacy approach might not work well if you want the host to give control of a host device to guest (VFIO like pass through using IOMMUs). I know folks have already thought about this and probably also tried something or other on this front but, it will be good to know the downsides. Virtio-desktop can be a separate specification describing a virtual desktop. Of-course we cannot avoid few architecture dependent virtual devices in but the Virtio-desktop specification will try to keep minimum possible architecture dependent devices. As per our thoughts, a Virtio-desktop will have two kinds of devices: 1. Architecture dependent devices: This devices will be emulated in-kernel by architecture specific code of KVM or Xen or Some other hypervisor. a) Virtualized CPU b) Virtualized PIC (i.e. in-kernel architecture specific emulation of irqchip) c) Virtualized Timer (i.e. in-kernel architecture specific emulation of timer chip) I think reusing PIC and timer design is not the most optimal. What a PV aware OS really wants is to wake up because of an external event or at some specific point of time (or after a specific delay) and easy way to manage the VM clock without timer tick counting. With a tickless approach, it would need the timer events as rarely as possible. Perhaps a better approach would be to introduce a way for the guest to subscribe to a list of external events (including time), which would be fed to it via something like reverse hypercall (or just use legacy interrupts). Preferably it should be possible to pass any events through a stack of guests to the end consumer guest and even applications in a guest. This approach falls apart once hardware vendors implement timer interrupts inside a guest context (which Intel and IIUC ARM are doing). At that point, it's actually more efficient to do real timer calls to real hardware. Same with irq chip. Implementing PV irqchip today is going backwards. I'm not sure this should be the conclusion. Obviously throwing more hardware at virtualization makes it faster and the x86 host will probably also benefit from faster interrupt handling as a side benefit, so emulating the PIC etc. makes sense for now and also in short term (some years from now). Moder OSes, i.e those that have a non zero chance to get virtio-desktop support, do not use PIC on x86 after bootup, so there is not performance gains in replacing it with something PV and I hope you do not propose that. You probably think about using PV in place of LAPIC which, besides have to be written and debugged, will be slower on modern x86 HW since mode x86 HW accelerates LAPIC emulation. AFAIK arm also has irq chip virtualization support in HW. But long term, if you could direct the hardware design efforts of major companies and standardization bodies to any direction, is fast emulation of 30 year old technology what would create the fastest architecture in the future? For example, maybe the PIC+LAPIC should be replaced in long term by something that can vector the interrupts to different VCPUs directly, each at different privilege levels? What prevents you from doing it today with LAPIC/MSIX? PIC/IOAPIC are legacy and not used for anything performance sensitive. And do you truly believe that HW vendors will abandon current HW in favor of your design? -- Gleb.
[Qemu-devel] [PATCH for-1.4 03/19] target-ppc: Fix unused variable warning for FLUSH_ALL_TLBS
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-ppc/mmu_helper.c |3 ++-
1 Datei geändert, 2 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-ppc/mmu_helper.c b/target-ppc/mmu_helper.c
index 14fa25a..ee168f1 100644
--- a/target-ppc/mmu_helper.c
+++ b/target-ppc/mmu_helper.c
@@ -2262,8 +2262,9 @@ void helper_store_601_batu(CPUPPCState *env, uint32_t nr,
target_ulong value)
void helper_store_601_batl(CPUPPCState *env, uint32_t nr, target_ulong value)
{
+#if !defined(FLUSH_ALL_TLBS)
target_ulong mask;
-#if defined(FLUSH_ALL_TLBS)
+#else
int do_inval;
#endif
--
1.7.10.4
[Qemu-devel] [Libvirt][QEMU]The relationships between Libvirt and QEMU indetails
Hi Daniel and other developers, We have programed a HLFS(HDFS based Log-Structured FileSystem) driver for QEMU, which you can see it here. http://cloudxy.googlecode.com/svn/trunk/hlfs/patches/hlfs_driver_for_qemu_1.3.0.patch And i have tested in QEMU environment, which works well for us. Now, we wanna add a HLFS driver(Volume storage) for Libvirt(The same as Sheepdog) but i am not sure how to test HLFS driver for Libvirt. How could i know if the HLFS driver for Libvirt works well? I guess libvirt uses qemu interfaces(QEMU way) to finish the real jobs like create/delete volumes. I wanna use command 'virsh' to finish them, which the logical procedure like this: virsh -- libvirt client -- libvirt server -- QEMU Therefore, 'virsh' cannot work for me. I do not know how to test it with command 'virsh' solely. Or maybe i must build QEMU environment for this test, right? In brief, i am not clear about the relationships between Libvirt and QEMU. How do they(QEMU and Libvirt) communicate with each other? How could i test create/delete volumes of Sheepdog/HLFS only with Libvirt environment? Could anyone give me some suggestions? Thanks in advance;-) -- Thanks Harry Wei
[Qemu-devel] [PATCH RESEND for-1.4 01/19] target-cris: Build fix for debug output
Around r3361 (81fdc5f8d2d681da8d255baf0713144f8656bac9) env-debug1 used
to contain the address of an MMU fault. This is now written into
env-pregs[PR_EDA] instead.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-cris/op_helper.c |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-cris/op_helper.c b/target-cris/op_helper.c
index 0f6a1ee..b580513 100644
--- a/target-cris/op_helper.c
+++ b/target-cris/op_helper.c
@@ -60,7 +60,7 @@ void tlb_fill(CPUCRISState *env, target_ulong addr, int
is_write, int mmu_idx,
int ret;
D_LOG(%s pc=%x tpc=%x ra=%p\n, __func__,
- env-pc, env-debug1, (void *)retaddr);
+ env-pc, env-pregs[PR_EDA], (void *)retaddr);
ret = cpu_cris_handle_mmu_fault(env, addr, is_write, mmu_idx);
if (unlikely(ret)) {
if (retaddr) {
--
1.7.10.4
[Qemu-devel] [RFC 18/19] target-sparc: Refactor debug output macros
Make debug output compile-testable even if disabled.
Inline DEBUG_FEATURES and introduce FEATURES_DPRINTF() in cpu.c.
Inline DEBUG_MMU in ldst_helper.c but leave DPRINTF_MMU() outside.
Inline DEBUG_{MXCC,ASI} in ldst_helper.c.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-sparc/cpu.c | 30
target-sparc/ldst_helper.c | 173 +++-
2 Dateien geändert, 90 Zeilen hinzugefügt(+), 113 Zeilen entfernt(-)
diff --git a/target-sparc/cpu.c b/target-sparc/cpu.c
index f404aa8..55e4a83 100644
--- a/target-sparc/cpu.c
+++ b/target-sparc/cpu.c
@@ -19,7 +19,13 @@
#include cpu.h
-//#define DEBUG_FEATURES
+#define DEBUG_FEATURES 0
+
+#define FEATURES_DPRINTF(...) G_STMT_START \
+if (DEBUG_FEATURES) { \
+fprintf(stderr, ## __VA_ARGS__); \
+} \
+G_STMT_END
static int cpu_sparc_find_by_name(sparc_def_t *cpu_def, const char *cpu_model);
@@ -679,9 +685,7 @@ static int cpu_sparc_find_by_name(sparc_def_t *cpu_def,
const char *cpu_model)
goto error;
}
cpu_def-iu_version = iu_version;
-#ifdef DEBUG_FEATURES
-fprintf(stderr, iu_version % PRIx64 \n, iu_version);
-#endif
+FEATURES_DPRINTF(iu_version % PRIx64 \n, iu_version);
} else if (!strcmp(featurestr, fpu_version)) {
char *err;
@@ -691,9 +695,7 @@ static int cpu_sparc_find_by_name(sparc_def_t *cpu_def,
const char *cpu_model)
goto error;
}
cpu_def-fpu_version = fpu_version;
-#ifdef DEBUG_FEATURES
-fprintf(stderr, fpu_version %x\n, fpu_version);
-#endif
+FEATURES_DPRINTF(fpu_version %x\n, fpu_version);
} else if (!strcmp(featurestr, mmu_version)) {
char *err;
@@ -703,9 +705,7 @@ static int cpu_sparc_find_by_name(sparc_def_t *cpu_def,
const char *cpu_model)
goto error;
}
cpu_def-mmu_version = mmu_version;
-#ifdef DEBUG_FEATURES
-fprintf(stderr, mmu_version %x\n, mmu_version);
-#endif
+FEATURES_DPRINTF(mmu_version %x\n, mmu_version);
} else if (!strcmp(featurestr, nwindows)) {
char *err;
@@ -716,9 +716,7 @@ static int cpu_sparc_find_by_name(sparc_def_t *cpu_def,
const char *cpu_model)
goto error;
}
cpu_def-nwindows = nwindows;
-#ifdef DEBUG_FEATURES
-fprintf(stderr, nwindows %d\n, nwindows);
-#endif
+FEATURES_DPRINTF(nwindows %d\n, nwindows);
} else {
fprintf(stderr, unrecognized feature %s\n, featurestr);
goto error;
@@ -732,9 +730,9 @@ static int cpu_sparc_find_by_name(sparc_def_t *cpu_def,
const char *cpu_model)
}
cpu_def-features |= plus_features;
cpu_def-features = ~minus_features;
-#ifdef DEBUG_FEATURES
-print_features(stderr, fprintf, cpu_def-features, NULL);
-#endif
+if (DEBUG_FEATURES) {
+print_features(stderr, fprintf, cpu_def-features, NULL);
+}
g_free(s);
return 0;
diff --git a/target-sparc/ldst_helper.c b/target-sparc/ldst_helper.c
index 7decd66..7a9c7fe 100644
--- a/target-sparc/ldst_helper.c
+++ b/target-sparc/ldst_helper.c
@@ -20,38 +20,26 @@
#include cpu.h
#include helper.h
-//#define DEBUG_MMU
-//#define DEBUG_MXCC
+#define DEBUG_MMU 0
+#define DEBUG_MXCC 0
//#define DEBUG_UNALIGNED
//#define DEBUG_UNASSIGNED
-//#define DEBUG_ASI
-//#define DEBUG_CACHE_CONTROL
+#define DEBUG_ASI 0
+#define DEBUG_CACHE_CONTROL 0
-#ifdef DEBUG_MMU
#define DPRINTF_MMU(fmt, ...) \
-do { printf(MMU: fmt , ## __VA_ARGS__); } while (0)
-#else
-#define DPRINTF_MMU(fmt, ...) do {} while (0)
-#endif
+do { if (DEBUG_MMU) { printf(MMU: fmt , ## __VA_ARGS__); } } while (0)
-#ifdef DEBUG_MXCC
#define DPRINTF_MXCC(fmt, ...) \
-do { printf(MXCC: fmt , ## __VA_ARGS__); } while (0)
-#else
-#define DPRINTF_MXCC(fmt, ...) do {} while (0)
-#endif
+do { if (DEBUG_MXCC) { printf(MXCC: fmt , ## __VA_ARGS__); } } while (0)
-#ifdef DEBUG_ASI
#define DPRINTF_ASI(fmt, ...) \
-do { printf(ASI: fmt , ## __VA_ARGS__); } while (0)
-#endif
+do { if (DEBUG_ASI) { printf(ASI: fmt , ## __VA_ARGS__); } } while (0)
-#ifdef DEBUG_CACHE_CONTROL
#define DPRINTF_CACHE_CONTROL(fmt, ...) \
-do { printf(CACHE_CONTROL: fmt , ## __VA_ARGS__); } while (0)
-#else
-#define DPRINTF_CACHE_CONTROL(fmt, ...) do {} while (0)
-#endif
+do { if (DEBUG_CACHE_CONTROL) { \
+printf(CACHE_CONTROL: fmt , ## __VA_ARGS__); \
+} } while (0)
#ifdef TARGET_SPARC64
#ifndef TARGET_ABI32
@@ -209,10 +197,10 @@ static void demap_tlb(SparcTLBEntry *tlb, target_ulong
demap_addr,
}
Re: [Qemu-devel] [RFC] Virtio-desktop: Virtio-based virtual desktop
Anup Patel anup.pa...@linaro.org writes: Hi All, How about having a generic Virtio-based machine for emulating a virtual desktop ? I know folks have already thought about this and probably also tried something or other on this front but, it will be good to know the downsides. Virtio-desktop can be a separate specification describing a virtual desktop. Of-course we cannot avoid few architecture dependent virtual devices in but the Virtio-desktop specification will try to keep minimum possible architecture dependent devices. There's a lot of reasons why a pure PV machine type is a bad idea. Lots of people have enumerated them in this thread. But let me mention some things that I think we don't have covered today with PV: - Graphics. Yes, I know QXL exists but it's (a) dependent on PCI (b) lacks the ability to gracefully degrade making it hopelessly tied to spice. - Input. PS/2 mouse provides relative input which sucks in guests. For absolute input, we have VMMouse which is x86-specific, USB tablets (which are expensive to emulate) or the spice mouse which is intimately tied to the full Spice stack. - Guest interaction. Copy/paste, drag and drop, etc. In theory this is covered in spice agents but it's all again hopelessly tied to Spice which makes it non-portable. So there's good work todo but it's almost certainly in working with the Spice community to try to make what they already have more accessible to non-x86 architectures. Regards, Anthony Liguori As per our thoughts, a Virtio-desktop will have two kinds of devices: 1. Architecture dependent devices: This devices will be emulated in-kernel by architecture specific code of KVM or Xen or Some other hypervisor. a) Virtualized CPU b) Virtualized PIC (i.e. in-kernel architecture specific emulation of irqchip) c) Virtualized Timer (i.e. in-kernel architecture specific emulation of timer chip) 2. Architecture independent devices: This are Virtio-based devices which are usually required by a desktop virtual machine. a) Virtio-blk (storage) - Already available b) Virtio-net (network) - Already available c) Virtio-fb (display) - It seems some work has been already done for Virtio frame buffer but I did not find drivers/fb/virtio-fb.c in latest kernel (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/42720) - Is Virtio-fb work still in-progress ?? d) Virtio-input (keyboard/mouse/multi-touch) - Currently not available - It will provide keyboard input events - It will provide mouse input events - It will provide multi-touch input events e) Virtio-power (reset/shutdown/enumeration) - It can provides info about the entire virtual machine including CPU, PIC, Timer, available Virtio devices, etc. - It can also provide CPU and Virtio-device hot-plugging - Its primary purpose would be to provide reset and shutdown of CPU and Virtio devices. - There will be only one instance of this device and its location will be fixed for each architecture. The Virtio-desktop specification may also describe a recommended memory map of for each architecture. Right now, only missing devices seems to be Virtio-fb, Virtio-input, and Virtio-power, which some of us are willing to take-up. IMHO, If we have something like Virtio-desktop specification then all possible guest OSes can have support for it and different hypervisor can emulate it without worrying about guest support. Best Regards, Anup
Re: [Qemu-devel] [RFC 16/19] target-ppc: Refactor debug output macros
Andreas Färber afaer...@suse.de writes:
Make debug output compile-testable even if disabled.
Inline DEBUG_OP check in excp_helper.c.
Inline LOG_MMU_STATE() in mmu_helper.c.
Inline PPC_DEBUG_SPR check in translate_init.c.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-ppc/excp_helper.c| 22 +++
target-ppc/kvm.c|9 ++-
target-ppc/mem_helper.c |2 --
target-ppc/mmu_helper.c | 63
+--
target-ppc/translate.c | 12 -
target-ppc/translate_init.c | 10 +++
6 Dateien geändert, 55 Zeilen hinzugefügt(+), 63 Zeilen entfernt(-)
diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
index 0a1ac86..54722c4 100644
--- a/target-ppc/excp_helper.c
+++ b/target-ppc/excp_helper.c
@@ -21,14 +21,14 @@
#include helper_regs.h
-//#define DEBUG_OP
-//#define DEBUG_EXCEPTIONS
+#define DEBUG_OP 0
+#define DEBUG_EXCEPTIONS 0
-#ifdef DEBUG_EXCEPTIONS
-# define LOG_EXCP(...) qemu_log(__VA_ARGS__)
-#else
-# define LOG_EXCP(...) do { } while (0)
-#endif
+#define LOG_EXCP(...) G_STMT_START \
+if (DEBUG_EXCEPTIONS) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
Just thinking out loud a bit.. This form becomes pretty common and it's
ashame to use a macro here if we don't have to.
I think:
static inline void LOG_EXCP(const char *fmt, ...)
{
if (debug_exceptions) {
va_list ap;
va_start(ap, fmt);
qemu_logv(fmt, ap);
va_end(ap);
}
}
Probably would have equivalent performance. debug_exception would be
read-mostly and ought to be very predictable as a result. I strongly
expect that the compiler would actually inline LOG_EXCP too.
I see LOG_EXCP and LOG_DIS in this series. Perhaps we could just
introduce these functions and then make these flags run-time
controllable?
BTW, one advantage of this over your original proposal back to your
point is that you still won't catch linker errors with your proposal.
Dead code eliminate will kill off those branches before the linker ever
sees them.
Regards,
Anthony Liguori
/*/
/* PowerPC Hypercall emulation */
@@ -777,7 +777,7 @@ void ppc_hw_interrupt(CPUPPCState *env)
}
#endif /* !CONFIG_USER_ONLY */
-#if defined(DEBUG_OP)
+#ifndef CONFIG_USER_ONLY
static void cpu_dump_rfi(target_ulong RA, target_ulong msr)
{
qemu_log(Return from exception at TARGET_FMT_lx with flags
@@ -835,9 +835,9 @@ static inline void do_rfi(CPUPPCState *env, target_ulong
nip, target_ulong msr,
/* XXX: beware: this is false if VLE is supported */
env-nip = nip ~((target_ulong)0x0003);
hreg_store_msr(env, msr, 1);
-#if defined(DEBUG_OP)
-cpu_dump_rfi(env-nip, env-msr);
-#endif
+if (DEBUG_OP) {
+cpu_dump_rfi(env-nip, env-msr);
+}
/* No need to raise an exception here,
* as rfi is always the last insn of a TB
*/
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 2f4f068..0dc6657 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -37,15 +37,10 @@
#include hw/spapr.h
#include hw/spapr_vio.h
-//#define DEBUG_KVM
+#define DEBUG_KVM 0
-#ifdef DEBUG_KVM
#define dprintf(fmt, ...) \
-do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
-#else
-#define dprintf(fmt, ...) \
-do { } while (0)
-#endif
+do { if (DEBUG_KVM) { fprintf(stderr, fmt, ## __VA_ARGS__); } } while (0)
#define PROC_DEVTREE_CPU /proc/device-tree/cpus/
diff --git a/target-ppc/mem_helper.c b/target-ppc/mem_helper.c
index 902b1cd..5c7a5ce 100644
--- a/target-ppc/mem_helper.c
+++ b/target-ppc/mem_helper.c
@@ -26,8 +26,6 @@
#include exec/softmmu_exec.h
#endif /* !defined(CONFIG_USER_ONLY) */
-//#define DEBUG_OP
-
/*/
/* Memory load and stores */
diff --git a/target-ppc/mmu_helper.c b/target-ppc/mmu_helper.c
index ee168f1..9340fbb 100644
--- a/target-ppc/mmu_helper.c
+++ b/target-ppc/mmu_helper.c
@@ -21,39 +21,36 @@
#include sysemu/kvm.h
#include kvm_ppc.h
-//#define DEBUG_MMU
-//#define DEBUG_BATS
-//#define DEBUG_SLB
-//#define DEBUG_SOFTWARE_TLB
+#define DEBUG_MMU 0
+#define DEBUG_BATS 0
+#define DEBUG_SLB 0
+#define DEBUG_SOFTWARE_TLB 0
//#define DUMP_PAGE_TABLES
-//#define DEBUG_SOFTWARE_TLB
//#define FLUSH_ALL_TLBS
-#ifdef DEBUG_MMU
-# define LOG_MMU(...) qemu_log(__VA_ARGS__)
-# define LOG_MMU_STATE(env) log_cpu_state((env), 0)
-#else
-# define LOG_MMU(...) do { } while (0)
-# define LOG_MMU_STATE(...) do { } while (0)
-#endif
-
-#ifdef DEBUG_SOFTWARE_TLB
-# define LOG_SWTLB(...) qemu_log(__VA_ARGS__)
-#else
-# define LOG_SWTLB(...) do { } while (0)
-#endif
-
-#ifdef DEBUG_BATS
-# define LOG_BATS(...) qemu_log(__VA_ARGS__)
-#else
-# define
[Qemu-devel] [RFC 15/19] target-openrisc: Refactor debug output macros
Make debug output compile-testable even if disabled.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-openrisc/translate.c | 20 ++--
1 Datei geändert, 10 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)
diff --git a/target-openrisc/translate.c b/target-openrisc/translate.c
index 1e1b30c..6f592d0 100644
--- a/target-openrisc/translate.c
+++ b/target-openrisc/translate.c
@@ -31,13 +31,13 @@
#define GEN_HELPER 1
#include helper.h
-#define OPENRISC_DISAS
+#define OPENRISC_DISAS 1
-#ifdef OPENRISC_DISAS
-# define LOG_DIS(...) qemu_log_mask(CPU_LOG_TB_IN_ASM, ## __VA_ARGS__)
-#else
-# define LOG_DIS(...) do { } while (0)
-#endif
+#define LOG_DIS(...) G_STMT_START \
+if (OPENRISC_DISAS) { \
+qemu_log_mask(CPU_LOG_TB_IN_ASM, ## __VA_ARGS__); \
+} \
+G_STMT_END
typedef struct DisasContext {
TranslationBlock *tb;
@@ -698,7 +698,7 @@ static void dec_misc(DisasContext *dc, uint32_t insn)
{
uint32_t op0, op1;
uint32_t ra, rb, rd;
-#ifdef OPENRISC_DISAS
+#if OPENRISC_DISAS
uint32_t L6, K5;
#endif
uint32_t I16, I5, I11, N26, tmp;
@@ -707,7 +707,7 @@ static void dec_misc(DisasContext *dc, uint32_t insn)
ra = extract32(insn, 16, 5);
rb = extract32(insn, 11, 5);
rd = extract32(insn, 21, 5);
-#ifdef OPENRISC_DISAS
+#if OPENRISC_DISAS
L6 = extract32(insn, 5, 6);
K5 = extract32(insn, 0, 5);
#endif
@@ -1340,11 +1340,11 @@ static void dec_compi(DisasContext *dc, uint32_t insn)
static void dec_sys(DisasContext *dc, uint32_t insn)
{
uint32_t op0;
-#ifdef OPENRISC_DISAS
+#if OPENRISC_DISAS
uint32_t K16;
#endif
op0 = extract32(insn, 16, 8);
-#ifdef OPENRISC_DISAS
+#if OPENRISC_DISAS
K16 = extract32(insn, 0, 16);
#endif
--
1.7.10.4
[Qemu-devel] [PATCH for-1.4 07/19] target-sparc: Fix debug output for DEBUG_MMU
Signed-off-by: Andreas Färber afaer...@suse.de --- target-sparc/ldst_helper.c |2 +- 1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-) diff --git a/target-sparc/ldst_helper.c b/target-sparc/ldst_helper.c index cf1bddf..7decd66 100644 --- a/target-sparc/ldst_helper.c +++ b/target-sparc/ldst_helper.c @@ -1850,7 +1850,7 @@ void helper_st_asi(CPUSPARCState *env, target_ulong addr, target_ulong val, DPRINTF_MMU(LSU change: 0x% PRIx64 - 0x% PRIx64 \n, oldreg, env-lsu); #ifdef DEBUG_MMU -dump_mmu(stdout, fprintf, env1); +dump_mmu(stdout, fprintf, env); #endif tlb_flush(env, 1); } -- 1.7.10.4
Re: [Qemu-devel] [QEMU RFC 0/2] Spying on Memory to implement ethernet can_recieve()
Peter Crosthwaite peter.crosthwa...@xilinx.com writes: Hi All, Have a bit of a tricky question about ethernet controllers. We are maintaining two ethernet controllers the cadence GEM and the Xilinx AXI Ethernet both of which are scatter gather (SG) DMA capable. The issue comes about when trying to impelement the can_recieve() function for each. For the sake of background, the ethernet can_recieve() function is used by net devices to signal to the net API that it cant consume data. As QEMU network interfaces are infinately faster than real hardware you need to implement this function to insulate against mass packet droppage. The can_recieve has no real hardware analog, the network devices would just drop the packets (but the packets would be comming at a much slower rate). For most devices, the return of this function is dependant on internal state of the device. However, for SGDMA, whether or not you can receive is dependent on the state of the SGDMA buffer descriptors, which are stored in RAM. So to properly implement can_receive() we need to spy on the contents of memory, to see if the next descriptor is valid. This is not too hard. The hard part is monitoring the descriptor for change after you have returned false from can recieve() so you can tell the net layer you are now ready. Essentially, you need to watch memory and wakup when the cpu writes to the magic address. Patch 1 is a hackish first attempt at this for the cadence GEM, using the Memory API. I don't think there's anything special here. This comes down to: how can a device emulation provide flow control information to the backend? There are two ways this works today in QEMU. Most devices have some sort of mailslot register that's notified when RX buffers are added to the descriptor ring. From that, you call qemu_flush_queued_packets() to start the flow again. virtio-net is an example of this. If there is truly no notification when adding descriptors, the only option is to use a timer to periodically poll the descriptor ring. This is how our USB controllers work. Trying to write-protect memory is a losing battle. You'll end up with a timer anyway to avoid constantly taking page faults. Regards, Anthony Liguori The alternative to this is to impelement timing for the ethernet device, which is truer to the real hardware. Throttle the ethernet trasffic based on wire speed, not the state of the ethernet controller. Ive had an attempt at this for the AXI Ethernet (Patch 2) but a proper solution to this would be to implement this wire side (in the net layer) rather than device side. Peter Crosthwaite (2): cadence_gem: Throttle traffic using buffer state xilinx_axienet: Model timing. hw/cadence_gem.c| 75 - hw/xilinx_axienet.c | 16 ++-- 2 files changed, 77 insertions(+), 14 deletions(-) -- 1.7.12.1.396.g16eed7c
[Qemu-devel] [PATCH for-1.4 02/19] target-ppc: Fix target_ulong vs. hwaddr format mismatches
To keep log format backwards compatible, cast to target_ulong
rather than using HWADDR_PRIx.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-ppc/mmu_helper.c |8 +---
1 Datei geändert, 5 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-)
diff --git a/target-ppc/mmu_helper.c b/target-ppc/mmu_helper.c
index 0aee7a9..14fa25a 100644
--- a/target-ppc/mmu_helper.c
+++ b/target-ppc/mmu_helper.c
@@ -589,7 +589,8 @@ static inline int find_pte2(CPUPPCState *env, mmu_ctx_t
*ctx, int is_64b, int h,
r = pte64_check(ctx, pte0, pte1, h, rw, type);
LOG_MMU(Load pte from TARGET_FMT_lx = TARGET_FMT_lx
TARGET_FMT_lx %d %d %d TARGET_FMT_lx \n,
-pteg_off + (i * 16), pte0, pte1, (int)(pte0 1), h,
+(target_ulong)pteg_off + (i * 16), pte0, pte1,
+(int)(pte0 1), h,
(int)((pte0 1) 1), ctx-ptem);
} else
#endif
@@ -604,7 +605,8 @@ static inline int find_pte2(CPUPPCState *env, mmu_ctx_t
*ctx, int is_64b, int h,
r = pte32_check(ctx, pte0, pte1, h, rw, type);
LOG_MMU(Load pte from TARGET_FMT_lx = TARGET_FMT_lx
TARGET_FMT_lx %d %d %d TARGET_FMT_lx \n,
-pteg_off + (i * 8), pte0, pte1, (int)(pte0 31), h,
+(target_ulong)pteg_off + (i * 8), pte0, pte1,
+(int)(pte0 31), h,
(int)((pte0 6) 1), ctx-ptem);
}
switch (r) {
@@ -634,7 +636,7 @@ static inline int find_pte2(CPUPPCState *env, mmu_ctx_t
*ctx, int is_64b, int h,
if (good != -1) {
done:
LOG_MMU(found PTE at addr TARGET_FMT_lx prot=%01x ret=%d\n,
-ctx-raddr, ctx-prot, ret);
+(target_ulong)ctx-raddr, ctx-prot, ret);
/* Update page flags */
pte1 = ctx-raddr;
if (pte_update_flags(ctx, pte1, ret, rw) == 1) {
--
1.7.10.4
Re: [Qemu-devel] [RFC] FDT as a git submodule?
Alexander Graf ag...@suse.de writes: Am 26.01.2013 um 19:13 schrieb Peter Crosthwaite peter.crosthwa...@xilinx.com: Hi All, On Sat, Jan 26, 2013 at 2:49 AM, Peter Maydell peter.mayd...@linaro.org wrote: On 26 January 2013 10:11, Andreas Färber afaer...@suse.de wrote: You forget that a distro is pretty much a Linux concept. There is no such thing on W32 (openSUSE doesn't package it for MinGW either), and on Darwin the various competing ports systems suck IMO. On OpenBSD there's a dtc port but we'd need to assure it's installed on the build bots before we mandate it, same for the Linux build bots. Even on Linux having a libfdt that's available to compile against is a comparatively recent thing -- it was only early 2012 IIRC that Debian/Ubuntu got this, for instance. I'm not objecting to mandating it but would like to propose to only mandate it for the targets that need it. I.e., if no libfdt available, don't install microblaze and ppc softmmu targets. That would still allow the average user to emulate x86 or arm without hassles, and it should not be needed for linux-user. Im not proposing to mandate it at all initially. Just setup the configurator such that if you --enable-fdt it gives you an option to submodule it rather than just hard failing at configure time. Its annoying to have to provide instructions for all the different distros for apt/yum or build from source for this component. A normal build of QEMU would be unaffected. I'm leaning towards making FDT compulsory for ARM too: the kernel is moving strongly in this direction and it is just annoying to get a qemu that gives up when it encounters an FDT. The only reason I haven't so far is just that availability in distros/OSes is too spotty. An in-tree libfdt would solve that. +1. The context of this for us is ARM as well not just out Microblaze/PPC targets. Zynq with no FDT is of limited use and will puke for anyone trying to boot Zynq Linux. The pixman submodule has not been working well for me, it's not a universally working solution to be copied either. OTOH libfdt is: * less than 4000 lines of code, half of which is the public .h file * specifically intended by upstream to be taken and dropped into other peoples' projects (this is how you have to use it if you're a bootloader, for instance) * built by just having your usual make process compile and link in an extra seven .c files I don't know if we'd use a git submodule though -- we only want a single subdir of upstream's git repo, not the whole thing. I kinda want to take a better than nothin philosophy here. If the upstream DTC is broken then you can still fall back to your distros. With the proposal as it stands, your distro FDT will take precedent over the submodule flow anyway. 4000 Lines is a pritty cheap download. Fair enough. Anthony, could you please create a mirror of dtc on git.qemu.org so we can create a submodule against it. Done. http://git.qemu.org/?p=dtc.git;a=tree Regards, Anthony Liguori Alex Regards, Peter -- PMM
[Qemu-devel] [RFC 16/19] target-ppc: Refactor debug output macros
Make debug output compile-testable even if disabled.
Inline DEBUG_OP check in excp_helper.c.
Inline LOG_MMU_STATE() in mmu_helper.c.
Inline PPC_DEBUG_SPR check in translate_init.c.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-ppc/excp_helper.c| 22 +++
target-ppc/kvm.c|9 ++-
target-ppc/mem_helper.c |2 --
target-ppc/mmu_helper.c | 63 +--
target-ppc/translate.c | 12 -
target-ppc/translate_init.c | 10 +++
6 Dateien geändert, 55 Zeilen hinzugefügt(+), 63 Zeilen entfernt(-)
diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
index 0a1ac86..54722c4 100644
--- a/target-ppc/excp_helper.c
+++ b/target-ppc/excp_helper.c
@@ -21,14 +21,14 @@
#include helper_regs.h
-//#define DEBUG_OP
-//#define DEBUG_EXCEPTIONS
+#define DEBUG_OP 0
+#define DEBUG_EXCEPTIONS 0
-#ifdef DEBUG_EXCEPTIONS
-# define LOG_EXCP(...) qemu_log(__VA_ARGS__)
-#else
-# define LOG_EXCP(...) do { } while (0)
-#endif
+#define LOG_EXCP(...) G_STMT_START \
+if (DEBUG_EXCEPTIONS) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
/*/
/* PowerPC Hypercall emulation */
@@ -777,7 +777,7 @@ void ppc_hw_interrupt(CPUPPCState *env)
}
#endif /* !CONFIG_USER_ONLY */
-#if defined(DEBUG_OP)
+#ifndef CONFIG_USER_ONLY
static void cpu_dump_rfi(target_ulong RA, target_ulong msr)
{
qemu_log(Return from exception at TARGET_FMT_lx with flags
@@ -835,9 +835,9 @@ static inline void do_rfi(CPUPPCState *env, target_ulong
nip, target_ulong msr,
/* XXX: beware: this is false if VLE is supported */
env-nip = nip ~((target_ulong)0x0003);
hreg_store_msr(env, msr, 1);
-#if defined(DEBUG_OP)
-cpu_dump_rfi(env-nip, env-msr);
-#endif
+if (DEBUG_OP) {
+cpu_dump_rfi(env-nip, env-msr);
+}
/* No need to raise an exception here,
* as rfi is always the last insn of a TB
*/
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 2f4f068..0dc6657 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -37,15 +37,10 @@
#include hw/spapr.h
#include hw/spapr_vio.h
-//#define DEBUG_KVM
+#define DEBUG_KVM 0
-#ifdef DEBUG_KVM
#define dprintf(fmt, ...) \
-do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
-#else
-#define dprintf(fmt, ...) \
-do { } while (0)
-#endif
+do { if (DEBUG_KVM) { fprintf(stderr, fmt, ## __VA_ARGS__); } } while (0)
#define PROC_DEVTREE_CPU /proc/device-tree/cpus/
diff --git a/target-ppc/mem_helper.c b/target-ppc/mem_helper.c
index 902b1cd..5c7a5ce 100644
--- a/target-ppc/mem_helper.c
+++ b/target-ppc/mem_helper.c
@@ -26,8 +26,6 @@
#include exec/softmmu_exec.h
#endif /* !defined(CONFIG_USER_ONLY) */
-//#define DEBUG_OP
-
/*/
/* Memory load and stores */
diff --git a/target-ppc/mmu_helper.c b/target-ppc/mmu_helper.c
index ee168f1..9340fbb 100644
--- a/target-ppc/mmu_helper.c
+++ b/target-ppc/mmu_helper.c
@@ -21,39 +21,36 @@
#include sysemu/kvm.h
#include kvm_ppc.h
-//#define DEBUG_MMU
-//#define DEBUG_BATS
-//#define DEBUG_SLB
-//#define DEBUG_SOFTWARE_TLB
+#define DEBUG_MMU 0
+#define DEBUG_BATS 0
+#define DEBUG_SLB 0
+#define DEBUG_SOFTWARE_TLB 0
//#define DUMP_PAGE_TABLES
-//#define DEBUG_SOFTWARE_TLB
//#define FLUSH_ALL_TLBS
-#ifdef DEBUG_MMU
-# define LOG_MMU(...) qemu_log(__VA_ARGS__)
-# define LOG_MMU_STATE(env) log_cpu_state((env), 0)
-#else
-# define LOG_MMU(...) do { } while (0)
-# define LOG_MMU_STATE(...) do { } while (0)
-#endif
-
-#ifdef DEBUG_SOFTWARE_TLB
-# define LOG_SWTLB(...) qemu_log(__VA_ARGS__)
-#else
-# define LOG_SWTLB(...) do { } while (0)
-#endif
-
-#ifdef DEBUG_BATS
-# define LOG_BATS(...) qemu_log(__VA_ARGS__)
-#else
-# define LOG_BATS(...) do { } while (0)
-#endif
-
-#ifdef DEBUG_SLB
-# define LOG_SLB(...) qemu_log(__VA_ARGS__)
-#else
-# define LOG_SLB(...) do { } while (0)
-#endif
+#define LOG_MMU(...) G_STMT_START \
+if (DEBUG_MMU) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
+
+#define LOG_SWTLB(...) G_STMT_START \
+if (DEBUG_SOFTWARE_TLB) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
+
+#define LOG_BATS(...) G_STMT_START \
+if (DEBUG_BATS) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
+
+#define LOG_SLB(...) G_STMT_START \
+if (DEBUG_SLB) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
/*/
/* PowerPC MMU emulation */
@@ -534,7 +531,7 @@ static inline int get_bat(CPUPPCState *env, mmu_ctx_t *ctx,
}
}
if (ret 0) {
-#if defined(DEBUG_BATS)
+#if DEBUG_BATS
if (qemu_log_enabled()) {
LOG_BATS(no BAT match for TARGET_FMT_lx :\n, virtual);
for (i = 0; i 4; i++) {
@@ -1860,7 +1857,9 @@
Re: [Qemu-devel] [RFC 16/19] target-ppc: Refactor debug output macros
Am 27.01.2013 15:14, schrieb Anthony Liguori:
Andreas Färber afaer...@suse.de writes:
diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
index 0a1ac86..54722c4 100644
--- a/target-ppc/excp_helper.c
+++ b/target-ppc/excp_helper.c
@@ -21,14 +21,14 @@
#include helper_regs.h
-//#define DEBUG_OP
-//#define DEBUG_EXCEPTIONS
+#define DEBUG_OP 0
+#define DEBUG_EXCEPTIONS 0
-#ifdef DEBUG_EXCEPTIONS
-# define LOG_EXCP(...) qemu_log(__VA_ARGS__)
-#else
-# define LOG_EXCP(...) do { } while (0)
-#endif
+#define LOG_EXCP(...) G_STMT_START \
+if (DEBUG_EXCEPTIONS) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
Just thinking out loud a bit.. This form becomes pretty common and it's
ashame to use a macro here if we don't have to.
I think:
static inline void LOG_EXCP(const char *fmt, ...)
{
if (debug_exceptions) {
va_list ap;
va_start(ap, fmt);
qemu_logv(fmt, ap);
va_end(ap);
}
}
Probably would have equivalent performance. debug_exception would be
read-mostly and ought to be very predictable as a result. I strongly
expect that the compiler would actually inline LOG_EXCP too.
Thanks for your early feedback. I merely tried to stay close to the
original code. I wouldn't mind inline functions either. Or even more
harmonization for that matter.
I see LOG_EXCP and LOG_DIS in this series. Perhaps we could just
introduce these functions and then make these flags run-time
controllable?
I was feeling conservative during that series in light of compile-time
decided conditional; if we want to go down that route we should probably
sprinkle quite some unlikely()s for optimization.
I think the if (0) { ... } approach would already catch a few things. As
a next step, some mechanism as proposed by Peter C. (?) to enable things
at configure-time could be built on top. Run-time would need some
stabilization phase to avoid command line compatibility issues.
BTW, one advantage of this over your original proposal back to your
point is that you still won't catch linker errors with your proposal.
Dead code eliminate will kill off those branches before the linker ever
sees them.
Linker errors would be limited to renamed/dropped/#ifdef'ed functions,
wouldn't they? In the past I caught that using existing --enable-debug.
My recurring issue is overlooking env-something after removing fields
from CPU_COMMON/CPUArchState. I was hoping that to be caught inside
if (0) { ... } during my 3x KVM + BSD + MinGW builds rather than
patching individual files.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH for-1.4 05/19] target-s390x: Fix debug output
Commit 71e470886fb6092504503a5fe41092ace71c096c (target-s390x: fix style) renamed the cpu_s390x_handle_mmu_fault() argument from _vaddr to orig_vaddr. Update the debug output code. Signed-off-by: Andreas Färber afaer...@suse.de --- target-s390x/helper.c |2 +- 1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-) diff --git a/target-s390x/helper.c b/target-s390x/helper.c index 9a132e6..a6af542 100644 --- a/target-s390x/helper.c +++ b/target-s390x/helper.c @@ -387,7 +387,7 @@ int cpu_s390x_handle_mmu_fault(CPUS390XState *env, target_ulong orig_vaddr, int prot; DPRINTF(%s: address 0x% PRIx64 rw %d mmu_idx %d\n, -__func__, _vaddr, rw, mmu_idx); +__func__, orig_vaddr, rw, mmu_idx); orig_vaddr = TARGET_PAGE_MASK; vaddr = orig_vaddr; -- 1.7.10.4
Re: [Qemu-devel] [PATCH qom-cpu for-1.4 00/14] QOM CPU fixes for 1.4
Am 26.01.2013 18:16, schrieb Andreas Färber: Am 23.01.2013 13:07, schrieb Andreas Färber: Hello, This series fixes a number of bugs surrounding QOM CPU instantiation. Please ack. Ping. First, two remaining users of type_register_static() for iterative CPU type registration are moved over to type_register(). TBD: better commit message Second, error checking for -cpu some-random-type is added. This also prepares infrastructure for converting arm, m68k, or32 and uc32 to the new name-arch-cpu type name scheme in follow-up series. Third, error checking for -cpu arch-cpu and any future abstract sub-types is added. A new object_class_is_abstract() accessor function is needed. Note that the ppc target got around this by using object_class_get_list() rather than object_class_by_name(). I have applied minor style tweaks for arm and fixed two trivial bugs for openrisc and unicore32: https://github.com/afaerber/qemu-cpu/commits/qom-cpu-types If there are no more objections, I will apply 3-14 to qom-cpu tonight Done: https://github.com/afaerber/qemu-cpu/commits/qom-cpu Andreas with a goal of sending a pull early next week. This shall serve as base for getting rid of the unfortunate any types that are now a device, therefore the Hard Freeze-induced time pressure. The CPU realizefn series will need to be rebased on this one (class_init). https://github.com/afaerber/qemu-cpu/commits/qom-cpu-realize There were a few acks already, so once the prereqs from this type bugfix series are in qom-cpu, I will apply the realizefn series to qom-cpu-next as base for SuperH, X86CPU and further CPU subclasses. Andreas Regards, Andreas Cc: Peter Maydell peter.mayd...@linaro.org Cc: Richard Henderson r...@twiddle.net Cc: Jia Liu pro...@gmail.com Cc: Guan Xuetao g...@mprc.pku.edu.cn Cc: Alexander Graf ag...@suse.de Cc: Anthony Liguori anth...@codemonkey.ws Andreas Färber (14): target-openrisc: Don't use type_register_static() target-unicore32: Don't use type_register_static() cpu: Add model resolution support to CPUClass target-arm: Detect attempt to instantiate non-CPU type in cpu_init() target-alpha: Detect attempt to instantiate non-CPU type in cpu_init() target-m68k: Detect attempt to instantiate non-CPU type in cpu_init() target-openrisc: Detect attempt to instantiate non-CPU type in cpu_init() target-unicore32: Detect attempt to instantiate non-CPU type in cpu_init() qom: Introduce object_class_is_abstract() target-alpha: Catch attempt to instantiate abstract type in cpu_init() target-arm: Catch attempt to instantiate abstract type in cpu_init() target-m68k: Catch attempt to instantiate abstract type in cpu_init() target-openrisc: Catch attempt to instantiate abstract type in cpu_init() target-unicore32: Catch attempt to instantiate abstract type in cpu_init() include/qom/cpu.h | 13 + include/qom/object.h|8 qom/cpu.c | 13 + qom/object.c|5 + target-alpha/cpu.c | 16 ++-- target-arm/cpu.c| 18 ++ target-arm/helper.c |6 -- target-m68k/cpu.c | 18 ++ target-m68k/helper.c|6 -- target-openrisc/cpu.c | 27 --- target-ppc/translate_init.c |2 ++ target-unicore32/cpu.c | 26 +- target-unicore32/helper.c |4 +++- 13 Dateien geändert, 151 Zeilen hinzugefügt(+), 11 Zeilen entfernt(-) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [RFC 17/19] target-s390x: Refactor debug output macros
Make debug output compile-testable even if disabled.
Inline S390X_DEBUG_DISAS in translate.c.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-s390x/cc_helper.c | 13 +++--
target-s390x/fpu_helper.c | 13 +++--
target-s390x/helper.c | 42 ++
target-s390x/int_helper.c | 13 +++--
target-s390x/kvm.c |9 ++---
target-s390x/mem_helper.c | 13 +++--
target-s390x/misc_helper.c | 13 +++--
target-s390x/translate.c | 18 --
8 Dateien geändert, 63 Zeilen hinzugefügt(+), 71 Zeilen entfernt(-)
diff --git a/target-s390x/cc_helper.c b/target-s390x/cc_helper.c
index a6d60bf..a6fad6a 100644
--- a/target-s390x/cc_helper.c
+++ b/target-s390x/cc_helper.c
@@ -22,12 +22,13 @@
#include helper.h
#include qemu/host-utils.h
-/* #define DEBUG_HELPER */
-#ifdef DEBUG_HELPER
-#define HELPER_LOG(x...) qemu_log(x)
-#else
-#define HELPER_LOG(x...)
-#endif
+#define DEBUG_HELPER 0
+
+#define HELPER_LOG(...) G_STMT_START \
+if (DEBUG_HELPER) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
static uint32_t cc_calc_ltgt_32(int32_t src, int32_t dst)
{
diff --git a/target-s390x/fpu_helper.c b/target-s390x/fpu_helper.c
index 94375b6..aba5e2c 100644
--- a/target-s390x/fpu_helper.c
+++ b/target-s390x/fpu_helper.c
@@ -25,12 +25,13 @@
#include exec/softmmu_exec.h
#endif
-/* #define DEBUG_HELPER */
-#ifdef DEBUG_HELPER
-#define HELPER_LOG(x...) qemu_log(x)
-#else
-#define HELPER_LOG(x...)
-#endif
+#define DEBUG_HELPER 0
+
+#define HELPER_LOG(...) G_STMT_START \
+if (DEBUG_HELPER) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
#define RET128(F) (env-retxl = F.low, F.high)
diff --git a/target-s390x/helper.c b/target-s390x/helper.c
index 76fd558..90d62db 100644
--- a/target-s390x/helper.c
+++ b/target-s390x/helper.c
@@ -25,30 +25,24 @@
#include sysemu/sysemu.h
#endif
-//#define DEBUG_S390
-//#define DEBUG_S390_PTE
-//#define DEBUG_S390_STDOUT
-
-#ifdef DEBUG_S390
-#ifdef DEBUG_S390_STDOUT
-#define DPRINTF(fmt, ...) \
-do { fprintf(stderr, fmt, ## __VA_ARGS__); \
- qemu_log(fmt, ##__VA_ARGS__); } while (0)
-#else
-#define DPRINTF(fmt, ...) \
-do { qemu_log(fmt, ## __VA_ARGS__); } while (0)
-#endif
-#else
-#define DPRINTF(fmt, ...) \
-do { } while (0)
-#endif
-
-#ifdef DEBUG_S390_PTE
-#define PTE_DPRINTF DPRINTF
-#else
-#define PTE_DPRINTF(fmt, ...) \
-do { } while (0)
-#endif
+#define DEBUG_S390 0
+#define DEBUG_S390_PTE 0
+#define DEBUG_S390_STDOUT 0
+
+#define DPRINTF(fmt, ...) G_STMT_START \
+if (DEBUG_S390) { \
+if (DEBUG_S390_STDOUT) { \
+fprintf(stderr, fmt, ## __VA_ARGS__); \
+} \
+qemu_log(fmt, ## __VA_ARGS__); \
+} \
+G_STMT_END
+
+#define PTE_DPRINTF(fmt, ...) G_STMT_START \
+if (DEBUG_S390_PTE) { \
+DPRINTF(fmt, ## __VA_ARGS__); \
+} \
+G_STMT_END
#ifndef CONFIG_USER_ONLY
void s390x_tod_timer(void *opaque)
diff --git a/target-s390x/int_helper.c b/target-s390x/int_helper.c
index 6858301..acf2de0 100644
--- a/target-s390x/int_helper.c
+++ b/target-s390x/int_helper.c
@@ -22,12 +22,13 @@
#include qemu/host-utils.h
#include helper.h
-/* #define DEBUG_HELPER */
-#ifdef DEBUG_HELPER
-#define HELPER_LOG(x...) qemu_log(x)
-#else
-#define HELPER_LOG(x...)
-#endif
+#define DEBUG_HELPER 0
+
+#define HELPER_LOG(...) G_STMT_START \
+if (DEBUG_HELPER) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
/* 64/64 - 128 unsigned multiplication */
uint64_t HELPER(mul128)(CPUS390XState *env, uint64_t v1, uint64_t v2)
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index add6a58..ee4c7f9 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -35,15 +35,10 @@
#include cpu.h
#include sysemu/device_tree.h
-/* #define DEBUG_KVM */
+#define DEBUG_KVM 0
-#ifdef DEBUG_KVM
#define dprintf(fmt, ...) \
-do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
-#else
-#define dprintf(fmt, ...) \
-do { } while (0)
-#endif
+do { if (DEBUG_KVM) { fprintf(stderr, fmt, ## __VA_ARGS__); } } while (0)
#define IPA0_DIAG 0x8300
#define IPA0_SIGP 0xae00
diff --git a/target-s390x/mem_helper.c b/target-s390x/mem_helper.c
index 372334b..99e3d45 100644
--- a/target-s390x/mem_helper.c
+++ b/target-s390x/mem_helper.c
@@ -61,12 +61,13 @@ void tlb_fill(CPUS390XState *env, target_ulong addr, int
is_write, int mmu_idx,
#endif
-/* #define DEBUG_HELPER */
-#ifdef DEBUG_HELPER
-#define HELPER_LOG(x...) qemu_log(x)
-#else
-#define HELPER_LOG(x...)
-#endif
+#define DEBUG_HELPER 0
+
+#define HELPER_LOG(...) G_STMT_START \
+if (DEBUG_HELPER) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
#ifndef CONFIG_USER_ONLY
static void mvc_fast_memset(CPUS390XState *env, uint32_t l, uint64_t dest,
diff --git a/target-s390x/misc_helper.c b/target-s390x/misc_helper.c
index
Re: [Qemu-devel] [RFC 16/19] target-ppc: Refactor debug output macros
On 27.01.2013, at 15:35, Andreas Färber wrote:
Am 27.01.2013 15:14, schrieb Anthony Liguori:
Andreas Färber afaer...@suse.de writes:
diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
index 0a1ac86..54722c4 100644
--- a/target-ppc/excp_helper.c
+++ b/target-ppc/excp_helper.c
@@ -21,14 +21,14 @@
#include helper_regs.h
-//#define DEBUG_OP
-//#define DEBUG_EXCEPTIONS
+#define DEBUG_OP 0
+#define DEBUG_EXCEPTIONS 0
-#ifdef DEBUG_EXCEPTIONS
-# define LOG_EXCP(...) qemu_log(__VA_ARGS__)
-#else
-# define LOG_EXCP(...) do { } while (0)
-#endif
+#define LOG_EXCP(...) G_STMT_START \
+if (DEBUG_EXCEPTIONS) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
Just thinking out loud a bit.. This form becomes pretty common and it's
ashame to use a macro here if we don't have to.
I think:
static inline void LOG_EXCP(const char *fmt, ...)
{
if (debug_exceptions) {
va_list ap;
va_start(ap, fmt);
qemu_logv(fmt, ap);
va_end(ap);
}
}
Probably would have equivalent performance. debug_exception would be
read-mostly and ought to be very predictable as a result. I strongly
expect that the compiler would actually inline LOG_EXCP too.
Thanks for your early feedback. I merely tried to stay close to the
original code. I wouldn't mind inline functions either. Or even more
harmonization for that matter.
I fully agree. Just recently Scott revamped the openpic debug print code:
//#define DEBUG_OPENPIC
#ifdef DEBUG_OPENPIC
static const int debug_openpic = 1;
#else
static const int debug_openpic = 0;
#endif
#define DPRINTF(fmt, ...) do { \
if (debug_openpic) { \
printf(fmt , ## __VA_ARGS__); \
} \
} while (0)
I like that approach. It keeps all users identical. The #define stays
identical. The callers stay identical. But we do get proper compile time
checks. Of course Anthony's approach works too, but the thing I'd definitely
like to see is that the #defines don't become numerical, but rather stay of an
#ifdef basis.
Alex
[Qemu-devel] [RFC 13/19] target-lm32: Refactor debug output macros
Already enabled and thus compile-tested, but align with other targets.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-lm32/translate.c | 10 +-
1 Datei geändert, 5 Zeilen hinzugefügt(+), 5 Zeilen entfernt(-)
diff --git a/target-lm32/translate.c b/target-lm32/translate.c
index 6b87340..01ef79a 100644
--- a/target-lm32/translate.c
+++ b/target-lm32/translate.c
@@ -28,11 +28,11 @@
#include helper.h
#define DISAS_LM32 1
-#if DISAS_LM32
-# define LOG_DIS(...) qemu_log_mask(CPU_LOG_TB_IN_ASM, ## __VA_ARGS__)
-#else
-# define LOG_DIS(...) do { } while (0)
-#endif
+#define LOG_DIS(...) G_STMT_START \
+if (DISAS_LM32) { \
+qemu_log_mask(CPU_LOG_TB_IN_ASM, ## __VA_ARGS__); \
+} \
+G_STMT_END
#define EXTRACT_FIELD(src, start, end) \
(((src) start) ((1 (end - start + 1)) - 1))
--
1.7.10.4
Re: [Qemu-devel] [RFC 16/19] target-ppc: Refactor debug output macros
Am 27.01.2013 15:46, schrieb Alexander Graf:
On 27.01.2013, at 15:35, Andreas Färber wrote:
Am 27.01.2013 15:14, schrieb Anthony Liguori:
Andreas Färber afaer...@suse.de writes:
diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
index 0a1ac86..54722c4 100644
--- a/target-ppc/excp_helper.c
+++ b/target-ppc/excp_helper.c
@@ -21,14 +21,14 @@
#include helper_regs.h
-//#define DEBUG_OP
-//#define DEBUG_EXCEPTIONS
+#define DEBUG_OP 0
+#define DEBUG_EXCEPTIONS 0
-#ifdef DEBUG_EXCEPTIONS
-# define LOG_EXCP(...) qemu_log(__VA_ARGS__)
-#else
-# define LOG_EXCP(...) do { } while (0)
-#endif
+#define LOG_EXCP(...) G_STMT_START \
+if (DEBUG_EXCEPTIONS) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
Just thinking out loud a bit.. This form becomes pretty common and it's
ashame to use a macro here if we don't have to.
I think:
static inline void LOG_EXCP(const char *fmt, ...)
{
if (debug_exceptions) {
va_list ap;
va_start(ap, fmt);
qemu_logv(fmt, ap);
va_end(ap);
}
}
Probably would have equivalent performance. debug_exception would be
read-mostly and ought to be very predictable as a result. I strongly
expect that the compiler would actually inline LOG_EXCP too.
Thanks for your early feedback. I merely tried to stay close to the
original code. I wouldn't mind inline functions either. Or even more
harmonization for that matter.
I fully agree. Just recently Scott revamped the openpic debug print code:
//#define DEBUG_OPENPIC
#ifdef DEBUG_OPENPIC
static const int debug_openpic = 1;
#else
static const int debug_openpic = 0;
#endif
#define DPRINTF(fmt, ...) do { \
if (debug_openpic) { \
printf(fmt , ## __VA_ARGS__); \
} \
} while (0)
Like :)
I'll wait for more feedback from affected maintainers though before I
redo or widen this series.
Or were you proposing to do a ppc-only refactoring à la Scott for 1.4?
Andreas
I like that approach. It keeps all users identical. The #define stays
identical. The callers stay identical. But we do get proper compile time
checks. Of course Anthony's approach works too, but the thing I'd definitely
like to see is that the #defines don't become numerical, but rather stay of
an #ifdef basis.
Alex
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [RFC 11/19] target-cris: Refactor debug output macros
Make debug output compile-testable even if disabled.
Introduce DPRINTF() in helper.c and consolidate stdout and stderr
output.
Introduce DPRINTF() in mmu.c and inline remaining D(x).
Drop unused D(x) macro in op_helper.c.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-cris/helper.c| 21 +
target-cris/mmu.c | 58 +++
target-cris/op_helper.c | 15 +---
target-cris/translate.c | 18 ---
4 Dateien geändert, 56 Zeilen hinzugefügt(+), 56 Zeilen entfernt(-)
diff --git a/target-cris/helper.c b/target-cris/helper.c
index de04143..31bf358 100644
--- a/target-cris/helper.c
+++ b/target-cris/helper.c
@@ -23,16 +23,17 @@
#include qemu/host-utils.h
-//#define CRIS_HELPER_DEBUG
+#define CRIS_HELPER_DEBUG 0
+#define D_LOG(...) G_STMT_START \
+if (CRIS_HELPER_DEBUG) { \
+qemu_log(__VA_ARGS__); \
+} G_STMT_END
-#ifdef CRIS_HELPER_DEBUG
-#define D(x) x
-#define D_LOG(...) qemu_log(__VA_ARGS__)
-#else
-#define D(x)
-#define D_LOG(...) do { } while (0)
-#endif
+#define DPRINTF(...) G_STMT_START \
+if (CRIS_HELPER_DEBUG) { \
+fprintf(stderr, ## __VA_ARGS__); \
+} G_STMT_END
#if defined(CONFIG_USER_ONLY)
@@ -71,7 +72,7 @@ int cpu_cris_handle_mmu_fault(CPUCRISState *env, target_ulong
address, int rw,
int r = -1;
target_ulong phy;
-D(printf(%s addr=%x pc=%x rw=%x\n, __func__, address, env-pc, rw));
+DPRINTF(%s addr=%x pc=%x rw=%x\n, __func__, address, env-pc, rw);
miss = cris_mmu_translate(res, env, address TARGET_PAGE_MASK,
rw, mmu_idx, 0);
if (miss) {
@@ -259,7 +260,7 @@ hwaddr cpu_get_phys_page_debug(CPUCRISState * env,
target_ulong addr)
if (!miss) {
phy = res.phy;
}
-D(fprintf(stderr, %s %x - %x\n, __func__, addr, phy));
+DPRINTF(%s %x - %x\n, __func__, addr, phy);
return phy;
}
#endif
diff --git a/target-cris/mmu.c b/target-cris/mmu.c
index ee31e2a..f930230 100644
--- a/target-cris/mmu.c
+++ b/target-cris/mmu.c
@@ -24,13 +24,23 @@
#include mmu.h
#ifdef DEBUG
-#define D(x) x
-#define D_LOG(...) qemu_log(__VA_ARGS__)
+#define CRIS_ENABLE_DEBUG 1
#else
-#define D(x) do { } while (0)
-#define D_LOG(...) do { } while (0)
+#define CRIS_ENABLE_DEBUG 0
#endif
+#define DPRINTF(...) G_STMT_START \
+if (CRIS_ENABLE_DEBUG) { \
+printf(__VA_ARGS__); \
+} \
+G_STMT_END
+
+#define D_LOG(...) G_STMT_START \
+if (CRIS_ENABLE_DEBUG) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
+
void cris_mmu_init(CPUCRISState *env)
{
env-mmu_rand_lfsr = 0x;
@@ -105,7 +115,6 @@ static inline void set_field(uint32_t *dst, unsigned int
val,
*dst |= val;
}
-#ifdef DEBUG
static void dump_tlb(CPUCRISState *env, int mmu)
{
int set;
@@ -124,7 +133,6 @@ static void dump_tlb(CPUCRISState *env, int mmu)
}
}
}
-#endif
/* rw 0 = read, 1 = write, 2 = exec. */
static int cris_mmu_translate_page(struct cris_mmu_result *res,
@@ -225,23 +233,23 @@ static int cris_mmu_translate_page(struct cris_mmu_result
*res,
set_exception_vector(0x0b, d_mmu_write);
*/
if (cfg_k tlb_k usermode) {
-D(printf(tlb: kernel protected %x lo=%x pc=%x\n,
- vaddr, lo, env-pc));
+DPRINTF(tlb: kernel protected %x lo=%x pc=%x\n,
+vaddr, lo, env-pc);
match = 0;
res-bf_vec = vect_base + 2;
} else if (rw == 1 cfg_w !tlb_w) {
-D(printf(tlb: write protected %x lo=%x pc=%x\n,
- vaddr, lo, env-pc));
+DPRINTF(tlb: write protected %x lo=%x pc=%x\n,
+vaddr, lo, env-pc);
match = 0;
/* write accesses never go through the I mmu. */
res-bf_vec = vect_base + 3;
} else if (rw == 2 cfg_x !tlb_x) {
-D(printf(tlb: exec protected %x lo=%x pc=%x\n,
- vaddr, lo, env-pc));
+DPRINTF(tlb: exec protected %x lo=%x pc=%x\n,
+vaddr, lo, env-pc);
match = 0;
res-bf_vec = vect_base + 3;
} else if (cfg_v !tlb_v) {
-D(printf(tlb: invalid %x\n, vaddr));
+DPRINTF(tlb: invalid %x\n, vaddr);
match = 0;
res-bf_vec = vect_base + 1;
}
@@ -256,7 +264,9 @@ static int cris_mmu_translate_page(struct cris_mmu_result
*res,
res-prot |= PAGE_EXEC;
}
} else {
-D(dump_tlb(env, mmu));
+if (CRIS_ENABLE_DEBUG) {
+dump_tlb(env, mmu);
+}
}
} else {
/* If refill, provide a randomized set. */
@@ -279,18 +289,18 @@ static int cris_mmu_translate_page(struct cris_mmu_result
*res,
set_field(r_cause, vpage, 13, 19);
set_field(r_cause, pid, 0, 8);
[Qemu-devel] [RFC 00/19] Debug output revamp
Hello,
Based on a suggestion from Igor Mitsyanko, this series aims to expose
debug output to compile-testing, so that it doesn't constantly break.
The basic requirement is to move format strings and arguments out of
#ifdef sections or no-op macros, so that the C compiler sees them.
For one thing this is to catch existing, e.g., %x - HWADDR_PRIx breakages,
so that debug output still can be enabled when needed.
For another it is to assist in catching refactored, e.g., CPU_COMMON fields,
to not break things further in new patches.
When I passed on Igor's idea to Fred, Anthony rejected it due to inconsistency.
Thus the solution is not to put our heads in the sand but to do the legwork of
harmonizing things in one big effort if incremental improvements are undesired.
This RFC series therefore updates all targets (which happens to be where the
bulk of my CPUState refactorings happens), leaving devices for a v2.
Anthony brought up the issue that an if { ... } inside the macro might cause
unpredictable effects. In theory our Coding Style forbids affected uses such as
if (foo) DPRINTF(bar) else baz; but in practice not all code is converted,
so use G_STMT_START ... G_STMT_END to shield against this. That allows to
redefine them to no-op if so desired one day.
Note that checkpatch.pl does not seem to understand that this effectively is
do { ... } while (0).
In some cases I took the liberty of simplifying D(qemu_log(...)) to D_LOG(...)
or D(printf(...)) to DPRINTF(...), as D(x) might be used for variable
declarations (in my case CPUState, prompting this series), unsuited for an
if (foo) { ... } block.
target-mips was already using this pattern.
target-cris was partially using it.
target-{arm,xtensa} didn't seem to have any such debug output.
target-m68k/translate.c has a DEBUG_DISPATCH further down; it indirects the
function call and only logs the name, so leave as is.
target-microblaze/helper.c:do_interrupt() has some commented-out debug code,
but it accesses MB internals only, so leaving to maintainers.
target-ppc/mmu_helper.c has failing debug code for DUMP_PAGE_TABLES involving
non-existing sdr and mask variables that I couldn't find a quick fix for.
Alex, please check!
target-sh4/translate.c has a commented-out DEBUG_DISAS macro that conflicts
with the one defined in include/exec/exec-all.h, therefore untouched.
Aurélien, should we rename it or drop the commented-out definition?
target-sparc/int{32,64}_helper.c have a DEBUG_PCALL that seemed too heavyweight;
same for some statistics or dump options in other targets, unlikely to be
affected by tree-wide refactorings and thus the maintainer's problem. ;)
Patches 1-7 are bug fixes found by enabling today's debug output.
Patches 8-9 are preparatory Coding Style cleanups.
Patches 10-19 do the actual macro refactoring per target-*/.
Available from:
git://github.com/afaerber/qemu-cpu.git dprintf.v1
https://github.com/afaerber/qemu-cpu/commits/dprintf.v1
My immediate quest is finding a solution for target-cris/helper.c, where I ran
into an issue moving the interrupt_request field to CPUState, since there is a
lonely usage inside a D_LOG() (plus my changes causing checkpatch.pl warnings).
https://github.com/afaerber/qemu-cpu/commit/cb9d472dda6efcd578a86df9c1b43510a0837e0d#diff-30
Regards,
Andreas
From individual patches:
* cris __VA__ARGS__ build fix was applied already.
* cris build fix and one cleanup sent out already are resent for testability.
Cc: Anthony Liguori anth...@codemonkey.ws
Cc: Blue Swirl blauwir...@gmail.com
Cc: Igor Mitsyanko i.mitsya...@samsung.com
Cc: Fréderic Konrad fred.kon...@greensocs.com
Cc: Edgar E. Iglesias edgar.igles...@gmail.com (cris)
Cc: Alexander Graf ag...@suse.de (ppc)
Cc: Aurélien Jarno aurel...@aurel32.net (sh4)
Cc: qemu-...@nongnu.org
Cc: Richard Henderson r...@twiddle.net (i386, s390x)
Cc: Michael Walle mich...@walle.cc (lm32)
Cc: Peter Crosthwaite peter.crosthwa...@xilinx.com (mblaze)
Cc: Jia Liu pro...@gmail.com (or32)
Cc: Guan Xuetao g...@mprc.pku.edu.cn (uc32)
Andreas Färber (19):
target-cris: Build fix for debug output
target-ppc: Fix target_ulong vs. hwaddr format mismatches
target-ppc: Fix unused variable warning for FLUSH_ALL_TLBS
target-ppc: Fix build for PPC_DEBUG_DISAS
target-s390x: Fix debug output
target-s390x: Fix debug output (continued)
target-sparc: Fix debug output for DEBUG_MMU
target-cris/helper.c: Update Coding Style
target-cris/mmu.c: Update Coding Style of cris_mmu_translate_page()
target-alpha: Refactor debug output macros
target-cris: Refactor debug output macros
target-i386: Refactor debug output macros
target-lm32: Refactor debug output macros
target-microblaze: Refactor debug output macros
target-openrisc: Refactor debug output macros
target-ppc: Refactor debug output macros
target-s390x: Refactor debug output macros
target-sparc: Refactor debug output macros
target-unicore32: Refactor debug output macros
target-alpha/translate.c | 12 +-
[Qemu-devel] [PATCH for-1.4? 09/19] target-cris/mmu.c: Update Coding Style of cris_mmu_translate_page()
Reindent, add braces, adjust whitespace.
Prepares for touching the logging macros.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-cris/mmu.c | 312 +++--
1 Datei geändert, 160 Zeilen hinzugefügt(+), 152 Zeilen entfernt(-)
diff --git a/target-cris/mmu.c b/target-cris/mmu.c
index 512e28b..ee31e2a 100644
--- a/target-cris/mmu.c
+++ b/target-cris/mmu.c
@@ -131,161 +131,169 @@ static int cris_mmu_translate_page(struct
cris_mmu_result *res,
CPUCRISState *env, uint32_t vaddr,
int rw, int usermode, int debug)
{
- unsigned int vpage;
- unsigned int idx;
- uint32_t pid, lo, hi;
- uint32_t tlb_vpn, tlb_pfn = 0;
- int tlb_pid, tlb_g, tlb_v, tlb_k, tlb_w, tlb_x;
- int cfg_v, cfg_k, cfg_w, cfg_x;
- int set, match = 0;
- uint32_t r_cause;
- uint32_t r_cfg;
- int rwcause;
- int mmu = 1; /* Data mmu is default. */
- int vect_base;
-
- r_cause = env-sregs[SFR_R_MM_CAUSE];
- r_cfg = env-sregs[SFR_RW_MM_CFG];
- pid = env-pregs[PR_PID] 0xff;
-
- switch (rw) {
- case 2: rwcause = CRIS_MMU_ERR_EXEC; mmu = 0; break;
- case 1: rwcause = CRIS_MMU_ERR_WRITE; break;
- default:
- case 0: rwcause = CRIS_MMU_ERR_READ; break;
- }
-
- /* I exception vectors 4 - 7, D 8 - 11. */
- vect_base = (mmu + 1) * 4;
-
- vpage = vaddr 13;
-
- /* We know the index which to check on each set.
- Scan both I and D. */
+unsigned int vpage;
+unsigned int idx;
+uint32_t pid, lo, hi;
+uint32_t tlb_vpn, tlb_pfn = 0;
+int tlb_pid, tlb_g, tlb_v, tlb_k, tlb_w, tlb_x;
+int cfg_v, cfg_k, cfg_w, cfg_x;
+int set, match = 0;
+uint32_t r_cause;
+uint32_t r_cfg;
+int rwcause;
+int mmu = 1; /* Data mmu is default. */
+int vect_base;
+
+r_cause = env-sregs[SFR_R_MM_CAUSE];
+r_cfg = env-sregs[SFR_RW_MM_CFG];
+pid = env-pregs[PR_PID] 0xff;
+
+switch (rw) {
+case 2:
+rwcause = CRIS_MMU_ERR_EXEC;
+mmu = 0;
+break;
+case 1:
+rwcause = CRIS_MMU_ERR_WRITE;
+break;
+default:
+case 0:
+rwcause = CRIS_MMU_ERR_READ;
+break;
+}
+
+/* I exception vectors 4 - 7, D 8 - 11. */
+vect_base = (mmu + 1) * 4;
+
+vpage = vaddr 13;
+
+/* We know the index which to check on each set.
+ Scan both I and D. */
#if 0
- for (set = 0; set 4; set++) {
- for (idx = 0; idx 16; idx++) {
- lo = env-tlbsets[mmu][set][idx].lo;
- hi = env-tlbsets[mmu][set][idx].hi;
- tlb_vpn = EXTRACT_FIELD(hi, 13, 31);
- tlb_pfn = EXTRACT_FIELD(lo, 13, 31);
-
- printf (TLB: [%d][%d] hi=%x lo=%x v=%x p=%x\n,
- set, idx, hi, lo, tlb_vpn, tlb_pfn);
- }
- }
+for (set = 0; set 4; set++) {
+for (idx = 0; idx 16; idx++) {
+lo = env-tlbsets[mmu][set][idx].lo;
+hi = env-tlbsets[mmu][set][idx].hi;
+tlb_vpn = EXTRACT_FIELD(hi, 13, 31);
+tlb_pfn = EXTRACT_FIELD(lo, 13, 31);
+
+printf(TLB: [%d][%d] hi=%x lo=%x v=%x p=%x\n,
+ set, idx, hi, lo, tlb_vpn, tlb_pfn);
+}
+}
#endif
- idx = vpage 15;
- for (set = 0; set 4; set++)
- {
- lo = env-tlbsets[mmu][set][idx].lo;
- hi = env-tlbsets[mmu][set][idx].hi;
-
- tlb_vpn = hi 13;
- tlb_pid = EXTRACT_FIELD(hi, 0, 7);
- tlb_g = EXTRACT_FIELD(lo, 4, 4);
-
- D_LOG(TLB[%d][%d][%d] v=%x vpage=%x lo=%x hi=%x\n,
-mmu, set, idx, tlb_vpn, vpage, lo, hi);
- if ((tlb_g || (tlb_pid == pid))
-tlb_vpn == vpage) {
- match = 1;
- break;
- }
- }
-
- res-bf_vec = vect_base;
- if (match) {
- cfg_w = EXTRACT_FIELD(r_cfg, 19, 19);
- cfg_k = EXTRACT_FIELD(r_cfg, 18, 18);
- cfg_x = EXTRACT_FIELD(r_cfg, 17, 17);
- cfg_v = EXTRACT_FIELD(r_cfg, 16, 16);
-
- tlb_pfn = EXTRACT_FIELD(lo, 13, 31);
- tlb_v = EXTRACT_FIELD(lo, 3, 3);
- tlb_k = EXTRACT_FIELD(lo, 2, 2);
- tlb_w = EXTRACT_FIELD(lo, 1, 1);
- tlb_x = EXTRACT_FIELD(lo, 0, 0);
-
- /*
- set_exception_vector(0x04, i_mmu_refill);
- set_exception_vector(0x05, i_mmu_invalid);
- set_exception_vector(0x06, i_mmu_access);
- set_exception_vector(0x07, i_mmu_execute);
- set_exception_vector(0x08, d_mmu_refill);
-
[Qemu-devel] [PATCH RESEND for-1.4? 08/19] target-cris/helper.c: Update Coding Style
Reindent, add missing braces and drop/adjust whitespace.
Prepares for CPUArchState-to-CPUState field movements in
cpu_cris_handle_mmu_fault(), do_interruptv10() and do_interrupt().
The remaining functions were so minor that they can be fixed in one go.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-cris/helper.c | 393 +-
1 Datei geändert, 196 Zeilen hinzugefügt(+), 197 Zeilen entfernt(-)
diff --git a/target-cris/helper.c b/target-cris/helper.c
index 6e75e98..de04143 100644
--- a/target-cris/helper.c
+++ b/target-cris/helper.c
@@ -36,19 +36,19 @@
#if defined(CONFIG_USER_ONLY)
-void do_interrupt (CPUCRISState *env)
+void do_interrupt(CPUCRISState *env)
{
- env-exception_index = -1;
- env-pregs[PR_ERP] = env-pc;
+env-exception_index = -1;
+env-pregs[PR_ERP] = env-pc;
}
int cpu_cris_handle_mmu_fault(CPUCRISState * env, target_ulong address, int rw,
int mmu_idx)
{
- env-exception_index = 0xaa;
- env-pregs[PR_EDA] = address;
- cpu_dump_state(env, stderr, fprintf, 0);
- return 1;
+env-exception_index = 0xaa;
+env-pregs[PR_EDA] = address;
+cpu_dump_state(env, stderr, fprintf, 0);
+return 1;
}
#else /* !CONFIG_USER_ONLY */
@@ -56,211 +56,210 @@ int cpu_cris_handle_mmu_fault(CPUCRISState * env,
target_ulong address, int rw,
static void cris_shift_ccs(CPUCRISState *env)
{
- uint32_t ccs;
- /* Apply the ccs shift. */
- ccs = env-pregs[PR_CCS];
- ccs = ((ccs 0xc000) | ((ccs 12) 2)) ~0x3ff;
- env-pregs[PR_CCS] = ccs;
+uint32_t ccs;
+/* Apply the ccs shift. */
+ccs = env-pregs[PR_CCS];
+ccs = ((ccs 0xc000) | ((ccs 12) 2)) ~0x3ff;
+env-pregs[PR_CCS] = ccs;
}
-int cpu_cris_handle_mmu_fault (CPUCRISState *env, target_ulong address, int rw,
- int mmu_idx)
+int cpu_cris_handle_mmu_fault(CPUCRISState *env, target_ulong address, int rw,
+ int mmu_idx)
{
- struct cris_mmu_result res;
- int prot, miss;
- int r = -1;
- target_ulong phy;
-
- D(printf (%s addr=%x pc=%x rw=%x\n, __func__, address, env-pc, rw));
- miss = cris_mmu_translate(res, env, address TARGET_PAGE_MASK,
- rw, mmu_idx, 0);
- if (miss)
- {
- if (env-exception_index == EXCP_BUSFAULT)
- cpu_abort(env,
- CRIS: Illegal recursive bus fault.
-addr=%x rw=%d\n,
-address, rw);
-
- env-pregs[PR_EDA] = address;
- env-exception_index = EXCP_BUSFAULT;
- env-fault_vector = res.bf_vec;
- r = 1;
- }
- else
- {
- /*
-* Mask off the cache selection bit. The ETRAX busses do not
-* see the top bit.
-*/
- phy = res.phy ~0x8000;
- prot = res.prot;
- tlb_set_page(env, address TARGET_PAGE_MASK, phy,
- prot, mmu_idx, TARGET_PAGE_SIZE);
-r = 0;
- }
- if (r 0)
-D_LOG(%s returns %d irqreq=%x addr=%x phy=%x vec=%x pc=%x\n,
- __func__, r, env-interrupt_request, address, res.phy,
- res.bf_vec, env-pc);
- return r;
+struct cris_mmu_result res;
+int prot, miss;
+int r = -1;
+target_ulong phy;
+
+D(printf(%s addr=%x pc=%x rw=%x\n, __func__, address, env-pc, rw));
+miss = cris_mmu_translate(res, env, address TARGET_PAGE_MASK,
+ rw, mmu_idx, 0);
+if (miss) {
+if (env-exception_index == EXCP_BUSFAULT) {
+cpu_abort(env,
+ CRIS: Illegal recursive bus fault.
+ addr=%x rw=%d\n,
+ address, rw);
+}
+
+env-pregs[PR_EDA] = address;
+env-exception_index = EXCP_BUSFAULT;
+env-fault_vector = res.bf_vec;
+r = 1;
+} else {
+/*
+ * Mask off the cache selection bit. The ETRAX busses do not
+ * see the top bit.
+ */
+phy = res.phy ~0x8000;
+prot = res.prot;
+tlb_set_page(env, address TARGET_PAGE_MASK, phy,
+ prot, mmu_idx, TARGET_PAGE_SIZE);
+r = 0;
+}
+if (r 0) {
+D_LOG(%s returns %d irqreq=%x addr=%x phy=%x vec=%x pc=%x\n,
+ __func__, r, env-interrupt_request, address, res.phy,
+ res.bf_vec, env-pc);
+}
+return r;
}
static void do_interruptv10(CPUCRISState *env)
{
- int ex_vec = -1;
-
- D_LOG( exception index=%d interrupt_req=%d\n,
- env-exception_index,
- env-interrupt_request);
-
- assert(!(env-pregs[PR_CCS] PFIX_FLAG));
- switch
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
On Sat, Jan 26, 2013 at 8:43 PM, David Woodhouse dw...@infradead.org wrote:
For OVMF we really want to have a way to store non-volatile variables,
other than the dirty hack that currently puts them on a file in the EFI
system partition.
It looks like we've supported writing to fw_cfg items fairly much since
they were introduced, but we've never actually made use of that.
This WIP patch kills the existing fw_cfg_add_callback() because I can't
see how it would ever be useful, and it doesn't seem to have been used
for years, if ever. And adds something slightly more useful.
Other then the obvious bits that need finishing, any objections?
It looks like this duplicates rom_add_file() and fw_cfg_add_file(), so
I don't see the point.
Removing unused fw_cfg_add_callback() should be a separate patch and
that would be OK.
In general, QEMU uses different coding style from kernel, so please
read our CODING_STYLE and use checkpatch.pl to catch obvious problems,
like missing braces and C99 comments.
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 3b31d77..1318a2e 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -33,6 +33,9 @@
#define FW_CFG_SIZE 2
#define FW_CFG_DATA_SIZE 1
+struct FWCfgEntry;
+typedef void (*FWCfgCallback)(struct FWCfgState *s, struct FWCfgEntry *e,
int value);
+
typedef struct FWCfgEntry {
uint32_t len;
uint8_t *data;
@@ -206,20 +209,19 @@ static void fw_cfg_write(FWCfgState *s, uint8_t value)
trace_fw_cfg_write(s, value);
-if (s-cur_entry FW_CFG_WRITE_CHANNEL e-callback
-s-cur_offset e-len) {
-e-data[s-cur_offset++] = value;
-if (s-cur_offset == e-len) {
-e-callback(e-callback_opaque, e-data);
-s-cur_offset = 0;
-}
-}
+if (s-cur_entry FW_CFG_WRITE_CHANNEL e-callback)
+e-callback(s, e, value);
}
static int fw_cfg_select(FWCfgState *s, uint16_t key)
{
+int arch = !!(s-cur_entry FW_CFG_ARCH_LOCAL);
+FWCfgEntry *e = s-entries[arch][s-cur_entry FW_CFG_ENTRY_MASK];
int ret;
+if (e-callback)
+e-callback(s, e, -1);
+
s-cur_offset = 0;
if ((key FW_CFG_ENTRY_MASK) = FW_CFG_MAX_ENTRY) {
s-cur_entry = FW_CFG_INVALID;
@@ -419,8 +421,8 @@ void fw_cfg_add_i64(FWCfgState *s, uint16_t key, uint64_t
value)
fw_cfg_add_bytes(s, key, copy, sizeof(value));
}
-void fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
- void *callback_opaque, void *data, size_t len)
+static void fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback
callback,
+void *callback_opaque, void *data, size_t
len)
{
int arch = !!(key FW_CFG_ARCH_LOCAL);
@@ -436,8 +438,9 @@ void fw_cfg_add_callback(FWCfgState *s, uint16_t key,
FWCfgCallback callback,
s-entries[arch][key].callback = callback;
}
-void fw_cfg_add_file(FWCfgState *s, const char *filename,
- void *data, size_t len)
+static void fw_cfg_add_file_writeable(FWCfgState *s, const char *filename,
+ void *data, size_t len,
+ FWCfgCallback callback, void *cb_opaque)
{
int i, index;
size_t dsize;
@@ -451,7 +454,8 @@ void fw_cfg_add_file(FWCfgState *s, const char *filename,
index = be32_to_cpu(s-files-count);
assert(index FW_CFG_FILE_SLOTS);
-fw_cfg_add_bytes(s, FW_CFG_FILE_FIRST + index, data, len);
+fw_cfg_add_callback(s, FW_CFG_WRITE_CHANNEL + FW_CFG_FILE_FIRST + index,
+callback, cb_opaque, data, len);
pstrcpy(s-files-f[index].name, sizeof(s-files-f[index].name),
filename);
@@ -464,11 +468,74 @@ void fw_cfg_add_file(FWCfgState *s, const char
*filename,
s-files-f[index].size = cpu_to_be32(len);
s-files-f[index].select = cpu_to_be16(FW_CFG_FILE_FIRST + index);
+if (callback)
+ s-files-f[index].select |= cpu_to_be16(FW_CFG_WRITE_CHANNEL);
trace_fw_cfg_add_file(s, index, s-files-f[index].name, len);
s-files-count = cpu_to_be32(index+1);
}
+void fw_cfg_add_file(FWCfgState *s, const char *filename,
+ void *data, size_t len)
+{
+fw_cfg_add_file_writeable(s, filename, data, len, NULL, NULL);
+}
+
+// Lifted from pc.c
+static long get_file_size(FILE *f)
+{
+long where, size;
+
+/* XXX: on Unix systems, using fstat() probably makes more sense */
+
+where = ftell(f);
+fseek(f, 0, SEEK_END);
+size = ftell(f);
+fseek(f, where, SEEK_SET);
+
+return size;
+}
+
+static void nvstorage_callback(struct FWCfgState *s, struct FWCfgEntry *e,
int value)
+
+{
+if (value == -1) {
+FILE *f = fopen(e-callback_opaque, wb);
+if (f) {
+fwrite(e-data, e-len, 1, f);
+fclose(f);
+}
+ return;
+}
+if (s-cur_offset ==
[Qemu-devel] [PATCH for-1.4] configure: Keep -Werror enabled for Release Candidates
The automatic drop of -Werror during the RC phases has in the past led to warnings creeping into submaintainer trees. Last QEMU Summit it was concluded that -Werror should stay on and enabled only as part of the release process. To relieve our release manager, instead of always enabling -Werror or doing some number magic, let's enable it depending on whether a .git/ directory exists in the source tree. Signed-off-by: Andreas Färber afaer...@suse.de --- configure |2 +- 1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-) diff --git a/configure b/configure index b7635e4..0657b1a 100755 --- a/configure +++ b/configure @@ -1180,7 +1180,7 @@ fi z_version=`cut -f3 -d. $source_path/VERSION` if test -z $werror ; then -if test $z_version = 50 -a \ +if test -d $source_path/.git -a \ $linux = yes ; then werror=yes else -- 1.7.10.4
Re: [Qemu-devel] [PATCH for-1.4] configure: Keep -Werror enabled for Release Candidates
Am 27.01.2013 16:16, schrieb Andreas Färber: The automatic drop of -Werror during the RC phases has in the past led to warnings creeping into submaintainer trees. Last QEMU Summit it was concluded that -Werror should stay on and enabled only as part of the release process. be disabled, obviously :) To relieve our release manager, instead of always enabling -Werror or doing some number magic, let's enable it depending on whether a .git/ directory exists in the source tree. Signed-off-by: Andreas Färber afaer...@suse.de --- configure |2 +- 1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-) diff --git a/configure b/configure index b7635e4..0657b1a 100755 --- a/configure +++ b/configure @@ -1180,7 +1180,7 @@ fi z_version=`cut -f3 -d. $source_path/VERSION` if test -z $werror ; then -if test $z_version = 50 -a \ +if test -d $source_path/.git -a \ $linux = yes ; then werror=yes else -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote: It looks like this duplicates rom_add_file() and fw_cfg_add_file(), so I don't see the point. Both of those are read-only, surely? The firmware inside the guest can't use them for non-volatile storage. It doesn't duplicate fw_cfg_add_file(); it extends it to allow a writeable mode too. fw_cfg_add_file() becomes a simple wrapper around fw_cfg_add_file_writeable(), which actually contains most of the contents of the original function. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] qtest tmp105-test endianness issue
On Sat, Jan 26, 2013 at 10:51 PM, Andreas Färber afaer...@suse.de wrote: Am 26.01.2013 23:21, schrieb Alexander Graf: On 26.01.2013, at 23:12, Andreas Färber wrote: I've found that my tmp105-test fails on Mac OS X ppc(64), i.e. Little Endian arm-softmmu target and Big Endian host: GTESTER check-qtest-arm mipid_reset: Display off ** ERROR:/Users/andreas/QEMU/qemu/tests/libi2c-imap.c:163:omap_i2c_create: assertion failed (data == 0x34): (0x3400 == 0x0034) The only other test case that uses memread() is m48t59-test, which uses size 1 MMIO accesses only. This suggests that Big Endian guest (e.g., sparc) and Little Endian host (e.g., x86_64) may cause issues, too. What is the expected way to handle endianness in qtest? Should qtest.c:qtest_process_command() be changed? libqtest.c:qtest_memread()? Or the test itself byteswap and, if so, under which circumstances? Well, first of all qtest works on behalf of the emulated CPU. The MMIO code path doesn't care about target CPU endianness. It simply passes the native value to the handler. The handler however might change byte order depending on the memory api endianness flag. But in this particular case, I'd be very surprised if any endianness swapping had to be involved. Fact is, it passes on x86 and fails on ppc. :) Reproducible on openSUSE ppc64. It also fails on Sparc64. But other tests (x86 and Sparc) are fine, except (maybe because of lack of memory or slow NFS) /dicts/large_dict in tests/check-qjson does not finish in reasonable time. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse dw...@infradead.org wrote: On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote: It looks like this duplicates rom_add_file() and fw_cfg_add_file(), so I don't see the point. Both of those are read-only, surely? The firmware inside the guest can't use them for non-volatile storage. Right. But why do we need PV non-volatile storage, instead of normal flash? It doesn't duplicate fw_cfg_add_file(); it extends it to allow a writeable mode too. fw_cfg_add_file() becomes a simple wrapper around fw_cfg_add_file_writeable(), which actually contains most of the contents of the original function. OK, however most of the loading logic is now in loader.c and that should not be duplicated either. -- dwmw2
Re: [Qemu-devel] [RFC 16/19] target-ppc: Refactor debug output macros
Am 27.01.2013 um 15:54 schrieb Andreas Färber afaer...@suse.de:
Am 27.01.2013 15:46, schrieb Alexander Graf:
On 27.01.2013, at 15:35, Andreas Färber wrote:
Am 27.01.2013 15:14, schrieb Anthony Liguori:
Andreas Färber afaer...@suse.de writes:
diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
index 0a1ac86..54722c4 100644
--- a/target-ppc/excp_helper.c
+++ b/target-ppc/excp_helper.c
@@ -21,14 +21,14 @@
#include helper_regs.h
-//#define DEBUG_OP
-//#define DEBUG_EXCEPTIONS
+#define DEBUG_OP 0
+#define DEBUG_EXCEPTIONS 0
-#ifdef DEBUG_EXCEPTIONS
-# define LOG_EXCP(...) qemu_log(__VA_ARGS__)
-#else
-# define LOG_EXCP(...) do { } while (0)
-#endif
+#define LOG_EXCP(...) G_STMT_START \
+if (DEBUG_EXCEPTIONS) { \
+qemu_log(__VA_ARGS__); \
+} \
+G_STMT_END
Just thinking out loud a bit.. This form becomes pretty common and it's
ashame to use a macro here if we don't have to.
I think:
static inline void LOG_EXCP(const char *fmt, ...)
{
if (debug_exceptions) {
va_list ap;
va_start(ap, fmt);
qemu_logv(fmt, ap);
va_end(ap);
}
}
Probably would have equivalent performance. debug_exception would be
read-mostly and ought to be very predictable as a result. I strongly
expect that the compiler would actually inline LOG_EXCP too.
Thanks for your early feedback. I merely tried to stay close to the
original code. I wouldn't mind inline functions either. Or even more
harmonization for that matter.
I fully agree. Just recently Scott revamped the openpic debug print code:
//#define DEBUG_OPENPIC
#ifdef DEBUG_OPENPIC
static const int debug_openpic = 1;
#else
static const int debug_openpic = 0;
#endif
#define DPRINTF(fmt, ...) do { \
if (debug_openpic) { \
printf(fmt , ## __VA_ARGS__); \
} \
} while (0)
Like :)
I'll wait for more feedback from affected maintainers though before I
redo or widen this series.
Or were you proposing to do a ppc-only refactoring à la Scott for 1.4?
No, I think it makes a lot more sense to do this tree-wide after 1.4 :).
Alex
Andreas
I like that approach. It keeps all users identical. The #define stays
identical. The callers stay identical. But we do get proper compile time
checks. Of course Anthony's approach works too, but the thing I'd definitely
like to see is that the #defines don't become numerical, but rather stay of
an #ifdef basis.
Alex
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [kvmarm] [RFC] Virtio-desktop: Virtio-based virtual desktop
On 27.01.2013, at 15:07, Anthony Liguori wrote: Anup Patel anup.pa...@linaro.org writes: Hi All, How about having a generic Virtio-based machine for emulating a virtual desktop ? I know folks have already thought about this and probably also tried something or other on this front but, it will be good to know the downsides. Virtio-desktop can be a separate specification describing a virtual desktop. Of-course we cannot avoid few architecture dependent virtual devices in but the Virtio-desktop specification will try to keep minimum possible architecture dependent devices. There's a lot of reasons why a pure PV machine type is a bad idea. Lots of people have enumerated them in this thread. But let me mention some things that I think we don't have covered today with PV: - Graphics. Yes, I know QXL exists but it's (a) dependent on PCI (b) lacks the ability to gracefully degrade making it hopelessly tied to spice. There was a QXL-on-virtio port in the works a while ago IIRC: - Input. PS/2 mouse provides relative input which sucks in guests. For absolute input, we have VMMouse which is x86-specific, USB tablets (which are expensive to emulate) or the spice mouse which is intimately tied to the full Spice stack. I thought the USB tablet is ok today thanks to auto-suspend of the bus? Or was that only with ehci? - Guest interaction. Copy/paste, drag and drop, etc. In theory this is covered in spice agents but it's all again hopelessly tied to Spice which makes it non-portable. - Keyboard. When running with VNC, the 3 stacks involved in converting keyboard layouts back and forth are really confusing to users. So there's good work todo but it's almost certainly in working with the Spice community to try to make what they already have more accessible to non-x86 architectures. Hooray :) Alex
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
David Woodhouse dw...@infradead.org writes:
For OVMF we really want to have a way to store non-volatile variables,
other than the dirty hack that currently puts them on a file in the EFI
system partition.
It looks like we've supported writing to fw_cfg items fairly much since
they were introduced, but we've never actually made use of that.
This WIP patch kills the existing fw_cfg_add_callback() because I can't
see how it would ever be useful, and it doesn't seem to have been used
for years, if ever. And adds something slightly more useful.
Other then the obvious bits that need finishing, any objections?
The main issue is malicious guests. The administrator has to be aware
of and in control of how much disk space the guest can use. The
secondary issue is how to tie into the block layer so things like live
migration work.
This is why use a flash device is an attractive answer here because it
gives a fixed sized storage pool that's configurable by the
administrator. Since it's backed by a block device, it supports all of
the features needed for non-volatile storage (snapshotting, live copy,
etc.).
The only real downside is that it's opaque to the host. If it's
desirable to have something that's visible to the host, then I think we
would still need to make use of BlockDriverState as the means to make it
non-volatile.
That essentially involves writing a file system in QEMU on top of
BlockDriverState and then having a PV inteface with the guest to get/set
file content. Would be useful to have, but so far no one has cared
enough about making these stores non-opaque to do it.
Regards,
Anthony Liguori
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 3b31d77..1318a2e 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -33,6 +33,9 @@
#define FW_CFG_SIZE 2
#define FW_CFG_DATA_SIZE 1
+struct FWCfgEntry;
+typedef void (*FWCfgCallback)(struct FWCfgState *s, struct FWCfgEntry *e,
int value);
+
typedef struct FWCfgEntry {
uint32_t len;
uint8_t *data;
@@ -206,20 +209,19 @@ static void fw_cfg_write(FWCfgState *s, uint8_t value)
trace_fw_cfg_write(s, value);
-if (s-cur_entry FW_CFG_WRITE_CHANNEL e-callback
-s-cur_offset e-len) {
-e-data[s-cur_offset++] = value;
-if (s-cur_offset == e-len) {
-e-callback(e-callback_opaque, e-data);
-s-cur_offset = 0;
-}
-}
+if (s-cur_entry FW_CFG_WRITE_CHANNEL e-callback)
+e-callback(s, e, value);
}
static int fw_cfg_select(FWCfgState *s, uint16_t key)
{
+int arch = !!(s-cur_entry FW_CFG_ARCH_LOCAL);
+FWCfgEntry *e = s-entries[arch][s-cur_entry FW_CFG_ENTRY_MASK];
int ret;
+if (e-callback)
+e-callback(s, e, -1);
+
s-cur_offset = 0;
if ((key FW_CFG_ENTRY_MASK) = FW_CFG_MAX_ENTRY) {
s-cur_entry = FW_CFG_INVALID;
@@ -419,8 +421,8 @@ void fw_cfg_add_i64(FWCfgState *s, uint16_t key, uint64_t
value)
fw_cfg_add_bytes(s, key, copy, sizeof(value));
}
-void fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
- void *callback_opaque, void *data, size_t len)
+static void fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback
callback,
+void *callback_opaque, void *data, size_t
len)
{
int arch = !!(key FW_CFG_ARCH_LOCAL);
@@ -436,8 +438,9 @@ void fw_cfg_add_callback(FWCfgState *s, uint16_t key,
FWCfgCallback callback,
s-entries[arch][key].callback = callback;
}
-void fw_cfg_add_file(FWCfgState *s, const char *filename,
- void *data, size_t len)
+static void fw_cfg_add_file_writeable(FWCfgState *s, const char *filename,
+ void *data, size_t len,
+ FWCfgCallback callback, void *cb_opaque)
{
int i, index;
size_t dsize;
@@ -451,7 +454,8 @@ void fw_cfg_add_file(FWCfgState *s, const char *filename,
index = be32_to_cpu(s-files-count);
assert(index FW_CFG_FILE_SLOTS);
-fw_cfg_add_bytes(s, FW_CFG_FILE_FIRST + index, data, len);
+fw_cfg_add_callback(s, FW_CFG_WRITE_CHANNEL + FW_CFG_FILE_FIRST + index,
+callback, cb_opaque, data, len);
pstrcpy(s-files-f[index].name, sizeof(s-files-f[index].name),
filename);
@@ -464,11 +468,74 @@ void fw_cfg_add_file(FWCfgState *s, const char
*filename,
s-files-f[index].size = cpu_to_be32(len);
s-files-f[index].select = cpu_to_be16(FW_CFG_FILE_FIRST + index);
+if (callback)
+ s-files-f[index].select |= cpu_to_be16(FW_CFG_WRITE_CHANNEL);
trace_fw_cfg_add_file(s, index, s-files-f[index].name, len);
s-files-count = cpu_to_be32(index+1);
}
+void fw_cfg_add_file(FWCfgState *s, const char *filename,
+ void *data, size_t len)
+{
+fw_cfg_add_file_writeable(s, filename, data, len,
[Qemu-devel] [PATCH qom-cpu for-1.4] target-arm: Rename CPU types
In the initial conversion of CPU models to QOM types, model names were
mapped 1:1 to type names. As a side effect this gained us a type any,
which is now a device.
To avoid -device any silliness and to pave the way for compiling
multiple targets into one executable, adopt a name-arch-cpu scheme.
This leads to names like arm926-arm-cpu but is easiest to handle.
No functional changes for -cpu arguments or -cpu ? output.
Suggested-by: Eduardo Habkost ehabk...@redhat.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-arm/cpu.c|8 ++--
target-arm/helper.c | 11 ---
2 Dateien geändert, 14 Zeilen hinzugefügt(+), 5 Zeilen entfernt(-)
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index d1a4c82..1c6a628 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -204,12 +204,15 @@ void arm_cpu_realize(ARMCPU *cpu)
static ObjectClass *arm_cpu_class_by_name(const char *cpu_model)
{
ObjectClass *oc;
+char *typename;
if (!cpu_model) {
return NULL;
}
-oc = object_class_by_name(cpu_model);
+typename = g_strdup_printf(%s- TYPE_ARM_CPU, cpu_model);
+oc = object_class_by_name(typename);
+g_free(typename);
if (!oc || !object_class_dynamic_cast(oc, TYPE_ARM_CPU) ||
object_class_is_abstract(oc)) {
return NULL;
@@ -789,14 +792,15 @@ static void arm_cpu_class_init(ObjectClass *oc, void
*data)
static void cpu_register(const ARMCPUInfo *info)
{
TypeInfo type_info = {
-.name = info-name,
.parent = TYPE_ARM_CPU,
.instance_size = sizeof(ARMCPU),
.instance_init = info-initfn,
.class_size = sizeof(ARMCPUClass),
};
+type_info.name = g_strdup_printf(%s- TYPE_ARM_CPU, info-name);
type_register(type_info);
+g_free((void *)type_info.name);
}
static const TypeInfo arm_cpu_type_info = {
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 7a10fdd..eb7b291 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1303,9 +1303,9 @@ static gint arm_cpu_list_compare(gconstpointer a,
gconstpointer b)
name_a = object_class_get_name(class_a);
name_b = object_class_get_name(class_b);
-if (strcmp(name_a, any) == 0) {
+if (strcmp(name_a, any- TYPE_ARM_CPU) == 0) {
return 1;
-} else if (strcmp(name_b, any) == 0) {
+} else if (strcmp(name_b, any- TYPE_ARM_CPU) == 0) {
return -1;
} else {
return strcmp(name_a, name_b);
@@ -1316,9 +1316,14 @@ static void arm_cpu_list_entry(gpointer data, gpointer
user_data)
{
ObjectClass *oc = data;
CPUListState *s = user_data;
+const char *typename;
+char *name;
+typename = object_class_get_name(oc);
+name = g_strndup(typename, strlen(typename) - strlen(- TYPE_ARM_CPU));
(*s-cpu_fprintf)(s-file, %s\n,
- object_class_get_name(oc));
+ name);
+g_free(name);
}
void arm_cpu_list(FILE *f, fprintf_function cpu_fprintf)
--
1.7.10.4
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
On Sun, 2013-01-27 at 16:02 +, Blue Swirl wrote: On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse dw...@infradead.org wrote: On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote: It looks like this duplicates rom_add_file() and fw_cfg_add_file(), so I don't see the point. Both of those are read-only, surely? The firmware inside the guest can't use them for non-volatile storage. Right. But why do we need PV non-volatile storage, instead of normal flash? People have looked at adding normal flash to the PC target, but it has a number of problems. Firstly, it doesn't even *work* with KVM enabled. But even if we were to somehow fix that, the simple approach of emulating a BIOS flash is also very suboptimal; it puts the whole of the firmware *into* the flash and lets it store its non-volatile variables in the same emulated flash chip. So if you want to update the firmware (which would normally be just a case of updating the bios.bin file), you end up having to do each guest system individually *and* the update is painful because you have to preserve the non-volatile storage while updating the other parts. It's much better to have a separate storage for the non-volatile variables. Yes, we *could* teach it to use a dedicated flash chip for that rather than using flash for the firmware *and* storage as we would on real hardware. But if we're going to do something different for the virtualised case, a writeable fw_cfg file seems a whole lot easier and saner. It doesn't duplicate fw_cfg_add_file(); it extends it to allow a writeable mode too. fw_cfg_add_file() becomes a simple wrapper around fw_cfg_add_file_writeable(), which actually contains most of the contents of the original function. OK, however most of the loading logic is now in loader.c and that should not be duplicated either. I actually got file_get_size() from pc.c, and had marked it with a horrid C99 comment so we couldn't miss the duplication. I'll sort out that kind of detail later, if we can reach consensus on the basic approach. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote: David Woodhouse dw...@infradead.org writes: For OVMF we really want to have a way to store non-volatile variables, other than the dirty hack that currently puts them on a file in the EFI system partition. It looks like we've supported writing to fw_cfg items fairly much since they were introduced, but we've never actually made use of that. This WIP patch kills the existing fw_cfg_add_callback() because I can't see how it would ever be useful, and it doesn't seem to have been used for years, if ever. And adds something slightly more useful. Other then the obvious bits that need finishing, any objections? The main issue is malicious guests. The administrator has to be aware of and in control of how much disk space the guest can use. The secondary issue is how to tie into the block layer so things like live migration work. This is why use a flash device is an attractive answer here because it gives a fixed sized storage pool that's configurable by the administrator. That part is fixable simply by imposing a maximum size, surely? Since it's backed by a block device, it supports all of the features needed for non-volatile storage (snapshotting, live copy, etc.). The only real downside is that it's opaque to the host. If it's desirable to have something that's visible to the host, then I think we would still need to make use of BlockDriverState as the means to make it non-volatile. I don't really care about it being visible to the host. The important thing is that it's easily usable from the guest firmware at runtime, and not on a device that the OS might be trying to use. Their current trick is a file on the EFI system partition, which is definitely *not* acceptable. It doesn't work after the OS has booted, so even basic tasks like install an OS and hope the installer can set the boot variables to boot into it are broken. For exposing it to the guest, writeable fw_cfg definitely seems like the most attractive answer. I'll look at backing it with BlockDriverState. I don't even think we need a file system on it; it can just be a fixed-size device exposed as-is, surely? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
On Sun, Jan 27, 2013 at 4:38 PM, David Woodhouse dw...@infradead.org wrote: On Sun, 2013-01-27 at 16:02 +, Blue Swirl wrote: On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse dw...@infradead.org wrote: On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote: It looks like this duplicates rom_add_file() and fw_cfg_add_file(), so I don't see the point. Both of those are read-only, surely? The firmware inside the guest can't use them for non-volatile storage. Right. But why do we need PV non-volatile storage, instead of normal flash? People have looked at adding normal flash to the PC target, but it has a number of problems. Firstly, it doesn't even *work* with KVM enabled. But even if we were to somehow fix that, the simple approach of emulating a BIOS flash is also very suboptimal; it puts the whole of the firmware *into* the flash and lets it store its non-volatile variables in the same emulated flash chip. So if you want to update the firmware (which would normally be just a case of updating the bios.bin file), you end up having to do each guest system individually *and* the update is painful because you have to preserve the non-volatile storage while updating the other parts. That problem could be easily solved by allowing a combination of two images with different RO/RW settings, for example -bios bios.bin[,offset=0,ro] -bios flash.img, offset=0x8000,rw. It's much better to have a separate storage for the non-volatile variables. Yes, we *could* teach it to use a dedicated flash chip for that rather than using flash for the firmware *and* storage as we would on real hardware. But if we're going to do something different for the virtualised case, a writeable fw_cfg file seems a whole lot easier and saner. It doesn't duplicate fw_cfg_add_file(); it extends it to allow a writeable mode too. fw_cfg_add_file() becomes a simple wrapper around fw_cfg_add_file_writeable(), which actually contains most of the contents of the original function. OK, however most of the loading logic is now in loader.c and that should not be duplicated either. I actually got file_get_size() from pc.c, and had marked it with a horrid C99 comment so we couldn't miss the duplication. I'll sort out that kind of detail later, if we can reach consensus on the basic approach. So the duplication already exists. :-( -- dwmw2
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
On Sun, 2013-01-27 at 16:55 +, Blue Swirl wrote: That problem could be easily solved by allowing a combination of two images with different RO/RW settings, for example -bios bios.bin[,offset=0,ro] -bios flash.img, offset=0x8000,rw. /me shudders at the idea of co-ordinating that with the range of the flash chip that the latest build of the firmware actually wants to use for its non-volatile storage. Seriously, keep them separate. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
On Sun, 2013-01-27 at 16:59 +, Blue Swirl wrote: For example hw/spapr_nvram.c implements a similar device. If the user does not specify any backing file for nvram, its contents will not be saved. I'll look at that; thanks. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
On Sun, Jan 27, 2013 at 4:47 PM, David Woodhouse dw...@infradead.org wrote: On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote: David Woodhouse dw...@infradead.org writes: For OVMF we really want to have a way to store non-volatile variables, other than the dirty hack that currently puts them on a file in the EFI system partition. It looks like we've supported writing to fw_cfg items fairly much since they were introduced, but we've never actually made use of that. This WIP patch kills the existing fw_cfg_add_callback() because I can't see how it would ever be useful, and it doesn't seem to have been used for years, if ever. And adds something slightly more useful. Other then the obvious bits that need finishing, any objections? The main issue is malicious guests. The administrator has to be aware of and in control of how much disk space the guest can use. The secondary issue is how to tie into the block layer so things like live migration work. This is why use a flash device is an attractive answer here because it gives a fixed sized storage pool that's configurable by the administrator. That part is fixable simply by imposing a maximum size, surely? Since it's backed by a block device, it supports all of the features needed for non-volatile storage (snapshotting, live copy, etc.). The only real downside is that it's opaque to the host. If it's desirable to have something that's visible to the host, then I think we would still need to make use of BlockDriverState as the means to make it non-volatile. I don't really care about it being visible to the host. The important thing is that it's easily usable from the guest firmware at runtime, and not on a device that the OS might be trying to use. Their current trick is a file on the EFI system partition, which is definitely *not* acceptable. It doesn't work after the OS has booted, so even basic tasks like install an OS and hope the installer can set the boot variables to boot into it are broken. For exposing it to the guest, writeable fw_cfg definitely seems like the most attractive answer. I'll look at backing it with BlockDriverState. I don't even think we need a file system on it; it can just be a fixed-size device exposed as-is, surely? For example hw/spapr_nvram.c implements a similar device. If the user does not specify any backing file for nvram, its contents will not be saved. -- dwmw2
[Qemu-devel] [PATCH 0/2 v2] Time resync support by qemu-ga
This patch series attempts to add time resync support
to qemu-ga by introducing qemu-ga commands guest-get-time
and guest-set-time.
Right now, when a guest is paused or migrated to a file
then loaded from that file, the guest OS has no idea that
there was a big gap in the time. Depending on how long the
gap was, NTP might not be able to resynchronize the guest.
So adding new guest-agent command that is called any time
a guest is resumed and which tells the guest to update its
own wall clock time based on the information from the host
will make it easier for a guest to resynchronize without
waiting for NTP.
The previous RFC send for discussion and suggestion as link
here:
http://article.gmane.org/gmane.comp.emulators.qemu/186126
The interface for these commands like:
{ 'command': 'guest-get-time', 'returns': 'TimeInfo' }
{ 'command': 'guest-set-time',
'data': { '*seconds': 'int', '*microseconds': 'int',
'*utc-offset': 'int' } }
Notes:
I planed to send out this version with the implementition
of win32-specific commands, but got some environment issue
which I am working on. I will send it out very soon. To
avoid wasting of time, I'd like to send this out first with
the previous comments fixed to have more suggestions.
Suggestions and comments are welcome!
Changes since v1:
- Squashed patches add support to get host time and add
guest-get-time command into one.
- Documents improvment based on the suggestions from
Eric and Mike.
- Change the name of 'HostTimeInfo' to 'TimeInfo'.
- Better use-case and logic for 'guest-set-time'
command suggested by Eric.
- Error handel improvment from Luiz.
Lei Li (2):
qga: add guest-get-time command
qga: add guest-set-time command
include/qapi/qmp/qerror.h |3 +
qga/commands-posix.c | 106 +
qga/qapi-schema.json | 80 ++
3 files changed, 189 insertions(+), 0 deletions(-)
[Qemu-devel] [PATCH 1/2] qga: add guest-get-time command
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
include/qapi/qmp/qerror.h |3 +++
qga/commands-posix.c | 30 ++
qga/qapi-schema.json | 38 ++
3 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/include/qapi/qmp/qerror.h b/include/qapi/qmp/qerror.h
index 6c0a18d..0baf1a4 100644
--- a/include/qapi/qmp/qerror.h
+++ b/include/qapi/qmp/qerror.h
@@ -129,6 +129,9 @@ void assert_no_error(Error *err);
#define QERR_FEATURE_DISABLED \
ERROR_CLASS_GENERIC_ERROR, The feature '%s' is not enabled
+#define QERR_GET_TIME_FAILED \
+ERROR_CLASS_GENERIC_ERROR, Failed to get time
+
#define QERR_INVALID_BLOCK_FORMAT \
ERROR_CLASS_GENERIC_ERROR, Invalid block format '%s'
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 0ad73f3..2fef2b6 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -119,6 +119,36 @@ void qmp_guest_shutdown(bool has_mode, const char *mode,
Error **err)
/* succeded */
}
+static TimeInfo *get_host_time(Error **errp)
+{
+int ret;
+qemu_timeval tq;
+TimeInfo *time_info;
+
+ret = qemu_gettimeofday(tq);
+if (ret 0) {
+error_set_errno(errp, errno, QERR_GET_TIME_FAILED);
+return NULL;
+}
+
+time_info = g_malloc0(sizeof(TimeInfo));
+time_info-seconds = tq.tv_sec;
+time_info-microseconds = tq.tv_usec;
+
+return time_info;
+}
+
+struct TimeInfo *qmp_guest_get_time(Error **errp)
+{
+TimeInfo *time_info = get_host_time(errp);
+
+if (!time_info) {
+return NULL;
+}
+
+return time_info;
+}
+
typedef struct GuestFileHandle {
uint64_t id;
FILE *fh;
diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
index d91d903..d067fa5 100644
--- a/qga/qapi-schema.json
+++ b/qga/qapi-schema.json
@@ -83,6 +83,44 @@
{ 'command': 'guest-ping' }
##
+# @TimeInfo
+#
+# Time Information. It is relative to the Epoch of 1970-01-01.
+#
+# @seconds: seconds time unit.
+#
+# @microseconds: microseconds time unit.
+#
+# @utc-offset: Information about utc offset. Represented as:
+# ±[] based at a minimum on minutes, with
+# negative values are west and positive values
+# are east of UTC. The bounds of @utc-offset is
+# at most 24 hours away from UTC.
+#
+# Since: 1.4
+##
+{ 'type': 'TimeInfo',
+ 'data': { 'seconds': 'int', 'microseconds': 'int',
+'utc-offset': 'int' } }
+
+##
+# @guest-get-time:
+#
+# Get the information about host time in UTC and the
+# UTC offset.
+#
+# This command tries to get the host time which is
+# presumably correct, since we need to be able to
+# resynchronize guest clock to host's in guest.
+#
+# Returns: @TimeInfo on success.
+#
+# Since 1.4
+##
+{ 'command': 'guest-get-time',
+ 'returns': 'TimeInfo' }
+
+##
# @GuestAgentCommandInfo:
#
# Information about guest agent commands.
--
1.7.7.6
[Qemu-devel] [PATCH 0/2 v2] Time resync support by qemu-ga
This patch series attempts to add time resync support
to qemu-ga by introducing qemu-ga commands guest-get-time
and guest-set-time.
Right now, when a guest is paused or migrated to a file
then loaded from that file, the guest OS has no idea that
there was a big gap in the time. Depending on how long the
gap was, NTP might not be able to resynchronize the guest.
So adding new guest-agent command that is called any time
a guest is resumed and which tells the guest to update its
own wall clock time based on the information from the host
will make it easier for a guest to resynchronize without
waiting for NTP.
The previous RFC send for discussion and suggestion as link
here:
http://article.gmane.org/gmane.comp.emulators.qemu/186126
The interface for these commands like:
{ 'command': 'guest-get-time', 'returns': 'TimeInfo' }
{ 'command': 'guest-set-time',
'data': { '*seconds': 'int', '*microseconds': 'int',
'*utc-offset': 'int' } }
Notes:
I planed to send out this version with the implementition
of win32-specific commands, but got some environment issue
which I am working on. I will send it out very soon. To
avoid wasting of time, I'd like to send this out first with
the previous comments fixed to have more suggestions.
Suggestions and comments are welcome!
Changes since v1:
- Squashed patches add support to get host time and add
guest-get-time command into one.
- Documents improvment based on the suggestions from
Eric and Mike.
- Change the name of 'HostTimeInfo' to 'TimeInfo'.
- Better use-case and logic for 'guest-set-time'
command suggested by Eric.
- Error handel improvment from Luiz.
Lei Li (2):
qga: add guest-get-time command
qga: add guest-set-time command
include/qapi/qmp/qerror.h |3 +
qga/commands-posix.c | 106 +
qga/qapi-schema.json | 80 ++
3 files changed, 189 insertions(+), 0 deletions(-)
[Qemu-devel] [PATCH 1/2] qga: add guest-get-time command
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
include/qapi/qmp/qerror.h |3 +++
qga/commands-posix.c | 30 ++
qga/qapi-schema.json | 38 ++
3 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/include/qapi/qmp/qerror.h b/include/qapi/qmp/qerror.h
index 6c0a18d..0baf1a4 100644
--- a/include/qapi/qmp/qerror.h
+++ b/include/qapi/qmp/qerror.h
@@ -129,6 +129,9 @@ void assert_no_error(Error *err);
#define QERR_FEATURE_DISABLED \
ERROR_CLASS_GENERIC_ERROR, The feature '%s' is not enabled
+#define QERR_GET_TIME_FAILED \
+ERROR_CLASS_GENERIC_ERROR, Failed to get time
+
#define QERR_INVALID_BLOCK_FORMAT \
ERROR_CLASS_GENERIC_ERROR, Invalid block format '%s'
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 0ad73f3..2fef2b6 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -119,6 +119,36 @@ void qmp_guest_shutdown(bool has_mode, const char *mode,
Error **err)
/* succeded */
}
+static TimeInfo *get_host_time(Error **errp)
+{
+int ret;
+qemu_timeval tq;
+TimeInfo *time_info;
+
+ret = qemu_gettimeofday(tq);
+if (ret 0) {
+error_set_errno(errp, errno, QERR_GET_TIME_FAILED);
+return NULL;
+}
+
+time_info = g_malloc0(sizeof(TimeInfo));
+time_info-seconds = tq.tv_sec;
+time_info-microseconds = tq.tv_usec;
+
+return time_info;
+}
+
+struct TimeInfo *qmp_guest_get_time(Error **errp)
+{
+TimeInfo *time_info = get_host_time(errp);
+
+if (!time_info) {
+return NULL;
+}
+
+return time_info;
+}
+
typedef struct GuestFileHandle {
uint64_t id;
FILE *fh;
diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
index d91d903..d067fa5 100644
--- a/qga/qapi-schema.json
+++ b/qga/qapi-schema.json
@@ -83,6 +83,44 @@
{ 'command': 'guest-ping' }
##
+# @TimeInfo
+#
+# Time Information. It is relative to the Epoch of 1970-01-01.
+#
+# @seconds: seconds time unit.
+#
+# @microseconds: microseconds time unit.
+#
+# @utc-offset: Information about utc offset. Represented as:
+# ±[] based at a minimum on minutes, with
+# negative values are west and positive values
+# are east of UTC. The bounds of @utc-offset is
+# at most 24 hours away from UTC.
+#
+# Since: 1.4
+##
+{ 'type': 'TimeInfo',
+ 'data': { 'seconds': 'int', 'microseconds': 'int',
+'utc-offset': 'int' } }
+
+##
+# @guest-get-time:
+#
+# Get the information about host time in UTC and the
+# UTC offset.
+#
+# This command tries to get the host time which is
+# presumably correct, since we need to be able to
+# resynchronize guest clock to host's in guest.
+#
+# Returns: @TimeInfo on success.
+#
+# Since 1.4
+##
+{ 'command': 'guest-get-time',
+ 'returns': 'TimeInfo' }
+
+##
# @GuestAgentCommandInfo:
#
# Information about guest agent commands.
--
1.7.7.6
[Qemu-devel] [PATCH 2/2] qga: add guest-set-time command
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
qga/commands-posix.c | 76 ++
qga/qapi-schema.json | 42 +++
2 files changed, 118 insertions(+), 0 deletions(-)
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 2fef2b6..5424c50 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -149,6 +149,82 @@ struct TimeInfo *qmp_guest_get_time(Error **errp)
return time_info;
}
+void qmp_guest_set_time(bool has_seconds, int64_t seconds,
+bool has_microseconds, int64_t microseconds,
+bool has_utc_offset, int64_t utc_offset, Error **errp)
+{
+int ret;
+int status;
+pid_t pid, rpid;
+struct timeval tv;
+TimeInfo *time_info;
+
+/* year-2038 will overflow in case time_t is 32bit */
+if (sizeof(time_t) == 4) {
+return;
+}
+
+if (!has_seconds) {
+if (has_microseconds || has_utc_offset) {
+error_setg(errp, field 'seconds' missing);
+return;
+} else {
+/* Grab time from the host if no arguments given. */
+time_info = get_host_time(errp);
+if (!time_info) {
+return;
+}
+
+tv.tv_sec = time_info-seconds;
+tv.tv_usec = time_info-microseconds;
+}
+} else {
+if (abs(utc_offset) (24 * 60)) {
+error_setg(errp, 'utc_offset' shoud be less than 24 hours);
+return;
+}
+
+if (microseconds 100) {
+error_setg(errp, 'microseconds' overflow);
+return;
+}
+
+tv.tv_sec = (time_t) seconds + (has_utc_offset ? utc_offset * 60 : 0);
+tv.tv_usec = has_microseconds ? (time_t) microseconds : 0;
+}
+
+
+ret = settimeofday(tv, NULL);
+if (ret 0) {
+error_set(errp, QERR_QGA_COMMAND_FAILED, strerror(errno));
+return;
+}
+
+/* Set the Hardware Clock to the current System Time. */
+pid = fork();
+if (pid == 0) {
+setsid();
+reopen_fd_to_null(0);
+reopen_fd_to_null(1);
+reopen_fd_to_null(2);
+
+execle(/sbin/hwclock, hwclock, -w, NULL, environ);
+_exit(EXIT_FAILURE);
+} else if (pid 0) {
+goto exit_err;
+}
+
+do {
+rpid = waitpid(pid, status, 0);
+} while (rpid == -1 errno == EINTR);
+if (rpid == pid WIFEXITED(status) !WEXITSTATUS(status)) {
+return;
+}
+
+exit_err:
+error_set(errp, QERR_UNDEFINED_ERROR);
+}
+
typedef struct GuestFileHandle {
uint64_t id;
FILE *fh;
diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
index d067fa5..6eba625 100644
--- a/qga/qapi-schema.json
+++ b/qga/qapi-schema.json
@@ -121,6 +121,48 @@
'returns': 'TimeInfo' }
##
+# @guest-set-time:
+#
+# Set guest time. If no arguments were given, will set
+# host time to guest.
+#
+# Right now, when a guest is paused or migrated to a file
+# then loaded from that file, the guest OS has no idea that
+# there was a big gap in the time. Depending on how long
+# the gap was, NTP might not be able to resynchronize the
+# guest.
+#
+# This command tries to set guest time based on the information
+# from host or an absolute value given by management app, and
+# set the Hardware Clock to the current System Time. This
+# will make it easier for a guest to resynchronize without
+# waiting for NTP.
+#
+# @seconds: #optional seconds time.
+#
+# @microseconds: #optional microseconds time.
+#
+# @utc-offset: #optional utc offset.
+#
+# Returns: Nothing on success.
+#
+# Notes: If no arguments were given, will grab time from
+#the host.
+#
+#@microseconds and @utc-offset must not be provided
+#unless @seconds is present.
+#
+#If just @seconds provided, other fields would be
+#set to zero.
+#
+# present
+# Since: 1.4
+##
+{ 'command': 'guest-set-time',
+ 'data': { '*seconds': 'int', '*microseconds': 'int',
+'*utc-offset': 'int' } }
+
+##
# @GuestAgentCommandInfo:
#
# Information about guest agent commands.
--
1.7.7.6
[Qemu-devel] [PATCH qom-cpu for-1.4] target-m68k: Use type_register() instead of type_register_static()
According to its documentation, type_register_static()'s TypeInfo
argument should exist for the life type of the type.
Therefore use type_register() when registering the list of CPU subtypes.
No functional change with the current implementation.
Cf. 918fd0839eeafc83bd4984364321a947d29041fe for arm.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-m68k/cpu.c |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-m68k/cpu.c b/target-m68k/cpu.c
index e6df1ee..5c78031 100644
--- a/target-m68k/cpu.c
+++ b/target-m68k/cpu.c
@@ -162,7 +162,7 @@ static void register_cpu_type(const M68kCPUInfo *info)
.instance_init = info-instance_init,
};
-type_register_static(type_info);
+type_register(type_info);
}
static const TypeInfo m68k_cpu_type_info = {
--
1.7.10.4
Re: [Qemu-devel] [PATCH qom-cpu for-1.4 00/14] QOM CPU fixes for 1.4
Am 23.01.2013 13:07, schrieb Andreas Färber: Andreas Färber (14): target-openrisc: Don't use type_register_static() target-unicore32: Don't use type_register_static() Applied these two plus the equally trivial m68k equivalent to qom-cpu (with a more elaborate commit message like on the m68k patch): https://github.com/afaerber/qemu-cpu/commits/qom-cpu These serve as prerequisites for renaming the CPU types. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH qom-cpu for-1.4] target-m68k: Rename CPU types
In the initial conversion of CPU models to QOM types, model names were
mapped 1:1 to type names. As a side effect this gained us a type any,
which is now a device.
To avoid -device any silliness and to pave the way for compiling
multiple targets into one executable, adopt a name-arch-cpu scheme.
No functional changes for -cpu arguments or -cpu ? output.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-m68k/cpu.c|8 ++--
target-m68k/helper.c | 11 ---
2 Dateien geändert, 14 Zeilen hinzugefügt(+), 5 Zeilen entfernt(-)
diff --git a/target-m68k/cpu.c b/target-m68k/cpu.c
index 5c78031..32aaea3 100644
--- a/target-m68k/cpu.c
+++ b/target-m68k/cpu.c
@@ -58,12 +58,15 @@ static void m68k_cpu_reset(CPUState *s)
static ObjectClass *m68k_cpu_class_by_name(const char *cpu_model)
{
ObjectClass *oc;
+char *typename;
if (cpu_model == NULL) {
return NULL;
}
-oc = object_class_by_name(cpu_model);
+typename = g_strdup_printf(%s- TYPE_M68K_CPU, cpu_model);
+oc = object_class_by_name(typename);
+g_free(typename);
if (oc != NULL (object_class_dynamic_cast(oc, TYPE_M68K_CPU) == NULL ||
object_class_is_abstract(oc))) {
return NULL;
@@ -157,12 +160,13 @@ static void m68k_cpu_class_init(ObjectClass *c, void
*data)
static void register_cpu_type(const M68kCPUInfo *info)
{
TypeInfo type_info = {
-.name = info-name,
.parent = TYPE_M68K_CPU,
.instance_init = info-instance_init,
};
+type_info.name = g_strdup_printf(%s- TYPE_M68K_CPU, info-name);
type_register(type_info);
+g_free((void *)type_info.name);
}
static const TypeInfo m68k_cpu_type_info = {
diff --git a/target-m68k/helper.c b/target-m68k/helper.c
index f66e12b..5ddcd70 100644
--- a/target-m68k/helper.c
+++ b/target-m68k/helper.c
@@ -34,9 +34,9 @@ static gint m68k_cpu_list_compare(gconstpointer a,
gconstpointer b)
name_a = object_class_get_name(class_a);
name_b = object_class_get_name(class_b);
-if (strcmp(name_a, any) == 0) {
+if (strcmp(name_a, any- TYPE_M68K_CPU) == 0) {
return 1;
-} else if (strcmp(name_b, any) == 0) {
+} else if (strcmp(name_b, any- TYPE_M68K_CPU) == 0) {
return -1;
} else {
return strcasecmp(name_a, name_b);
@@ -47,9 +47,14 @@ static void m68k_cpu_list_entry(gpointer data, gpointer
user_data)
{
ObjectClass *c = data;
CPUListState *s = user_data;
+const char *typename;
+char *name;
+typename = object_class_get_name(c);
+name = g_strndup(typename, strlen(typename) - strlen(- TYPE_M68K_CPU));
(*s-cpu_fprintf)(s-file, %s\n,
- object_class_get_name(c));
+ name);
+g_free(name);
}
void m68k_cpu_list(FILE *f, fprintf_function cpu_fprintf)
--
1.7.10.4
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
On Sun, Jan 27, 2013 at 8:38 AM, David Woodhouse dw...@infradead.org wrote: On Sun, 2013-01-27 at 16:02 +, Blue Swirl wrote: On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse dw...@infradead.org wrote: On Sun, 2013-01-27 at 15:14 +, Blue Swirl wrote: It looks like this duplicates rom_add_file() and fw_cfg_add_file(), so I don't see the point. Both of those are read-only, surely? The firmware inside the guest can't use them for non-volatile storage. Right. But why do we need PV non-volatile storage, instead of normal flash? People have looked at adding normal flash to the PC target, FWIW, I do have non-volatile variables working for OVMF using http://wiki.qemu.org/Features/PC_System_Flash but it has a number of problems. Firstly, it doesn't even *work* with KVM enabled. Avi tells me KVM_MEM_READONLY may be a big step in solving this. But, I'll admit that I've not made much progress on this part of the task. But even if we were to somehow fix that, the simple approach of emulating a BIOS flash is also very suboptimal; it puts the whole of the firmware *into* the flash and lets it store its non-volatile variables in the same emulated flash chip. So if you want to update the firmware (which would normally be just a case of updating the bios.bin file), you end up having to do each guest system individually *and* the update is painful because you have to preserve the non-volatile storage while updating the other parts. It is a good point, and I originally thought of keeping them separate, but it seems like we ended up heading down the PC System Flash path. I think at one point being able to keep the firmware image static when QEMU updated might have been seen as an advantage. Based on several years experience, I think OVMF builds have continued to work well with older and newer versions of QEMU. Yet, for the user that just wants to have the latest firmware, well we all probably know how much fun bios upgrades can be. :) Anyway, I think OVMF probably will end up supporting PC System Flash for non-volatile variables in addition to what ever comes of this discussion. It's much better to have a separate storage for the non-volatile variables. Yes, we *could* teach it to use a dedicated flash chip for that rather than using flash for the firmware *and* storage as we would on real hardware. But if we're going to do something different for the virtualised case, a writeable fw_cfg file seems a whole lot easier and saner. I just wish fw_cfg had a more flash-friendly interface. The EDK II variable storage prefers random access to the non-volatile storage bytes. The infrastructure generally is built around random writes and block erases. -Jordan
[Qemu-devel] [PATCH qom-cpu for-1.4] target-openrisc: TYPE_OPENRISC_CPU should be abstract
A basic assumption of CPU subtypes is that only specific models get
instantiated. A user is not supposed to instantiate an arch-cpu.
Suppress it via abstract = true, which also drops or32-cpu from
-cpu ? output.
Cc: qemu-sta...@nongnu.org
Cc: Jia Liu pro...@gmail.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-openrisc/cpu.c |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-openrisc/cpu.c b/target-openrisc/cpu.c
index 54876d9..14f2cbe 100644
--- a/target-openrisc/cpu.c
+++ b/target-openrisc/cpu.c
@@ -159,7 +159,7 @@ static const TypeInfo openrisc_cpu_type_info = {
.parent = TYPE_CPU,
.instance_size = sizeof(OpenRISCCPU),
.instance_init = openrisc_cpu_initfn,
-.abstract = false,
+.abstract = true,
.class_size = sizeof(OpenRISCCPUClass),
.class_init = openrisc_cpu_class_init,
};
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4] target-openrisc: Rename CPU subtypes
Model names were mapped 1:1 to type names. As a side effect this
registered a type any, which is now a device.
To avoid -device any silliness and to pave the way for compiling
multiple targets into one executable, adopt a name-arch-cpu scheme.
No functional changes for -cpu arguments or -cpu ? output.
Cc: Jia Liu pro...@gmail.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-openrisc/cpu.c | 15 +++
1 Datei geändert, 11 Zeilen hinzugefügt(+), 4 Zeilen entfernt(-)
diff --git a/target-openrisc/cpu.c b/target-openrisc/cpu.c
index 14f2cbe..a7a8de8 100644
--- a/target-openrisc/cpu.c
+++ b/target-openrisc/cpu.c
@@ -144,14 +144,15 @@ static void openrisc_cpu_class_init(ObjectClass *oc, void
*data)
static void cpu_register(const OpenRISCCPUInfo *info)
{
TypeInfo type_info = {
-.name = info-name,
.parent = TYPE_OPENRISC_CPU,
.instance_size = sizeof(OpenRISCCPU),
.instance_init = info-initfn,
.class_size = sizeof(OpenRISCCPUClass),
};
+type_info.name = g_strdup_printf(%s- TYPE_OPENRISC_CPU, info-name);
type_register(type_info);
+g_free((void *)type_info.name);
}
static const TypeInfo openrisc_cpu_type_info = {
@@ -200,9 +201,9 @@ static gint openrisc_cpu_list_compare(gconstpointer a,
gconstpointer b)
name_a = object_class_get_name(class_a);
name_b = object_class_get_name(class_b);
-if (strcmp(name_a, any) == 0) {
+if (strcmp(name_a, any- TYPE_OPENRISC_CPU) == 0) {
return 1;
-} else if (strcmp(name_b, any) == 0) {
+} else if (strcmp(name_b, any- TYPE_OPENRISC_CPU) == 0) {
return -1;
} else {
return strcmp(name_a, name_b);
@@ -213,9 +214,15 @@ static void openrisc_cpu_list_entry(gpointer data,
gpointer user_data)
{
ObjectClass *oc = data;
CPUListState *s = user_data;
+const char *typename;
+char *name;
+typename = object_class_get_name(oc);
+name = g_strndup(typename,
+ strlen(typename) - strlen(- TYPE_OPENRISC_CPU));
(*s-cpu_fprintf)(s-file, %s\n,
- object_class_get_name(oc));
+ name);
+g_free(name);
}
void cpu_openrisc_list(FILE *f, fprintf_function cpu_fprintf)
--
1.7.10.4
Re: [Qemu-devel] [PATCH qom-cpu for-1.4 08/14] target-unicore32: Detect attempt to instantiate non-CPU type in cpu_init()
Am 23.01.2013 13:07, schrieb Andreas Färber:
diff --git a/target-unicore32/helper.c b/target-unicore32/helper.c
index 5359538..7ace68c 100644
--- a/target-unicore32/helper.c
+++ b/target-unicore32/helper.c
@@ -29,9 +29,11 @@ CPUUniCore32State *uc32_cpu_init(const char *cpu_model)
{
UniCore32CPU *cpu;
CPUUniCore32State *env;
+ObjectClass *oc;
static int inited = 1;
-if (object_class_by_name(cpu_model) == NULL) {
+oc = cpu_class_by_name(TYPE_UNICORE32_CPU, cpu_model);
+if (oc == NULL) {
return NULL;
}
cpu = UNICORE32_CPU(object_new(cpu_model));
Should be using object_class_get_name(oc) instead of cpu_model:
diff --git a/target-unicore32/helper.c b/target-unicore32/helper.c
index 7ace68c..183b5b3 100644
--- a/target-unicore32/helper.c
+++ b/target-unicore32/helper.c
@@ -36,7 +36,7 @@ CPUUniCore32State *uc32_cpu_init(const char *cpu_model)
if (oc == NULL) {
return NULL;
}
-cpu = UNICORE32_CPU(object_new(cpu_model));
+cpu = UNICORE32_CPU(object_new(object_class_get_name(oc)));
env = cpu-env;
if (inited) {
Fixed.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH qom-cpu for-1.4] target-unicore32: Rename CPU subtypes
In the initial conversion of CPU models to QOM types, model names were
mapped 1:1 to type names. As a side effect this gained us a type any,
which is now a device.
To avoid -device any silliness and to pave the way for compiling
multiple targets into one executable, adopt a name-arch-cpu scheme.
No functional changes for -cpu arguments.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-unicore32/cpu.c |8 ++--
1 Datei geändert, 6 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c
index c120440..28c2fa0 100644
--- a/target-unicore32/cpu.c
+++ b/target-unicore32/cpu.c
@@ -25,12 +25,15 @@ static inline void set_feature(CPUUniCore32State *env, int
feature)
static ObjectClass *uc32_cpu_class_by_name(const char *cpu_model)
{
ObjectClass *oc;
+char *typename;
if (cpu_model == NULL) {
return NULL;
}
-oc = object_class_by_name(cpu_model);
+typename = g_strdup_printf(%s- TYPE_UNICORE32_CPU, cpu_model);
+oc = object_class_by_name(typename);
+g_free(typename);
if (oc != NULL (!object_class_dynamic_cast(oc, TYPE_UNICORE32_CPU) ||
object_class_is_abstract(oc))) {
oc = NULL;
@@ -106,12 +109,13 @@ static void uc32_cpu_class_init(ObjectClass *oc, void
*data)
static void uc32_register_cpu_type(const UniCore32CPUInfo *info)
{
TypeInfo type_info = {
-.name = info-name,
.parent = TYPE_UNICORE32_CPU,
.instance_init = info-instance_init,
};
+type_info.name = g_strdup_printf(%s- TYPE_UNICORE32_CPU, info-name);
type_register(type_info);
+g_free((void *)type_info.name);
}
static const TypeInfo uc32_cpu_type_info = {
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 2/6] target-microblaze: Mark as unmigratable
cpu_{save,load} were no-ops, so de facto it is unmigratable and no
backwards compatibility to keep. Therefore mark the MicroBlazeCPU as
unmigratable at device level the QOM way and suppress cpu_common
VMState registration by dropping CPU_SAVE_VERSION.
Signed-off-by: Juan Quintela quint...@redhat.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-microblaze/Makefile.objs |2 +-
target-microblaze/cpu.c |9 +
target-microblaze/cpu.h |2 --
target-microblaze/machine.c | 11 ---
4 Dateien geändert, 10 Zeilen hinzugefügt(+), 14 Zeilen entfernt(-)
delete mode 100644 target-microblaze/machine.c
diff --git a/target-microblaze/Makefile.objs b/target-microblaze/Makefile.objs
index afb87bc..985330e 100644
--- a/target-microblaze/Makefile.objs
+++ b/target-microblaze/Makefile.objs
@@ -1,2 +1,2 @@
obj-y += translate.o op_helper.o helper.o cpu.o
-obj-$(CONFIG_SOFTMMU) += mmu.o machine.o
+obj-$(CONFIG_SOFTMMU) += mmu.o
diff --git a/target-microblaze/cpu.c b/target-microblaze/cpu.c
index 0f858fd..39230fd 100644
--- a/target-microblaze/cpu.c
+++ b/target-microblaze/cpu.c
@@ -22,6 +22,7 @@
#include cpu.h
#include qemu-common.h
+#include migration/vmstate.h
/* CPUClass::reset() */
@@ -94,13 +95,21 @@ static void mb_cpu_initfn(Object *obj)
set_float_rounding_mode(float_round_nearest_even, env-fp_status);
}
+static const VMStateDescription vmstate_mb_cpu = {
+.name = cpu,
+.unmigratable = 1,
+};
+
static void mb_cpu_class_init(ObjectClass *oc, void *data)
{
+DeviceClass *dc = DEVICE_CLASS(oc);
CPUClass *cc = CPU_CLASS(oc);
MicroBlazeCPUClass *mcc = MICROBLAZE_CPU_CLASS(oc);
mcc-parent_reset = cc-reset;
cc-reset = mb_cpu_reset;
+
+dc-vmsd = vmstate_mb_cpu;
}
static const TypeInfo mb_cpu_type_info = {
diff --git a/target-microblaze/cpu.h b/target-microblaze/cpu.h
index 5621068..41480e7 100644
--- a/target-microblaze/cpu.h
+++ b/target-microblaze/cpu.h
@@ -307,8 +307,6 @@ static inline CPUMBState *cpu_init(const char *cpu_model)
#define cpu_gen_code cpu_mb_gen_code
#define cpu_signal_handler cpu_mb_signal_handler
-#define CPU_SAVE_VERSION 1
-
/* MMU modes definitions */
#define MMU_MODE0_SUFFIX _nommu
#define MMU_MODE1_SUFFIX _kernel
diff --git a/target-microblaze/machine.c b/target-microblaze/machine.c
deleted file mode 100644
index 1be1c35..000
--- a/target-microblaze/machine.c
+++ /dev/null
@@ -1,11 +0,0 @@
-#include hw/hw.h
-#include hw/boards.h
-
-void cpu_save(QEMUFile *f, void *opaque)
-{
-}
-
-int cpu_load(QEMUFile *f, void *opaque, int version_id)
-{
-return 0;
-}
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 0/6] Unmigratable CPUs for 1.4
Hello,
Prompted by earlier patches from Juan, this series cleans up some targets
that don't implement migration - be it by no-op implementations, by erroring
out in the implementation or by lack of implementation.
Making targets migratable is preferable over
marking devices as migratable is preferable over
terminating QEMU while attempting to migrate.
This series, based on qom-cpu queue, takes advantage of us having converted
the CPUState into a device for the upcoming release by associating
VMStateDescriptions marked as unmigratable with the target's base CPU class.
By dropping the machine.c files, now no longer mandated by the build system,
we also elegantly solve the issue of lacking license headers. :)
Known conflicts:
* CPU realizefn series on qom-cpu-next (cpu.c:class_init)
A follow-up series based on qom-cpu-next is in preparation, to tackle the bug
that alpha implements cpu_{save,load}() but does not have them registered,
rendering the implementation virtually useless IIUC.
I am still a bit unclear about the compatibility considerations: There are
subtle differences in calculating the instance_id between CPUArchState and
DeviceClass. Since no one complained about alpha so far I would like to defer
this to 1.5 to evaluate whether to handle VMState differently for new CPUs wrt
cpu_common, cpu and DeviceClass vs. CPUClass (preview on qom-cpu-vmstate).
Regards,
Andreas
Cc: Juan Quintela quint...@redhat.com (vmstate)
Cc: Edgar E. Iglesias edgar.igles...@gmail.com (microblaze)
Cc: Peter Crosthwaite peter.crosthwa...@xilinx.com (microblaze)
Cc: Alexander Graf ag...@suse.de (s390x)
Cc: Richard Henderson r...@twiddle.net (s390x)
Cc: Aurélien Jarno aurel...@aurel32.net (sh4)
Cc: Guan Xuetao g...@mprc.pku.edu.cn (uc32)
Cc: Max Filippov jcmvb...@gmail.com (xtensa)
Cc: Anthony Liguori anth...@codemonkey.ws
Andreas Färber (6):
target-unicore32: Mark as unmigratable
target-microblaze: Mark as unmigratable
target-xtensa: Mark as unmigratable
target-sh4: Mark as unmigratable
target-s390x: Mark as unmigratable
target-m68k: Mark as unmigratable
target-m68k/Makefile.objs |1 -
target-m68k/cpu.c |8
target-microblaze/Makefile.objs |2 +-
target-microblaze/cpu.c |9 +
target-microblaze/cpu.h |2 --
target-microblaze/machine.c | 11 ---
target-s390x/Makefile.objs |1 -
target-s390x/cpu.c | 10 +-
target-s390x/machine.c | 30 --
target-sh4/Makefile.objs|1 -
target-sh4/cpu.c|9 +
target-unicore32/Makefile.objs |2 +-
target-unicore32/cpu.c |8
target-unicore32/cpu.h |2 --
target-unicore32/machine.c | 23 ---
target-xtensa/Makefile.objs |1 -
target-xtensa/cpu.c |9 +
target-xtensa/machine.c | 38 --
18 Dateien geändert, 54 Zeilen hinzugefügt(+), 113 Zeilen entfernt(-)
delete mode 100644 target-m68k/machine.c
delete mode 100644 target-microblaze/machine.c
delete mode 100644 target-s390x/machine.c
delete mode 100644 target-sh4/machine.c
delete mode 100644 target-unicore32/machine.c
delete mode 100644 target-xtensa/machine.c
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 1/6] target-unicore32: Mark as unmigratable
CPU_SAVE_VERSION 2 was bogus as both save and load would just throw a
hw_error(). Therefore we can without problems suppress registration of
cpu_common VMState by dropping CPU_SAVE_VERSION define and provide an
unmigratable cpu VMStateDescription for UniCore32CPU at device level
instead, where we can attach this the QOM way.
Signed-off-by: Juan Quintela quint...@redhat.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-unicore32/Makefile.objs |2 +-
target-unicore32/cpu.c |8
target-unicore32/cpu.h |2 --
target-unicore32/machine.c | 23 ---
4 Dateien geändert, 9 Zeilen hinzugefügt(+), 26 Zeilen entfernt(-)
delete mode 100644 target-unicore32/machine.c
diff --git a/target-unicore32/Makefile.objs b/target-unicore32/Makefile.objs
index 8e143da..6b41b1e 100644
--- a/target-unicore32/Makefile.objs
+++ b/target-unicore32/Makefile.objs
@@ -1,4 +1,4 @@
obj-y += translate.o op_helper.o helper.o cpu.o
obj-y += ucf64_helper.o
-obj-$(CONFIG_SOFTMMU) += machine.o softmmu.o
+obj-$(CONFIG_SOFTMMU) += softmmu.o
diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c
index c120440..18ef1c5 100644
--- a/target-unicore32/cpu.c
+++ b/target-unicore32/cpu.c
@@ -14,6 +14,7 @@
#include cpu.h
#include qemu-common.h
+#include migration/vmstate.h
static inline void set_feature(CPUUniCore32State *env, int feature)
{
@@ -96,11 +97,18 @@ static void uc32_cpu_initfn(Object *obj)
tlb_flush(env, 1);
}
+static const VMStateDescription vmstate_uc32_cpu = {
+.name = cpu,
+.unmigratable = 1,
+};
+
static void uc32_cpu_class_init(ObjectClass *oc, void *data)
{
+DeviceClass *dc = DEVICE_CLASS(oc);
CPUClass *cc = CPU_CLASS(oc);
cc-class_by_name = uc32_cpu_class_by_name;
+dc-vmsd = vmstate_uc32_cpu;
}
static void uc32_register_cpu_type(const UniCore32CPUInfo *info)
diff --git a/target-unicore32/cpu.h b/target-unicore32/cpu.h
index 509ce7c..ae9a9d6 100644
--- a/target-unicore32/cpu.h
+++ b/target-unicore32/cpu.h
@@ -133,8 +133,6 @@ int uc32_cpu_signal_handler(int host_signum, void *pinfo,
void *puc);
int uc32_cpu_handle_mmu_fault(CPUUniCore32State *env, target_ulong address,
int rw,
int mmu_idx);
-#define CPU_SAVE_VERSION 2
-
/* MMU modes definitions */
#define MMU_MODE0_SUFFIX _kernel
#define MMU_MODE1_SUFFIX _user
diff --git a/target-unicore32/machine.c b/target-unicore32/machine.c
deleted file mode 100644
index 60b2ec1..000
--- a/target-unicore32/machine.c
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * Generic machine functions for UniCore32 ISA
- *
- * Copyright (C) 2010-2012 Guan Xuetao
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation, or any later version.
- * See the COPYING file in the top-level directory.
- */
-#include hw/hw.h
-
-void cpu_save(QEMUFile *f, void *opaque)
-{
-hw_error(%s not supported yet.\n, __func__);
-}
-
-int cpu_load(QEMUFile *f, void *opaque, int version_id)
-{
-hw_error(%s not supported yet.\n, __func__);
-
-return 0;
-}
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 6/6] target-m68k: Mark as unmigratable
It neither defined CPU_SAVE_VERSION nor implemented cpu_{save,load}().
Mark M68kCPU as unmigratable at device level.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-m68k/Makefile.objs |1 -
target-m68k/cpu.c |8
2 Dateien geändert, 8 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
delete mode 100644 target-m68k/machine.c
diff --git a/target-m68k/Makefile.objs b/target-m68k/Makefile.objs
index 7eccfab..2e2b850 100644
--- a/target-m68k/Makefile.objs
+++ b/target-m68k/Makefile.objs
@@ -1,3 +1,2 @@
obj-y += m68k-semi.o
obj-y += translate.o op_helper.o helper.o cpu.o
-obj-$(CONFIG_SOFTMMU) += machine.o
diff --git a/target-m68k/cpu.c b/target-m68k/cpu.c
index 5c78031..c911b8f 100644
--- a/target-m68k/cpu.c
+++ b/target-m68k/cpu.c
@@ -20,6 +20,7 @@
#include cpu.h
#include qemu-common.h
+#include migration/vmstate.h
static void m68k_set_feature(CPUM68KState *env, int feature)
@@ -143,15 +144,22 @@ static void m68k_cpu_initfn(Object *obj)
cpu_exec_init(env);
}
+static const VMStateDescription vmstate_m68k_cpu = {
+.name = cpu,
+.unmigratable = 1,
+};
+
static void m68k_cpu_class_init(ObjectClass *c, void *data)
{
M68kCPUClass *mcc = M68K_CPU_CLASS(c);
CPUClass *cc = CPU_CLASS(c);
+DeviceClass *dc = DEVICE_CLASS(c);
mcc-parent_reset = cc-reset;
cc-reset = m68k_cpu_reset;
cc-class_by_name = m68k_cpu_class_by_name;
+dc-vmsd = vmstate_m68k_cpu;
}
static void register_cpu_type(const M68kCPUInfo *info)
diff --git a/target-m68k/machine.c b/target-m68k/machine.c
deleted file mode 100644
index e69de29..000
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 3/6] target-xtensa: Mark as unmigratable
There was no CPU_SAVE_VERSION defined, so neither cpu_common VMState
nor cpu_{save,load}() were registered. Their implementation was no-op.
Therefore there is no backwards compatibility to keep, so mark XtensaCPU
as unmigratable at device level.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-xtensa/Makefile.objs |1 -
target-xtensa/cpu.c |9 +
target-xtensa/machine.c | 38 --
3 Dateien geändert, 9 Zeilen hinzugefügt(+), 39 Zeilen entfernt(-)
delete mode 100644 target-xtensa/machine.c
diff --git a/target-xtensa/Makefile.objs b/target-xtensa/Makefile.objs
index b30e5a8..644b7f9 100644
--- a/target-xtensa/Makefile.objs
+++ b/target-xtensa/Makefile.objs
@@ -3,4 +3,3 @@ obj-y += core-dc232b.o
obj-y += core-dc233c.o
obj-y += core-fsf.o
obj-y += translate.o op_helper.o helper.o cpu.o
-obj-$(CONFIG_SOFTMMU) += machine.o
diff --git a/target-xtensa/cpu.c b/target-xtensa/cpu.c
index 035b07c..ebc7e99 100644
--- a/target-xtensa/cpu.c
+++ b/target-xtensa/cpu.c
@@ -30,6 +30,7 @@
#include cpu.h
#include qemu-common.h
+#include migration/vmstate.h
/* CPUClass::reset() */
@@ -64,13 +65,21 @@ static void xtensa_cpu_initfn(Object *obj)
cpu_exec_init(env);
}
+static const VMStateDescription vmstate_xtensa_cpu = {
+.name = cpu,
+.unmigratable = 1,
+};
+
static void xtensa_cpu_class_init(ObjectClass *oc, void *data)
{
+DeviceClass *dc = DEVICE_CLASS(oc);
CPUClass *cc = CPU_CLASS(oc);
XtensaCPUClass *xcc = XTENSA_CPU_CLASS(cc);
xcc-parent_reset = cc-reset;
cc-reset = xtensa_cpu_reset;
+
+dc-vmsd = vmstate_xtensa_cpu;
}
static const TypeInfo xtensa_cpu_type_info = {
diff --git a/target-xtensa/machine.c b/target-xtensa/machine.c
deleted file mode 100644
index ddeffb2..000
--- a/target-xtensa/machine.c
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * Copyright (c) 2011, Max Filippov, Open Source and Linux Lab.
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- * * Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution.
- * * Neither the name of the Open Source and Linux Lab nor the
- * names of its contributors may be used to endorse or promote products
- * derived from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
- * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
- * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
- * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-#include hw/hw.h
-#include hw/boards.h
-
-void cpu_save(QEMUFile *f, void *opaque)
-{
-}
-
-int cpu_load(QEMUFile *f, void *opaque, int version_id)
-{
-return 0;
-}
--
1.7.10.4
Re: [Qemu-devel] [PATCH qom-cpu for-1.4 0/6] Unmigratable CPUs for 1.4
Am 28.01.2013 01:13, schrieb Andreas Färber:
Hello,
Prompted by earlier patches from Juan, this series cleans up some targets
that don't implement migration - be it by no-op implementations, by erroring
out in the implementation or by lack of implementation.
Making targets migratable is preferable over
marking devices as migratable is preferable over
as unmigratable, obviously :)
terminating QEMU while attempting to migrate.
This series, based on qom-cpu queue, takes advantage of us having converted
the CPUState into a device for the upcoming release by associating
VMStateDescriptions marked as unmigratable with the target's base CPU class.
By dropping the machine.c files, now no longer mandated by the build system,
we also elegantly solve the issue of lacking license headers. :)
Known conflicts:
* CPU realizefn series on qom-cpu-next (cpu.c:class_init)
A follow-up series based on qom-cpu-next is in preparation, to tackle the bug
that alpha implements cpu_{save,load}() but does not have them registered,
rendering the implementation virtually useless IIUC.
I am still a bit unclear about the compatibility considerations: There are
subtle differences in calculating the instance_id between CPUArchState and
DeviceClass. Since no one complained about alpha so far I would like to defer
this to 1.5 to evaluate whether to handle VMState differently for new CPUs wrt
cpu_common, cpu and DeviceClass vs. CPUClass (preview on qom-cpu-vmstate).
Regards,
Andreas
Cc: Juan Quintela quint...@redhat.com (vmstate)
Cc: Edgar E. Iglesias edgar.igles...@gmail.com (microblaze)
Cc: Peter Crosthwaite peter.crosthwa...@xilinx.com (microblaze)
Cc: Alexander Graf ag...@suse.de (s390x)
Cc: Richard Henderson r...@twiddle.net (s390x)
Cc: Aurélien Jarno aurel...@aurel32.net (sh4)
Cc: Guan Xuetao g...@mprc.pku.edu.cn (uc32)
Cc: Max Filippov jcmvb...@gmail.com (xtensa)
Cc: Anthony Liguori anth...@codemonkey.ws
Andreas Färber (6):
target-unicore32: Mark as unmigratable
target-microblaze: Mark as unmigratable
target-xtensa: Mark as unmigratable
target-sh4: Mark as unmigratable
target-s390x: Mark as unmigratable
target-m68k: Mark as unmigratable
target-m68k/Makefile.objs |1 -
target-m68k/cpu.c |8
target-microblaze/Makefile.objs |2 +-
target-microblaze/cpu.c |9 +
target-microblaze/cpu.h |2 --
target-microblaze/machine.c | 11 ---
target-s390x/Makefile.objs |1 -
target-s390x/cpu.c | 10 +-
target-s390x/machine.c | 30 --
target-sh4/Makefile.objs|1 -
target-sh4/cpu.c|9 +
target-unicore32/Makefile.objs |2 +-
target-unicore32/cpu.c |8
target-unicore32/cpu.h |2 --
target-unicore32/machine.c | 23 ---
target-xtensa/Makefile.objs |1 -
target-xtensa/cpu.c |9 +
target-xtensa/machine.c | 38 --
18 Dateien geändert, 54 Zeilen hinzugefügt(+), 113 Zeilen entfernt(-)
delete mode 100644 target-m68k/machine.c
delete mode 100644 target-microblaze/machine.c
delete mode 100644 target-s390x/machine.c
delete mode 100644 target-sh4/machine.c
delete mode 100644 target-unicore32/machine.c
delete mode 100644 target-xtensa/machine.c
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH qom-cpu for-1.4 5/6] target-s390x: Mark as unmigratable
CPU_SAVE_VERSION was undefined, so cpu_common VMState and
cpu_{save,load}() were not registered. They were no-ops.
Therefore there is no backwards compatibility to keep, so we can mark
S390CPU as unmigratable at device level.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-s390x/Makefile.objs |1 -
target-s390x/cpu.c | 10 +-
target-s390x/machine.c | 30 --
3 Dateien geändert, 9 Zeilen hinzugefügt(+), 32 Zeilen entfernt(-)
delete mode 100644 target-s390x/machine.c
diff --git a/target-s390x/Makefile.objs b/target-s390x/Makefile.objs
index e728abf..a4a4c1a 100644
--- a/target-s390x/Makefile.objs
+++ b/target-s390x/Makefile.objs
@@ -1,4 +1,3 @@
obj-y += translate.o helper.o cpu.o interrupt.o
obj-y += int_helper.o fpu_helper.o cc_helper.o mem_helper.o misc_helper.o
-obj-$(CONFIG_SOFTMMU) += machine.o
obj-$(CONFIG_KVM) += kvm.o
diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
index 0b68db8..a0c4479 100644
--- a/target-s390x/cpu.c
+++ b/target-s390x/cpu.c
@@ -26,8 +26,8 @@
#include cpu.h
#include qemu-common.h
#include qemu/timer.h
-#ifndef CONFIG_USER_ONLY
#include hw/hw.h
+#ifndef CONFIG_USER_ONLY
#include sysemu/arch_init.h
#endif
@@ -135,13 +135,21 @@ static void s390_cpu_finalize(Object *obj)
#endif
}
+static const VMStateDescription vmstate_s390_cpu = {
+.name = cpu,
+.unmigratable = 1,
+};
+
static void s390_cpu_class_init(ObjectClass *oc, void *data)
{
S390CPUClass *scc = S390_CPU_CLASS(oc);
CPUClass *cc = CPU_CLASS(scc);
+DeviceClass *dc = DEVICE_CLASS(oc);
scc-parent_reset = cc-reset;
cc-reset = s390_cpu_reset;
+
+dc-vmsd = vmstate_s390_cpu;
}
static const TypeInfo s390_cpu_type_info = {
diff --git a/target-s390x/machine.c b/target-s390x/machine.c
deleted file mode 100644
index 3e79be6..000
--- a/target-s390x/machine.c
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * QEMU S390x machine definitions
- *
- * Copyright (c) 2009 Alexander Graf ag...@suse.de
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, see http://www.gnu.org/licenses/.
- */
-
-#include hw/hw.h
-#include hw/boards.h
-
-void cpu_save(QEMUFile *f, void *opaque)
-{
-}
-
-int cpu_load(QEMUFile *f, void *opaque, int version_id)
-{
-return 0;
-}
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 4/6] target-sh4: Mark as unmigratable
It neither defined CPU_SAVE_VERSION nor implemented cpu{save,load}().
Mark it as unmigratable at device level.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-sh4/Makefile.objs |1 -
target-sh4/cpu.c |9 +
2 Dateien geändert, 9 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
delete mode 100644 target-sh4/machine.c
diff --git a/target-sh4/Makefile.objs b/target-sh4/Makefile.objs
index ca20f21..cb448a8 100644
--- a/target-sh4/Makefile.objs
+++ b/target-sh4/Makefile.objs
@@ -1,2 +1 @@
obj-y += translate.o op_helper.o helper.o cpu.o
-obj-$(CONFIG_SOFTMMU) += machine.o
diff --git a/target-sh4/cpu.c b/target-sh4/cpu.c
index e4858a0..d283122 100644
--- a/target-sh4/cpu.c
+++ b/target-sh4/cpu.c
@@ -21,6 +21,7 @@
#include cpu.h
#include qemu-common.h
+#include migration/vmstate.h
/* CPUClass::reset() */
@@ -63,13 +64,21 @@ static void superh_cpu_initfn(Object *obj)
env-movcal_backup_tail = (env-movcal_backup);
}
+static const VMStateDescription vmstate_sh_cpu = {
+.name = cpu,
+.unmigratable = 1,
+};
+
static void superh_cpu_class_init(ObjectClass *oc, void *data)
{
+DeviceClass *dc = DEVICE_CLASS(oc);
CPUClass *cc = CPU_CLASS(oc);
SuperHCPUClass *scc = SUPERH_CPU_CLASS(oc);
scc-parent_reset = cc-reset;
cc-reset = superh_cpu_reset;
+
+dc-vmsd = vmstate_sh_cpu;
}
static const TypeInfo superh_cpu_type_info = {
diff --git a/target-sh4/machine.c b/target-sh4/machine.c
deleted file mode 100644
index e69de29..000
--
1.7.10.4
Re: [Qemu-devel] [RFC] Writeable files in fw_cfg
David Woodhouse dw...@infradead.org writes: On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote: David Woodhouse dw...@infradead.org writes: For OVMF we really want to have a way to store non-volatile variables, other than the dirty hack that currently puts them on a file in the EFI system partition. It looks like we've supported writing to fw_cfg items fairly much since they were introduced, but we've never actually made use of that. This WIP patch kills the existing fw_cfg_add_callback() because I can't see how it would ever be useful, and it doesn't seem to have been used for years, if ever. And adds something slightly more useful. Other then the obvious bits that need finishing, any objections? The main issue is malicious guests. The administrator has to be aware of and in control of how much disk space the guest can use. The secondary issue is how to tie into the block layer so things like live migration work. This is why use a flash device is an attractive answer here because it gives a fixed sized storage pool that's configurable by the administrator. That part is fixable simply by imposing a maximum size, surely? Are you just trying to persist a single blob of a fixed maximum size? Why not just have a second flash device then? Since it's backed by a block device, it supports all of the features needed for non-volatile storage (snapshotting, live copy, etc.). The only real downside is that it's opaque to the host. If it's desirable to have something that's visible to the host, then I think we would still need to make use of BlockDriverState as the means to make it non-volatile. I don't really care about it being visible to the host. The important thing is that it's easily usable from the guest firmware at runtime, and not on a device that the OS might be trying to use. Their current trick is a file on the EFI system partition, which is definitely *not* acceptable. It doesn't work after the OS has booted, so even basic tasks like install an OS and hope the installer can set the boot variables to boot into it are broken. For exposing it to the guest, writeable fw_cfg definitely seems like the most attractive answer. I'll look at backing it with BlockDriverState. I don't even think we need a file system on it; it can just be a fixed-size device exposed as-is, surely? If you just want to write out a blob, I'm not sure why you prefer to use fw_cfg vs. a flash interface. Regards, Anthony Liguori -- dwmw2
Re: [Qemu-devel] [PATCH V5 03/13] block: add bdrv_can_read_snapshot() function
于 2013-1-26 2:11, Eric Blake 写道:
On 01/23/2013 07:57 PM, Wenchao Xia wrote:
Compared to bdrv_can_snapshot(), this function return whether
bs* is ready to read snapshot info from instead of write. If yes,
caller can then query snapshot information, but taking snapshot
is not always possible for that *bs may be read only.
Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
---
block.c | 19 +++
include/block/block.h |1 +
2 files changed, 20 insertions(+), 0 deletions(-)
+/* return whether internal snapshot can be read on @bs */
+int bdrv_can_read_snapshot(BlockDriverState *bs)
+{
+/* return whether internal snapshot can be write on @bs */
int bdrv_can_snapshot(BlockDriverState *bs)
I see you just copied existing code; but any reason why these functions
return int instead of bool? Would that be worth a separate cleanup patch?
Reviewed-by: Eric Blake ebl...@redhat.com
Just follow bdrv_can_snapshot() style, no special reason.:)
I think it is OK for a clean up patch following.
--
Best Regards
Wenchao Xia
Re: [Qemu-devel] [PATCH V15 0/9] libqblock qemu block layer library
Sorry for that, do you know how to enable these extra checks? I used default configuration by ./configure and did not check out this errors. Hi, Thank you for submitting your patch series. This patch breaks the build by causing make to fail. Here's the output: GEN i386-softmmu/config-devices.mak GEN x86_64-softmmu/config-devices.mak GEN alpha-softmmu/config-devices.mak GEN arm-softmmu/config-devices.mak GEN cris-softmmu/config-devices.mak GEN lm32-softmmu/config-devices.mak GEN m68k-softmmu/config-devices.mak GEN microblaze-softmmu/config-devices.mak GEN microblazeel-softmmu/config-devices.mak GEN mips-softmmu/config-devices.mak GEN mipsel-softmmu/config-devices.mak GEN mips64-softmmu/config-devices.mak GEN ppc-softmmu/config-devices.mak GEN ppcemb-softmmu/config-devices.mak GEN mips64el-softmmu/config-devices.mak GEN or32-softmmu/config-devices.mak GEN ppc64-softmmu/config-devices.mak GEN sh4-softmmu/config-devices.mak GEN sh4eb-softmmu/config-devices.mak GEN sparc64-softmmu/config-devices.mak GEN sparc-softmmu/config-devices.mak GEN s390x-softmmu/config-devices.mak GEN xtensa-softmmu/config-devices.mak GEN xtensaeb-softmmu/config-devices.mak GEN unicore32-softmmu/config-devices.mak GEN i386-linux-user/config-devices.mak GEN x86_64-linux-user/config-devices.mak GEN alpha-linux-user/config-devices.mak GEN arm-linux-user/config-devices.mak GEN cris-linux-user/config-devices.mak GEN m68k-linux-user/config-devices.mak GEN microblaze-linux-user/config-devices.mak GEN microblazeel-linux-user/config-devices.mak GEN armeb-linux-user/config-devices.mak GEN mips-linux-user/config-devices.mak GEN or32-linux-user/config-devices.mak GEN mipsel-linux-user/config-devices.mak GEN ppc-linux-user/config-devices.mak GEN ppc64-linux-user/config-devices.mak GEN ppc64abi32-linux-user/config-devices.mak GEN sh4-linux-user/config-devices.mak GEN sh4eb-linux-user/config-devices.mak GEN sparc-linux-user/config-devices.mak GEN sparc64-linux-user/config-devices.mak GEN sparc32plus-linux-user/config-devices.mak GEN unicore32-linux-user/config-devices.mak GEN s390x-linux-user/config-devices.mak GEN config-host.h GEN qemu-options.def GEN qmp-commands.h GEN qapi-types.h GEN qapi-visit.h GEN trace/generated-tracers.h GEN tests/test-qapi-types.h GEN tests/test-qapi-visit.h GEN tests/test-qmp-commands.h GEN config-all-devices.mak lt CC libqblock/libqblock.lo lt CC stubs/arch-query-cpu-def.lo lt CC libqblock/libqblock-error.lo lt CC stubs/clock-warp.lo lt CC stubs/cpu-get-icount.lo lt CC stubs/cpu-get-clock.lo lt CC stubs/fdset-add-fd.lo lt CC stubs/fdset-find-fd.lo lt CC stubs/fdset-remove-fd.lo lt CC stubs/fdset-get-fd.lo lt CC stubs/get-fd.lo lt CC stubs/get-vm-name.lo lt CC stubs/migr-blocker.lo lt CC stubs/mon-is-qmp.lo lt CC stubs/iothread-lock.lo lt CC stubs/mon-printf.lo lt CC stubs/mon-print-filename.lo lt CC stubs/mon-protocol-event.lo lt CC stubs/mon-set-error.lo lt CC stubs/reset.lo lt CC stubs/slirp.lo lt CC stubs/sysbus.lo lt CC stubs/vm-stop.lo lt CC stubs/vmstate.lo libqblock/libqblock.c: In function 'qb_create': libqblock/libqblock.c:485:39: error: comparison between 'QBlockFormatOptionsSDPreAlloc' and 'enum QBlockFormatOptionsVDIPreAlloc' [-Werror=enum-compare] libqblock/libqblock.c:337:29: error: variable 'o_raw' set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make: *** [libqblock/libqblock.lo] Error 1 make: *** Waiting for unfinished jobs Regards, Anthony Liguori -- Best Regards Wenchao Xia
Re: [Qemu-devel] [PATCH V11 0/4] replace QEMUOptionParameter with QemuOpts parser
于 2013-1-25 23:31, Markus Armbruster 写道: You screwed up your e-mail address: vnet.linux.ibm.com doesn't exist. My review bounced. Please find it on the list. Really sorry for my mistake. I will find them on the list.
Re: [Qemu-devel] [RFC] introduce a general query-config cmd
On Wed, Jan 23, 2013 at 06:41:44PM +0800, Amos Kong wrote:
On Tue, Jan 22, 2013 at 12:26:03PM -0600, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com writes:
On 01/22/2013 08:52 AM, Amos Kong wrote:
Libvirt will need to expose an attribute that lets the user control
whether to use this new option; how do we probe via QMP whether the
new
-boot strict=on command-line option is available?
Hi all,
How about add new info/query command?
(hmp) info strict-boot
on
(qmp) {execute: query-strict-boot}
{return: {state: true}}
It might be not a good solution, I already updated qemu-options.hx,
we can check help message to know if this new option is added or not.
Having libvirt probe the -help output is out of the question. We
already declared that for qemu 1.3 and beyond, ALL command line behavior
must ALSO be probe-able via QMP. I think Anthony had a trick for
testing for existence of various command line options without needing to
add a new query-strict-boot command, but I don't remember what that
trick was.
We need a generic query-config-schema command.
Hi all,
The config info is included in qemu-options.def, current
help() defines QEMU_OPTIONS_GENERATE_HELP, and includes
qemu-options-wrapper.h, DEF macro will output the help
message of options to the stdio.
I tried to add two branches in qemu-options-wrapper.h, which
are used to generate two string arraies (one for option name,
one for help message)
Thy help message is too long, it's failed to output all message to
hmp monitor, always got a segfault, the max limitation maybe reached.
It's more clear to only output help message of one option,
eg: {execute: query-config, arguments : {name: boot}}
{return: {config: -boot [order=drives][,once=drives][,menu=on|off]\n
[,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time][,strict=on|off]\n
'drives': floppy (a), hard disk (c), CD-ROM (d), network (n)\n
'sp_name': the file's name that would be passed to bios as logo picture, if
menu=on\n
'sp_time': the period that splash picture last if menu=on, unit is ms\n
'rb_timeout': the timeout before guest reboot when boot failed, unit is
ms\n}}
But info command of hmp doesn't support parameter
(eg: (hmp) info config boot)
Hi Anthony,
As we talked in IRC, you will send a patch to resolve the query issue.
Can you post patch out when you have time? I will review it.
Thanks, Amos
Q1) Is my patch ok for resolve the issue in last email (libvirt can check
the help message of each option)?
Q2) Can we only added a command for qmp monitor?
Q3) Is it ok to output all help message for hmp (info config)?
Q4) query-config or query-config-schema ?
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 010b8c9..13d1840 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1552,6 +1552,8 @@ show the vnc server status
show the current VM name
@item info uuid
show the current VM UUID
+@item info config
+show config
@item info cpustats
show CPU statistics
@item info usernet
diff --git a/hmp.c b/hmp.c
index 9e9e624..c0d84d1 100644
--- a/hmp.c
+++ b/hmp.c
@@ -98,6 +98,17 @@ void hmp_info_uuid(Monitor *mon)
qapi_free_UuidInfo(info);
}
+void hmp_info_config(Monitor *mon)
+{
+ConfigInfo *info;
+
+/* Fixed ME: hmp info command doesn't support parameter */
+
+info = qmp_query_config(boot, NULL);
+monitor_printf(mon, %s\n, info-config);
+qapi_free_ConfigInfo(info);
+}
+
void hmp_info_chardev(Monitor *mon)
{
ChardevInfoList *char_info, *info;
diff --git a/hmp.h b/hmp.h
index 21f3e05..f217a8c 100644
--- a/hmp.h
+++ b/hmp.h
@@ -23,6 +23,7 @@ void hmp_info_version(Monitor *mon);
void hmp_info_kvm(Monitor *mon);
void hmp_info_status(Monitor *mon);
void hmp_info_uuid(Monitor *mon);
+void hmp_info_config(Monitor *mon);
void hmp_info_chardev(Monitor *mon);
void hmp_info_mice(Monitor *mon);
void hmp_info_migrate(Monitor *mon);
diff --git a/monitor.c b/monitor.c
index 9cf419b..6f331fa 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2661,6 +2661,13 @@ static mon_cmd_t info_cmds[] = {
.help = show the current VM UUID,
.mhandler.info = hmp_info_uuid,
},
+{
+.name = config,
+.args_type = ,
+.params = ,
+.help = show the config,
+.mhandler.info = hmp_info_config,
+},
#if defined(TARGET_PPC)
{
.name = cpustats,
diff --git a/qapi-schema.json b/qapi-schema.json
index 5dfa052..8c46d57 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3017,3 +3017,23 @@
# Since: 1.3.0
##
{ 'command': 'nbd-server-stop' }
+
+##
+# @ConfigInfo:
+#
+# Commandline configration information.
+#
+##
+{ 'type': 'ConfigInfo', 'data': {'config': 'str'} }
+
+##
+# @query-config
+#
+# Query configuration information of one
Re: [Qemu-devel] [PATCH V2 00/20] Multiqueue virtio-net
On 01/25/2013 06:35 PM, Jason Wang wrote: Hello all: This seires is an update of last version of multiqueue virtio-net support. This series tries to brings multiqueue support to virtio-net through a multiqueue support tap backend and multiple vhost threads. To support this, multiqueue nic support were added to qemu. This is done by introducing an array of NetClientStates in NICState, and make each pair of peers to be an queue of the nic. This is done in patch 1-7. Tap were also converted to be able to create a multiple queue backend. Currently, only linux support this by issuing TUNSETIFF N times with the same device name to create N queues. Each fd returned by TUNSETIFF were a queue supported by kernel. Three new command lines were introduced, queues were used to tell how many queues will be created by qemu; fds were used to pass multiple pre-created tap file descriptors to qemu; vhostfds were used to pass multiple pre-created vhost descriptors to qemu. This is done in patch 8-13. A method of deleting a queue and queue_index were also introduce for virtio, this is done in patch 14-15. Vhost were also changed to support multiqueue by introducing a start vq index which tracks the first virtqueue that will be used by vhost instead of the assumption that the vhost always use virtqueue from index 0. This is done in patch 16. The last part is the multiqueue userspace changes, this is done in patch 17-20. With this changes, user could start a multiqueue virtio-net device through ./qemu -netdev tap,id=hn0,queues=2,vhost=on -device virtio-net-pci,netdev=hn0 Management tools such as libvirt can pass multiple pre-created fds/vhostfds through ./qemu -netdev tap,id=hn0,fds=X:Y,vhostfds=M:N -device virtio-net-pci,netdev=hn0 No git tree this round since github is unavailable in China... I saw that github had already been opened again. I can use it. Thanks, Wanlong Gao
Re: [Qemu-devel] [PATCH V2 00/20] Multiqueue virtio-net
On 01/28/2013 11:27 AM, Wanlong Gao wrote: On 01/25/2013 06:35 PM, Jason Wang wrote: Hello all: This seires is an update of last version of multiqueue virtio-net support. This series tries to brings multiqueue support to virtio-net through a multiqueue support tap backend and multiple vhost threads. To support this, multiqueue nic support were added to qemu. This is done by introducing an array of NetClientStates in NICState, and make each pair of peers to be an queue of the nic. This is done in patch 1-7. Tap were also converted to be able to create a multiple queue backend. Currently, only linux support this by issuing TUNSETIFF N times with the same device name to create N queues. Each fd returned by TUNSETIFF were a queue supported by kernel. Three new command lines were introduced, queues were used to tell how many queues will be created by qemu; fds were used to pass multiple pre-created tap file descriptors to qemu; vhostfds were used to pass multiple pre-created vhost descriptors to qemu. This is done in patch 8-13. A method of deleting a queue and queue_index were also introduce for virtio, this is done in patch 14-15. Vhost were also changed to support multiqueue by introducing a start vq index which tracks the first virtqueue that will be used by vhost instead of the assumption that the vhost always use virtqueue from index 0. This is done in patch 16. The last part is the multiqueue userspace changes, this is done in patch 17-20. With this changes, user could start a multiqueue virtio-net device through ./qemu -netdev tap,id=hn0,queues=2,vhost=on -device virtio-net-pci,netdev=hn0 Management tools such as libvirt can pass multiple pre-created fds/vhostfds through ./qemu -netdev tap,id=hn0,fds=X:Y,vhostfds=M:N -device virtio-net-pci,netdev=hn0 No git tree this round since github is unavailable in China... I saw that github had already been opened again. I can use it. Thanks for reminding, I've pushed the new bits to git://github.com/jasowang/qemu.git. Thanks, Wanlong Gao
[Qemu-devel] [PATCH] qga: cast to int for DWORD type
This patch fixes a compiler warning when cross-build: qga/service-win32.c: In function 'printf_win_error': qga/service-win32.c:32:5: warning: format '%d' expects argument of type 'int', but argument 3 has type 'DWORD' [-Wformat] Signed-off-by: Lei Li li...@linux.vnet.ibm.com --- qga/service-win32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/qga/service-win32.c b/qga/service-win32.c index 0905456..843398a 100644 --- a/qga/service-win32.c +++ b/qga/service-win32.c @@ -29,7 +29,7 @@ static int printf_win_error(const char *text) MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (char *)message, 0, NULL); -n = printf(%s. (Error: %d) %s, text, err, message); +n = printf(%s. (Error: %d) %s, text, (int)err, message); LocalFree(message); return n; -- 1.7.7.6
Re: [Qemu-devel] [PATCH V11 1/4] add def_value_str and use it in qemu_opts_print
于 2013-1-25 2:26, Markus Armbruster 写道:
Dong Xu Wang wdon...@vnet.linux.ibm.com writes:
qemu_opts_print has no user now, so can re-write the function safely.
qemu_opts_print will be used while using qemu-img create, it will
produce the same output as previous code.
The behavior of this function has changed:
1. Print every possible option, whether a value has been set or not.
2. Option descriptors may provide a default value.
3. Print to stdout instead of stderr.
Previously the behavior was to print every option that has been set.
Options that have not been set would be skipped.
Signed-off-by: Dong Xu Wang wdon...@vnet.linux.ibm.com
---
v10-v11:
1) print all values that have actually been assigned while accept-any
cases.
v7-v8:
1) print elements = accept any params while opts_accepts_any() ==
true.
2) since def_print_str is the default value if an option isn't set,
so rename it to def_value_str.
include/qemu/option.h | 1 +
util/qemu-option.c| 30 +-
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/include/qemu/option.h b/include/qemu/option.h
index ba197cd..394170a 100644
--- a/include/qemu/option.h
+++ b/include/qemu/option.h
@@ -96,6 +96,7 @@ typedef struct QemuOptDesc {
const char *name;
enum QemuOptType type;
const char *help;
+const char *def_value_str;
} QemuOptDesc;
struct QemuOptsList {
diff --git a/util/qemu-option.c b/util/qemu-option.c
index f532b76..1aed418 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -863,13 +863,33 @@ void qemu_opts_del(QemuOpts *opts)
int qemu_opts_print(QemuOpts *opts, void *dummy)
{
QemuOpt *opt;
+QemuOptDesc *desc = opts-list-desc;
-fprintf(stderr, %s: %s:, opts-list-name,
-opts-id ? opts-id : noid);
-QTAILQ_FOREACH(opt, opts-head, next) {
-fprintf(stderr, %s=\%s\, opt-name, opt-str);
+if (desc[0].name == NULL) {
+QTAILQ_FOREACH(opt, opts-head, next) {
+printf(%s=\%s\ , opt-name, opt-str);
+}
+return 0;
+}
+for (; desc desc-name; desc++) {
+const char *value = desc-def_value_str;
+QemuOpt *opt;
+
+opt = qemu_opt_find(opts, desc-name);
+if (opt) {
+value = opt-str;
+}
+
+if (!value) {
+continue;
+}
+
+if (desc-type == QEMU_OPT_STRING) {
+printf(%s='%s' , desc-name, value);
+} else {
+printf(%s=%s , desc-name, value);
+}
}
-fprintf(stderr, \n);
return 0;
}
I dislike def_value_str intensely, because it's a made up string that
needn't be related to the actual default value. Which is supplied by
the code getting the option.
If I remember correctly, you want qemu_opts_print() print the default
value, because you don't want to change output of qemu-img. Fair
enough.
Two sane ways to do that:
1. Make the caller to supply the default value. Just like the caller
supplies it when getting option values.
Easiest way is to make it set the defaults in the opts whenever it
supplies a default. Like this:
mumble = qemu_opt_get(opts, mumble);
if (!mumble) {
mumble = mutter;
qemu_opt_set(opts, mumble, mumble);
}
Problem: this doesn't set the value in the existing QemuOpt, it
appends a new one, which isn't what we want. We'd need a new
function to change the value.
2. Actually use def_value_str as default value! Replacing
if (value) {
opt-str = g_strdup(value);
}
in opt_set() by
opt-str = g_strdup(value ?: def_value_str);
could do. Looks easier than 1.
Okay, will use 2 in new version patches.
Re: [Qemu-devel] [PATCH v2 19/20] arm: add Faraday FTKBC010 support for A369
Sorry, the description was directly copied from the introduction of its datasheet, it appears to be ambigous in this case. In A369, the FTKBC010 is configured as a keypad controller, not a PS2 keyboard. it acts like some dedicated gpio buttons on the board. In other word: 1. There is no PS2 port on A369. 2. The keypad buttons monitored by FTKBC010 are some hard wired buttons on the board. So it's not appropriate to use existing PS2 keyboard emulation here. Best Wishes Dante Su 2013/1/26 Paul Brook p...@codesourcery.com From: Kuo-Jung Su dant...@faraday-tech.com Faraday keyboard/mouse controller (FTKBC010) is compliant with the IBM PS/2 interface. Your description doesn't appear to match the code at all. Surely if this were true then you should be using the existing PS2 keyboard emulation. Paul -- Best wishes, Kuo-Jung Su
Re: [Qemu-devel] [PATCH v2 20/20] arm: add generic ROM model for Faraday SoC platforms
Thanks for response. The reason why I initialized the QEMU-A36x project a month ago, was to create a embedded ROM code development environment. And there are fews issues at the qemu-1.3.0 which I was working on. 1. The ARM ELF loader failed to correctly handle the image with sparse memory model. For exmaple, A369 ROM code is configured as TEXT/RO-DATA @ 0x (ROM) BSS/RW-DATA/STACK @ 0xA000 (SRAM) And the RW-DATA section is never correctly initialized (all zero) if I use arm_load_kernel(). = RAM emulation(Preloading images into ram) simply doesn't work, I'll check if the issue still exists in the current master branch. 2. I've seen some platform using pflash as ROM emulation, and because some of our customer/colleague love arguing, so I just wanted to try another way more precisely emulate the model. And it now seems not a good idea here, I'll switch into pflash emulation later Best Wishes Dante Su 2013/1/26 Paul Brook p...@codesourcery.com Since the NAND and SPI flash memories do not support random access, so most of the systems which use such memory as main storages usually has some bootstrap code stored inside the embedded ROM of its SoC, and the bootstrap code is responsible for SDRAM initialization and then load the specific software(i.e. u-boot/linux) into SDRAM, and finally jumps into the loaded primary software. No. For a start the block device you're using is for parallel plash devices, which are directly mapped. This contradicts your desciption which talks about serial flash. Please look at how other boards work. There are already mechanisms for creating rom areas, or preloading images into ram. Paul -- Best wishes, Kuo-Jung Su
Re: [Qemu-devel] [PATCH v2 03/20] arm: add Faraday FTAPBBRG020 APB DMA support
2013/1/26 Paul Brook p...@codesourcery.com
The FTAPBBRG020 supports the DMA functions for the AHB-to-AHB,
AHB-to-APB, APB-to-AHB, and APB-to-APB transactions.
All the timer code in this file looks suspect. As a general rule
everything
should be event driven and complete immediately (or at least schedule a BH
for
immediate action if recursion is a concern), not relying on a periodic
timer
interrupts.
Agree,
I've cheated here, because I'm too lazy to checkout how to use mutex/thread
in QEMU,
I'll fix it later.
+qemu_mod_timer(s-qtimer,
+qemu_get_clock_ns(vm_clock) + 1);
For all practical purposes this is going to happen immediately, so you
should
not be using a timer.
+qemu_mod_timer(s-qtimer,
+qemu_get_clock_ns(vm_clock) + (get_ticks_per_sec() 2));
Why 0.25 seconds? Usually this sort of try-again-soon behavior means
you've
missed a trigger event somewhere else.
Yes,
it's because I'm using timer instead of mutext/thread here,
so there might be some race conditions, and thus I added this stupid
work-around here.
+if (!cpu_physical_memory_is_io(c-src)) {
+src_map = src_ptr = cpu_physical_memory_map(c-src, src_len,
0);
+}
+if (!cpu_physical_memory_is_io(c-dst)) {
+dst_map = dst_ptr = cpu_physical_memory_map(c-dst, dst_len,
1);
+}
cpu_physical_memory_map might not map the whole region you requested. This
will cause badness in the subsequent code.
My bad, I forgot this, I'll fix it later.
I suspect a log of this code anc and should be shared with your other DMA
controller, and probably several of the existing DMA controllers.
Paul
--
Best wishes,
Kuo-Jung Su
2013/1/26 Paul Brook p...@codesourcery.com
The FTAPBBRG020 supports the DMA functions for the AHB-to-AHB,
AHB-to-APB, APB-to-AHB, and APB-to-APB transactions.
All the timer code in this file looks suspect. As a general rule
everything
should be event driven and complete immediately (or at least schedule a BH
for
immediate action if recursion is a concern), not relying on a periodic
timer
interrupts.
+qemu_mod_timer(s-qtimer,
+qemu_get_clock_ns(vm_clock) + 1);
For all practical purposes this is going to happen immediately, so you
should
not be using a timer.
+qemu_mod_timer(s-qtimer,
+qemu_get_clock_ns(vm_clock) + (get_ticks_per_sec() 2));
Why 0.25 seconds? Usually this sort of try-again-soon behavior means
you've
missed a trigger event somewhere else.
+if (!cpu_physical_memory_is_io(c-src)) {
+src_map = src_ptr = cpu_physical_memory_map(c-src, src_len,
0);
+}
+if (!cpu_physical_memory_is_io(c-dst)) {
+dst_map = dst_ptr = cpu_physical_memory_map(c-dst, dst_len,
1);
+}
cpu_physical_memory_map might not map the whole region you requested. This
will cause badness in the subsequent code.
I suspect a log of this code anc and should be shared with your other DMA
controller, and probably several of the existing DMA controllers.
Paul
--
Best wishes,
Kuo-Jung Su
Re: [Qemu-devel] [PATCH v2 19/20] arm: add Faraday FTKBC010 support for A369
Am 28.01.2013 07:05, schrieb Kuo-Jung Su: Sorry, the description was directly copied from the introduction of its datasheet, it appears to be ambigous in this case. I thought so for the high quality ethernet adapter. ;) The commit message is supposed to describe the code in technical terms, not advertise represented hardware products with marketing speech please. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v2 05/20] arm: add Faraday FTGMAC100 1Gbps ethernet support
2013/1/26 Paul Brook p...@codesourcery.com
In order to reduce the processing load of the host CPU, the FTGMAC100
implements TCP, UDP, and IP V4 checksum generation and validation, and
supports VLAN tagging.
I see no evidence of these features in the code.
My bad and yes, the VLAN and checksum offload are not yet implemented.
I simply fotget to remove these description ... :P
but since the checksum offload feature of the real hardware actually
malfunctioned.
(becuase of the alignment issue).
I'll only implement the VLAN tagging feature in the next version.
+static void ftgmac100_read_desc(hwaddr addr, void *desc)
+{
+int i;
+uint32_t *p = desc;
+
+cpu_physical_memory_read(addr, desc, 16);
+
+for (i = 0; i 16; i += 4) {
+*p = le32_to_cpu(*p);
+}
+}
You're relying on the compiler choosing a particular bitfield and structure
layout. Don't do that. Especially when one of the fields is a void*.
Clearly
never been tested on a 64-bit host. void *desc is just plain lazy.
yes, it's my bad. It'll be fixed later
+buf = s-txbuff.buf + s-txbuff.len;
+cpu_physical_memory_read(txd.buf, (uint8_t *)buf, txd.len);
Buffer overflow. In at least two differnt ways.
yes, it's my bad. It'll be fixed later
+if (!(s-maccr MACCR_HT_MULTI_EN)) {
+printf([qemu] ftgmac100_receive: mcst filtered\n);
+return -1;
Looks like stray debug code. Several other occurences.
+case REG_TXPD:
+case REG_HPTXPD:
+qemu_mod_timer(s-qtimer, qemu_get_clock_ns(vm_clock) + 1);
Using a timer here is wrong. Either you should transmit immediately, or
you
should wait for something else to happen. Delaying by 1ns is never the
right
answer.
Paul
yes, it's my bad. I'll try to use mutex later
--
Best wishes,
Kuo-Jung Su
Re: [Qemu-devel] [PATCH v2 10/20] arm: add Faraday FTSDC010 MMC/SD controller support
2013/1/26 Paul Brook p...@codesourcery.com
+if (!(s-dcr DCR_WR) (s-datacnt 0)) {
+ret = sd_read_data(s-card)
+| sd_read_data(s-card) 8
+| sd_read_data(s-card) 16
+| sd_read_data(s-card) 24;
+s-datacnt -= 4;
+if (s-datacnt = 0) {
+s-status |= STR_DAT_END;
+}
This will fail if datacnt is not a multiple of 4.
Paul
my bad, datacnt shall not be unsigned.
--
Best wishes,
Kuo-Jung Su
Re: [Qemu-devel] [PATCH v2 19/20] arm: add Faraday FTKBC010 support for A369
2013/1/28 Andreas Färber afaer...@suse.de Am 28.01.2013 07:05, schrieb Kuo-Jung Su: Sorry, the description was directly copied from the introduction of its datasheet, it appears to be ambigous in this case. I thought so for the high quality ethernet adapter. ;) The commit message is supposed to describe the code in technical terms, not advertise represented hardware products with marketing speech please. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg Sorry, that's my bad. It would never happen again. -- Best wishes, Kuo-Jung Su
Re: [Qemu-devel] [PATCH] hw/m25p80.c: add WRSR(0x01) support
2013/1/26 Peter Crosthwaite peter.crosthwa...@xilinx.com
Hi Dante,
On Fri, Jan 25, 2013 at 5:25 PM, Peter Crosthwaite
peter.crosthwa...@xilinx.com wrote:
Hi Dante,
Sorry about the delay, and thanks for the contribution. Please run the
patch through the provided checkpatch script (scripts/checkpatch.pl).
There are a few whitespace errors that need to be fixed. Please also
see the comment below.
Regards,
Peter
On Thu, Jan 17, 2013 at 10:17 PM, Dante dant...@faraday-tech.com
wrote:
Atmel, SST and Intel/Numonyx serial flash tend to power up
with the software protection bits set.
And thus the new m25p80.c in linux kernel would always tries
to use WREN(0x06) + WRSR(0x01) to turn-off the protection.
The WEL(0x02) of status register is supposed to be cleared
after WRSR(0x01).
There are some drivers (i.e my own tiny driver for RTOSes) would
check the WEL(0x02) in status register to make sure the protection
is correctly turned off, so this patch is mandatory to me.
Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
---
hw/m25p80.c | 16
1 file changed, 16 insertions(+)
diff --git a/hw/m25p80.c b/hw/m25p80.c
index d392656..c8d0411 100644
--- a/hw/m25p80.c
+++ b/hw/m25p80.c
@@ -184,6 +184,7 @@ static const FlashPartInfo known_devices[] = {
typedef enum {
NOP = 0,
+WRSR = 0x1,
WRDI = 0x4,
RDSR = 0x5,
WREN = 0x6,
@@ -377,6 +378,12 @@ static void complete_collecting_data(Flash *s)
case ERASE_SECTOR:
flash_erase(s, s-cur_addr, s-cmd_in_progress);
break;
+case WRSR:
+ if (s-write_enable) {
+ s-state = STATE_IDLE;
Returning to the idle state should be unconditional, if
(!s-write_enable), then if you issue a WRSR, you will get stuck in
COLLECTING_DATA.
Reviewing this a little more, transitioning back to IDLE is handled by
the de-assertion of the chip-select. So you should by able to just
remove this s-state = STATE_IDLE altogether.
Regards,
Peter
Thanks for the comment, I'll send out a new patch with correct coding style
later
Best Wishes
Dante
Regards,
Peter
+ s-write_enable = false;
+ }
+ break;
default:
break;
}
@@ -440,6 +447,15 @@ static void decode_new_cmd(Flash *s, uint32_t
value)
s-len = 0;
s-state = STATE_COLLECTING_DATA;
break;
+
+ case WRSR:
+ if (s-write_enable) {
+ s-needed_bytes = 1;
+ s-pos = 0;
+ s-len = 0;
+ s-state = STATE_COLLECTING_DATA;
+ }
+break;
case WRDI:
s-write_enable = false;
--
1.7.9.5
* Confidentiality Notice
This electronic message and any attachments may contain
confidential and legally privileged information or
information which is otherwise protected from disclosure.
If you are not the intended recipient,please do not disclose
the contents, either in whole or in part, to anyone,and
immediately delete the message and any attachments from
your computer system and destroy all hard copies.
Thank you for your cooperation.
***
--
Best wishes,
Kuo-Jung Su
Re: [Qemu-devel] [PATCH v2] target-arm: add Faraday ARMv5TE processors support
2013/1/25 Peter Maydell peter.mayd...@linaro.org On 25 January 2013 07:18, Kuo-Jung Su dant...@gmail.com wrote: From: Kuo-Jung Su dant...@faraday-tech.com Faraday processors are a series of ARMv4/ARMv5TE clone. * ARMv4 series (FA526, FA626). All of them are now out-of-date, so I have no plan for them. * ARMv5TE series (FA606TE, FA626TE, FA616TE, FA726TE) All the single core RISC listed above are included in this patch. And there are two Faraday CP15 extensions (AUX and I/D-Scratchpad) have been implemented as a read/write value without any extra actions. I'm going to need pointers to the CPU documentation to be able to review this patch, though it looks mostly ok. One point: you've added new CPU state fields so you must add save and restore code for them in target-arm/machine.c (and increment CPU_SAVE_VERSION in target-arm/cpu.h.) thanks -- PMM I'm afraid that I don't have enough permission to release full version of the cpu datasheets. However I've prepared some partial version with only CP15 and MCU descriptions at my Google Drive: https://docs.google.com/folder/d/0BwfiewvSmUgAalh5TkxyZWtlWEE/edit And thanks for the comments about target-arm/machine.c and target-arm/cpu.h. I don't even know these things shall be updated until you reminded me. -- Best wishes, Kuo-Jung Su
Re: [Qemu-devel] [PATCH v2 01/20] arm: add Faraday a36x SoC platform support
Am 25.01.2013 10:07, schrieb Andreas Färber: Am 25.01.2013 09:19, schrieb Kuo-Jung Su: hw/a360.c| 271 +++ hw/a369.c| 581 ++ hw/arm/Makefile.objs |6 + hw/faraday.h | 21 ++ 4 files changed, 879 insertions(+) create mode 100644 hw/a360.c create mode 100644 hw/a369.c create mode 100644 hw/faraday.h diff --git a/hw/a360.c b/hw/a360.c new file mode 100644 index 000..cb0a588 --- /dev/null +++ b/hw/a360.c @@ -0,0 +1,271 @@ +/* + * Faraday A360 Evalution Board + * + * Copyright (c) 2012 Faraday Technology + * Written by Dante Su dant...@faraday-tech.com + * + * This code is licensed under GNU GPL v2. Can you please license this and any other files as v2 or (at your option) any later version? Cf. http://wiki.qemu.org/Relicensing Also, there is work underway to move target-specific files to the subdirectories of hw/, i.e. suggest the new ARM machine should go to hw/arm/faraday_a360.c as hw/ is terribly crowded today and a360 is pretty generic. The same applies to the machine names a360 and a369 - I feel they are too ambiguous, given that there is an AllWinner A20 SoC for instance. Can you consider renaming to something less ambiguous like faraday-a360 or so? Andreas For devices it depends on whether they are tightly coupled to the ARM SoC or reusable in any target (x86 etc.). Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [qemu-devel]The problem of QMP command getfd.
Hi all,
I am trying to executing qmp command getfd according to qmp-commands.hx.
{ execute: getfd, arguments: { fdname: fd1 } }
Every time, it returns the error.
{
error: {
class: GenericError,
desc: No file descriptor supplied via SCM_RIGHTS
}
}
This error is related with SCM_RIGHTS.
I don't know about SCM at all.
Can anyone give some hints about this?
Thanks in advance.
--Li
Re: [Qemu-devel] [PATCH v2 02/20] arm: add Faraday FUSBH200 EHCI controller
Am 25.01.2013 10:02, schrieb Gerd Hoffmann:
+static const MemoryRegionOps ehci_mmio_faraday_ops = {
+.read = ehci_faraday_read,
+.write = ehci_faraday_write,
+.valid.min_access_size = 4,
+.valid.max_access_size = 4,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
This should go to hcd-ehci-sysbus.c
+memory_region_init_io(s-mem_faraday, ehci_mmio_faraday_ops, s,
+ faraday, 0x4c);
I don't think this is good design... Can't you do the Faraday part from
your own instance_init / initfn / realizefn function?
Yes, please. Just add your own usb_ehci_sysbus_${board}_initfn, call
usb_ehci_sysbus_initfn for the common stuff, then add your
hardware-specific memory region.
I submitted a patch to facilitate this a little for you:
http://patchwork.ozlabs.org/patch/215919/
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v2 00/20] Add Faraday A36x SoC platform support
Am 25.01.2013 09:19, schrieb Kuo-Jung Su:
From: Kuo-Jung Su dant...@faraday-tech.com
These patches introduce Faraday A36x SoC platform support.
Faraday provides ARMv4/ARMv5TE compatible solutions,
and focus on ASIC design service.
Here are some public documents for you reference.
http://www.faraday-tech.com/html/documentation/index.html
The pre-built images are also available at my Google Drive:
https://docs.google.com/folder/d/0BwfiewvSmUgAX2pTTmtUMGFCZW8/edit
Here is the image file list:
1. android-4.0.4/zImage: A369 linux-3.0.31
2. android-4.0.4/romfs-4.0.4.tar.bz2: android-4.0.4
3. nand.img.bz2: A369 nand flash image
4. rom.img.bz2: A369 embedded ROM image
5. u-boot: A369 u-boot-2012.10 ELF file
6. zImage: A369 linux-3.4.12 + initramfs
7. README
Thank you for posting these test images. Could you also publish your
patches on some public git branch so that one doesn't need to manually
apply 20 or more patches to test it? (e.g., GitHub, repo.or.cz, ...)
Another thing you could look into is qemu-jeos.git support - could you
supply configs for building an upstream Linux kernel for testing? You
can look at arm-vexpress.cfg as template.
Changes for v2:
1. coding style fixes (verified with checkpatch.pl)
2. add Faraday A360 support
3. add Faraday USB 2.0 EHCI support
4. merge a369_scu.c into a369.c
5. introduce QOM coding style
6. remove lowercase Macros: min(), max()
7. name all struct as CamelCase style
8. move function prototypes from .c to faraday.h
9. use switch instead of if statement in a369_ahbc_write
10. remove debug prints
11. update all uarts in A36x to DEVICE_LITTLE_ENDIAN.
12. move the variable definitions to the start of the function,
instead of inside a do { } while(0)
13. remove disabled and commented out code.
14. use hw_error() and exit() upon pflash register failed.
15. add const prior to TypeInfo (i.e. static *const*
TypeInfo ftrtc011_info)
16. add le32_to_cpu/cpu_to_le32 to the descriptor processing in
FTGMAC100/FTMAC110.
17. update the GPL license to GPL v2 (except for FTLCDC200,
it's based on pl110.c which is LGPL.)
18. add const to src_* in the DMA controllers (FTAPBBRG020/FTDMAC020)
Note:
1. Thanks to the comments from KONRAD, Andreas, Paul and Blue.
But if there is still something missed, please kindly remind me to fix.
Thanks!
Your detailed change log is very helpful, thank you. When you post a v3
however, please post the patch series as a top-level patchset (i.e., the
cover letter not as a reply, just the actual patches to the cover
letter), the change log then should be sufficient to understand its
historical context and that makes it a little easier for humans or
Anthony's scripts to find the latest patch versions.
For all your new SysBus devices (i.e., types with .parent =
SYS_BUS_DEVICE) please use a QOM realizefn instead of a qdev initfn -
not just the function naming but dc-realize rather than sdc-init. This
avoids one of us having to go through your code later and doing the
conversion. (I showed you how to do that for EHCI as an example.)
What I'm still missing in v2 is qtest test cases for the RTC and a
libqos driver for your I2C master. If you have questions how to go about
that, feel free to ask on IRC.
2. There are still two coding style errors reported by checkpatch.pl,
but I think they might be false alarms, here is the error log:
ERROR: need consistent spacing around '*' (ctx:WxV)
#74: FILE: hw/a360.c:32:
+i2c_bus *i2c[2];^
ERROR: open brace '{' following function declarations go on the next line
#4680: FILE: hw/ftlcdc200_template.h:59:
+static drawfn glue(ftlcdc200_draw_fn_, BITS)[48] = {
Yes, your analysis looks correct, you can ignore both errors.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH v2 01/20] arm: add Faraday a36x SoC platform support
sure, no problem. 2013/1/28 Andreas Färber afaer...@suse.de Am 25.01.2013 10:07, schrieb Andreas Färber: Am 25.01.2013 09:19, schrieb Kuo-Jung Su: hw/a360.c| 271 +++ hw/a369.c| 581 ++ hw/arm/Makefile.objs |6 + hw/faraday.h | 21 ++ 4 files changed, 879 insertions(+) create mode 100644 hw/a360.c create mode 100644 hw/a369.c create mode 100644 hw/faraday.h diff --git a/hw/a360.c b/hw/a360.c new file mode 100644 index 000..cb0a588 --- /dev/null +++ b/hw/a360.c @@ -0,0 +1,271 @@ +/* + * Faraday A360 Evalution Board + * + * Copyright (c) 2012 Faraday Technology + * Written by Dante Su dant...@faraday-tech.com + * + * This code is licensed under GNU GPL v2. Can you please license this and any other files as v2 or (at your option) any later version? Cf. http://wiki.qemu.org/Relicensing Also, there is work underway to move target-specific files to the subdirectories of hw/, i.e. suggest the new ARM machine should go to hw/arm/faraday_a360.c as hw/ is terribly crowded today and a360 is pretty generic. The same applies to the machine names a360 and a369 - I feel they are too ambiguous, given that there is an AllWinner A20 SoC for instance. Can you consider renaming to something less ambiguous like faraday-a360 or so? Andreas For devices it depends on whether they are tightly coupled to the ARM SoC or reusable in any target (x86 etc.). Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- Best wishes, Kuo-Jung Su
Re: [Qemu-devel] [PATCH v2 02/20] arm: add Faraday FUSBH200 EHCI controller
Thanks, I'm working on it, and the new patch is susposed to be sent out
later.
2013/1/28 Andreas Färber afaer...@suse.de
Am 25.01.2013 10:02, schrieb Gerd Hoffmann:
+static const MemoryRegionOps ehci_mmio_faraday_ops = {
+.read = ehci_faraday_read,
+.write = ehci_faraday_write,
+.valid.min_access_size = 4,
+.valid.max_access_size = 4,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
This should go to hcd-ehci-sysbus.c
+memory_region_init_io(s-mem_faraday, ehci_mmio_faraday_ops, s,
+ faraday, 0x4c);
I don't think this is good design... Can't you do the Faraday part from
your own instance_init / initfn / realizefn function?
Yes, please. Just add your own usb_ehci_sysbus_${board}_initfn, call
usb_ehci_sysbus_initfn for the common stuff, then add your
hardware-specific memory region.
I submitted a patch to facilitate this a little for you:
http://patchwork.ozlabs.org/patch/215919/
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
Best wishes,
Kuo-Jung Su
Re: [Qemu-devel] [PATCH] [qemu-jeos] Update .gitmodules
Am 02.01.2013 16:53, schrieb Stefan Hajnoczi: On Wed, Dec 19, 2012 at 12:54:25AM +0100, Andreas Färber wrote: sources.redhat.com is timing out, use sourceware.org URL instead. Signed-off-by: Andreas Färber afaer...@suse.de --- .gitmodules |2 +- 1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-) Reviewed-by: Stefan Hajnoczi stefa...@redhat.com Ping? No update of qemu-jeos.git yet. Maybe my subject was misleading? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] hd-geo-test failing on OpenIndiana
Andreas Färber andreas.faer...@web.de writes: Hello Markus, On OpenIndiana 151a7 I am seeing assertion failures for ret == 0 in hd-geo-test.c:35:create_test_img(). It seems it is refusing to blow up the temporary file. Any suggestion what to do about that? Fine print on ftruncate(): If fildes refers to a regular file, the ftruncate() function shall cause the size of the file to be truncated to length. If the size of the file previously exceeded length, the extra data shall no longer be available to reads on the file. If the file previously was smaller than this size, ftruncate() shall either increase the size of the file or fail. XSI-conformant systems shall increase the size of the file. If the file size is increased, the extended area shall appear as if it were zero-filled. The value of the seek pointer shall not be modified by a call to ftruncate(). Looks like OpenIndiana got stuck in the 20th century. If you care for such losing systems, you need create_test_img to fall back or switch wholesale to a less elegant way to create the image. Unfortunately, what ftruncate() returns on failure to extend [EFBIG] or [EINVAL] The length argument was greater than the maximum file size. can mean plenty of other things, too: [EINVAL] The length argument was less than 0. [EFBIG] The file is a regular file and length is greater than the offset maximum established in the open file description associated with fildes. [EINVAL] The fildes argument references a file that was opened without write permission. Could mean falling back is not practical. Switching to a full write() of the image is not advised, though, because the large image has 8388608 sectors (4GiB). You really want to create a sparse file.
Re: [Qemu-devel] [PATCH V11 2/4] Create four opts list related functions
于 2013-1-25 2:59, Markus Armbruster 写道:
Dong Xu Wang wdon...@vnet.linux.ibm.com writes:
This patch will create 4 functions, count_opts_list, append_opts_list,
free_opts_list and print_opts_list, they will used in following commits.
Signed-off-by: Dong Xu Wang wdon...@vnet.linux.ibm.com
---
v6-v7):
1) Fix typo.
v5-v6):
1) allocate enough space in append_opts_list function.
include/qemu/option.h | 4 +++
util/qemu-option.c| 90
+++
2 files changed, 94 insertions(+)
diff --git a/include/qemu/option.h b/include/qemu/option.h
index 394170a..f784c2e 100644
--- a/include/qemu/option.h
+++ b/include/qemu/option.h
@@ -156,4 +156,8 @@ int qemu_opts_print(QemuOpts *opts, void *dummy);
int qemu_opts_foreach(QemuOptsList *list, qemu_opts_loopfunc func, void
*opaque,
int abort_on_failure);
+QemuOptsList *append_opts_list(QemuOptsList *dest,
+ QemuOptsList *list);
+void free_opts_list(QemuOptsList *list);
+void print_opts_list(QemuOptsList *list);
Please stick to the existing naming convention: qemu_opts_append(),
qemu_opts_free(), qemu_opts_print().
Okay, will fix.
#endif
diff --git a/util/qemu-option.c b/util/qemu-option.c
index 1aed418..f4bbbf8 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -1152,3 +1152,93 @@ int qemu_opts_foreach(QemuOptsList *list,
qemu_opts_loopfunc func, void *opaque,
loc_pop(loc);
return rc;
}
+
+static size_t count_opts_list(QemuOptsList *list)
+{
+size_t i = 0;
+
+while (list list-desc[i].name) {
+i++;
+}
Please don't invent your own way to interate over list-desc[]! Imitate
the existing code.
for (i = 0; list list-desc[i].name; i++) ;
Same several times below.
Okay, will fix.
+
+return i;
+}
+
+/* Create a new QemuOptsList and make its desc to the merge of first and
second.
+ * It will allocate space for one new QemuOptsList plus enough space for
+ * QemuOptDesc in first and second QemuOptsList. First argument's
QemuOptDesc
+ * members take precedence over second's.
+ */
Unlike most functions dealing with QemuOptsLists, this one can take null
arguments. Worth mentioning.
Okay.
Please wrap your lines a bit earlier. Column 70 is a good limit.
Okay, will use 70 column next version.
+QemuOptsList *append_opts_list(QemuOptsList *first,
+ QemuOptsList *second)
+{
+size_t num_first_options, num_second_options;
+QemuOptsList *dest = NULL;
+int i = 0;
+int index = 0;
+
+num_first_options = count_opts_list(first);
+num_second_options = count_opts_list(second);
+if (num_first_options + num_second_options == 0) {
+return NULL;
+}
Why do you need this extra case? Shouldn't the code below just work?
Yes, without this the code below can work.
+
+dest = g_malloc0(sizeof(QemuOptsList)
++ (num_first_options + num_second_options + 1) *
sizeof(QemuOptDesc));
+
+dest-name = append_opts_list;
+dest-implied_opt_name = NULL;
Not copied from an argument. Tolerable, because all you lose is the
convenience to omit name= in one place, but worth mentioning in the
function comment.
Okay.
+dest-merge_lists = false;
Not copied from an argument. I'm afraid the result will make no sense
if either argument has it set. Consider asserting they don't, and
documenting the requirement in the function comment.
Okay.
+QTAILQ_INIT(dest-head);
+while (first (first-desc[i].name)) {
+if (!find_desc_by_name(dest-desc, first-desc[i].name)) {
+dest-desc[index].name = g_strdup(first-desc[i].name);
+dest-desc[index].help = g_strdup(first-desc[i].help);
+dest-desc[index].type = first-desc[i].type;
+dest-desc[index].def_value_str =
+g_strdup(first-desc[i].def_value_str);
+++index;
index++ please, for consistency with the similar increment two lines
below.
Okay.
+ }
+i++;
Indentation's off.
Yes, will fix.
+}
+i = 0;
+while (second (second-desc[i].name)) {
+if (!find_desc_by_name(dest-desc, second-desc[i].name)) {
+dest-desc[index].name = g_strdup(first-desc[i].name);
+dest-desc[index].help = g_strdup(first-desc[i].help);
+dest-desc[index].type = second-desc[i].type;
+dest-desc[index].def_value_str =
+g_strdup(second-desc[i].def_value_str);
+++index;
+}
+i++;
+}
We've seen this loop before. Please avoid the code duplication, as I
asked you before.
Okay.
+dest-desc[index].name = NULL;
+return dest;
+}
+
+void free_opts_list(QemuOptsList *list)
+{
+int i = 0;
+
+while (list list-desc[i].name) {
+g_free((char *)list-desc[i].name);
+
