Re: [Qemu-devel] [PATCH] Fix some more license versions (GPL2+ instead of GPL2)
At 06/11/2012 01:49 PM, Stefan Weil Wrote: Cc: Wen Congyang we...@cn.fujitsu.com Signed-off-by: Stefan Weil s...@weilnetz.de Signed-off-by: Wen Congyang we...@cn.fujitsu.com --- Wen Congyang, would you please add your Signed-off-by? Thanks for doing this. Wen Congyang Thanks, Stefan W. memory_mapping-stub.c |4 ++-- memory_mapping.c |4 ++-- memory_mapping.h |4 ++-- target-i386/arch_dump.c |4 ++-- target-i386/arch_memory_mapping.c |4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/memory_mapping-stub.c b/memory_mapping-stub.c index 104281d..76be34d 100644 --- a/memory_mapping-stub.c +++ b/memory_mapping-stub.c @@ -6,8 +6,8 @@ * Authors: * Wen Congyang we...@cn.fujitsu.com * - * This work is licensed under the terms of the GNU GPL, version 2. See - * the COPYING file in the top-level directory. + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. * */ diff --git a/memory_mapping.c b/memory_mapping.c index 1125e3f..6f5a2e3 100644 --- a/memory_mapping.c +++ b/memory_mapping.c @@ -6,8 +6,8 @@ * Authors: * Wen Congyang we...@cn.fujitsu.com * - * This work is licensed under the terms of the GNU GPL, version 2. See - * the COPYING file in the top-level directory. + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. * */ diff --git a/memory_mapping.h b/memory_mapping.h index 3f00358..ef72b0a 100644 --- a/memory_mapping.h +++ b/memory_mapping.h @@ -6,8 +6,8 @@ * Authors: * Wen Congyang we...@cn.fujitsu.com * - * This work is licensed under the terms of the GNU GPL, version 2. See - * the COPYING file in the top-level directory. + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. * */ diff --git a/target-i386/arch_dump.c b/target-i386/arch_dump.c index 7c2b514..4240278 100644 --- a/target-i386/arch_dump.c +++ b/target-i386/arch_dump.c @@ -6,8 +6,8 @@ * Authors: * Wen Congyang we...@cn.fujitsu.com * - * This work is licensed under the terms of the GNU GPL, version 2. See - * the COPYING file in the top-level directory. + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. * */ diff --git a/target-i386/arch_memory_mapping.c b/target-i386/arch_memory_mapping.c index efb0211..8e5a56a 100644 --- a/target-i386/arch_memory_mapping.c +++ b/target-i386/arch_memory_mapping.c @@ -6,8 +6,8 @@ * Authors: * Wen Congyang we...@cn.fujitsu.com * - * This work is licensed under the terms of the GNU GPL, version 2. See - * the COPYING file in the top-level directory. + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. * */
[Qemu-devel] [PATCH 0/3] qxl fb size and async fix
Hi Gerd, Some additional patches to go on top of hw/qxl: ignore guest from guestbug until reset. Tree (with previous patchset, without qxl info) available at git://people.freedesktop.org/~alon/qemu to-q/qxl/fb_async_fix.v1 First two add a fb_size_mb property and use that to allow larger framebuffers, second bugs out on too large primary create request, and third resets the current_async to allow recovery from bad state via reset. I'm dropping the qxl info patch for now, lack of time. Alon Alon Levy (3): qxl: add fb_size_mb and fb_size qxl: refuse to create primary larger then fb size qxl: reset current_async on qxl_soft_reset hw/qxl.c | 42 +++--- hw/qxl.h |2 ++ 2 files changed, 33 insertions(+), 11 deletions(-) -- 1.7.10.1
[Qemu-devel] [PATCH 2/3] qxl: refuse to create primary larger then fb size
Signed-off-by: Alon Levy al...@redhat.com
---
hw/qxl.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/qxl.c b/hw/qxl.c
index a9b4fd1..6596856 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1204,6 +1204,16 @@ static void qxl_create_guest_primary(PCIQXLDevice *qxl,
int loadvm,
{
QXLDevSurfaceCreate surface;
QXLSurfaceCreate *sc = qxl-guest_primary.surface;
+int size;
+int requested_height = le32_to_cpu(sc-height);
+int requested_stride = le32_to_cpu(sc-stride);
+
+size = abs(requested_stride) * requested_height;
+if (size qxl-fb_size) {
+qxl_set_guest_bug(qxl, %s: requested primary larger then framebuffer
+size, __func__);
+return;
+}
if (qxl-mode == QXL_MODE_NATIVE) {
qxl_set_guest_bug(qxl, %s: nop since already in QXL_MODE_NATIVE,
--
1.7.10.1
[Qemu-devel] [PATCH 3/3] qxl: reset current_async on qxl_soft_reset
Signed-off-by: Alon Levy al...@redhat.com
---
hw/qxl.c |1 +
1 file changed, 1 insertion(+)
diff --git a/hw/qxl.c b/hw/qxl.c
index 6596856..b18a59d 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -988,6 +988,7 @@ static void qxl_soft_reset(PCIQXLDevice *d)
trace_qxl_soft_reset(d-id);
qxl_check_state(d);
qxl_clear_guest_bug(d);
+d-current_async = QXL_UNDEFINED_IO;
if (d-id == 0) {
qxl_enter_vga_mode(d);
--
1.7.10.1
Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
Il 09/06/2012 05:04, Zhi Yong Wu ha scritto: This commit looks suspicious because it removes a user-visible qdev property but we're trying to preserve backward compatibility. This command-line will break: x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device virtio-net-pci,vlan=1 Instead of dropping the qdev_prop_vlan completely the hw/qdev-properties.c code needs to call net/hub.h external functions to implement equivalent functionality: 1. Setting the vlan=id property looks up the hub port and assigns the NICConf-peer field. 2. Getting the vlan property looks up the hub id (i.e. vlan id) given the peer. If the peer is not a hub port the result is -1. When I wrote this patch I missed the big picture and forgot about backwards compatibility :(. To be honest, i am concerned if anyone uses this syntax. Since the feature will finally be discarded, i suggest that we don't support this now. If someone complains this later, we can fix it. If nobody complains, that is what we hope. I think you're missing the big picture of this series, which is exactly _not_ to discard the VLAN feature, but just to rewrite it in a better way. That said, I agree that this is a somewhat fringe usage; most people will use -net nic,model=virtio,vlan=1 rather than -device. We may get by with dropping it. I have no strong opinion either way. Paolo
[Qemu-devel] [PATCH v4 00/16] QEMU OpenRISC support
This is the OpenCores OpenRISC 1200 support for QEMU. Full implementation of the system-model and linux-user-model support. OpenRISC 1200 is a OpenCores open source CPU, its architecture manual can be found at http://opencores.org/svnget,or1k?file=/trunk/docs/openrisc_arch.pdf A OpenRISC Linux kernel contain initramfs for qemu-system-or32 testing can be found at https://docs.google.com/file/d/0BxeTrz3x0CBLSjR3Sk5Vd3h1eDA/edit?pli=1 A OpenRISC hello-world program for qemu-or32 testing can be found at https://docs.google.com/file/d/0BxeTrz3x0CBLN3RSWUFNYktrU2M/edit?pli=1 Signed-off-by: Jia Liu pro...@gmail.com --- Version History: V4: Addressed Max's review comments: - fix l.div l.mac* l.mul*, and more. Addressed Richard, Wei-Ren and Andreas's review comments: - replace tcg_temp_new_i32 with tcg_temp_local_new_i32 in l.div translation. Addressed Andreas's review comments: - update to suit Makefile system. - add UPR CPUCFGR and MMUCFGR impelement. - add instruction check functions. Version History: V3: Addressed Stefan and Andreas's review comments: - use QEMU and OpenRISC's official name. Addressed Andreas's review comments: - reimplement cpu QOM. - combine target stubs and QOM implement. - use new commit message and subject. Addressed Max's review comments: - handle div zero exception. - reimplement float point instructions. - fix l.mac*, l.mul*, and more. V2: Addressed Malc, Weiren, Andreas and Blue's review comments: - reimplement cpu QOM. Addressed Andreas's review comments: - reimplement machine. - rewrite the Copyright Notice using better format. Addressed Blue and Weiren's review comments: - compiling with AREG0 and remove global env, no dyngen-exe longer. Addressed Max, Blue and Weiren's review comments: - handle div zero exception. - handle illegal instruction. Addressed Blue's review comments: - separate do_interrupt into intrpt.c form intrpt_helper.c. - add QEMU_NORETURN to raise_exception. - reimplement float instrutions. - fix type of linux syscall and termbits. - reimplement sim board. - use the LGPL web URL in Copyright Notice. - reimplemt branch instructions. - split taregt stubs, QOM and machine. V1: - add QEMU OpenRISC support. - well tested on x64 machine, and final tested x86 machine. Jia Liu (16): target-or32: Add target stubs and cpu support target-or32: Add target machine target-or32: Add MMU support target-or32: Add interrupt support target-or32: Add exception support target-or32: Add int instruction helpers target-or32: Add float instruction helpers target-or32: Add translation routines target-or32: Add PIC support target-or32: Add timer support target-or32: Add a IIS dummy board target-or32: Add system instructions target-or32: Add gdb stub support target-or32: Add linux syscall, signal and termbits target-or32: Add linux user support target-or32: Add testcases arch_init.c |2 + arch_init.h |1 + configure | 15 +- cpu-exec.c | 19 + default-configs/or32-linux-user.mak |2 + default-configs/or32-softmmu.mak|6 + elf.h |2 + gdbstub.c | 64 ++ hw/openrisc/Makefile.objs |3 + hw/openrisc_cpudev.h| 29 + hw/openrisc_pic.c | 78 ++ hw/openrisc_sim.c | 145 hw/openrisc_timer.c | 160 linux-user/elfload.c| 41 + linux-user/main.c | 100 +++ linux-user/openrisc/syscall.h | 24 + linux-user/openrisc/syscall_nr.h| 506 +++ linux-user/openrisc/target_signal.h | 26 + linux-user/openrisc/termbits.h | 294 +++ linux-user/signal.c | 229 + linux-user/syscall.c|2 +- linux-user/syscall_defs.h | 40 +- poison.h|1 + target-openrisc/Makefile.objs |4 + target-openrisc/cpu.c | 240 ++ target-openrisc/cpu.h | 445 ++ target-openrisc/excp.c | 27 + target-openrisc/excp.h | 28 + target-openrisc/excp_helper.c | 27 + target-openrisc/fpu_helper.c| 275 ++ target-openrisc/helper.h| 73 ++ target-openrisc/int_helper.c| 155 target-openrisc/intrpt.c| 74 ++ target-openrisc/intrpt_helper.c | 52 ++ target-openrisc/machine.c | 50 ++ target-openrisc/mmu.c | 236 + target-openrisc/mmu_helper.c| 63 ++ target-openrisc/sys_helper.c| 235 + target-openrisc/translate.c | 1616 +++ tests/tcg/openrisc/Makefile | 67 ++ tests/tcg/openrisc/test_add.c | 34 + tests/tcg/openrisc/test_addc.c | 37 + tests/tcg/openrisc/test_addi.c | 31 +
[Qemu-devel] [PATCH v4 01/16] target-or32: Add target stubs and cpu support
Add OpenRISC target stubs and basic cpu support.
Signed-off-by: Jia Liu pro...@gmail.com
---
arch_init.c |2 +
arch_init.h |1 +
configure| 14 +-
cpu-exec.c |2 +
default-configs/or32-softmmu.mak |6 +
elf.h|2 +
hw/openrisc/Makefile.objs|3 +
hw/openrisc_cpudev.h | 29
hw/openrisc_pic.c| 30
hw/openrisc_timer.c | 30
poison.h |1 +
target-openrisc/Makefile.objs|3 +
target-openrisc/cpu.c| 240 +++
target-openrisc/cpu.h| 288 ++
target-openrisc/intrpt.c | 30
target-openrisc/machine.c| 30
target-openrisc/mmu.c| 39 ++
target-openrisc/mmu_helper.c | 43 ++
target-openrisc/translate.c | 75 ++
19 files changed, 866 insertions(+), 2 deletions(-)
create mode 100644 default-configs/or32-softmmu.mak
create mode 100644 hw/openrisc/Makefile.objs
create mode 100644 hw/openrisc_cpudev.h
create mode 100644 hw/openrisc_pic.c
create mode 100644 hw/openrisc_timer.c
create mode 100644 target-openrisc/Makefile.objs
create mode 100644 target-openrisc/cpu.c
create mode 100644 target-openrisc/cpu.h
create mode 100644 target-openrisc/intrpt.c
create mode 100644 target-openrisc/machine.c
create mode 100644 target-openrisc/mmu.c
create mode 100644 target-openrisc/mmu_helper.c
create mode 100644 target-openrisc/translate.c
diff --git a/arch_init.c b/arch_init.c
index a9e8b74..4b521e5 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -71,6 +71,8 @@ int graphic_depth = 15;
#define QEMU_ARCH QEMU_ARCH_MICROBLAZE
#elif defined(TARGET_MIPS)
#define QEMU_ARCH QEMU_ARCH_MIPS
+#elif defined(TARGET_OPENRISC)
+#define QEMU_ARCH QEMU_ARCH_OPENRISC
#elif defined(TARGET_PPC)
#define QEMU_ARCH QEMU_ARCH_PPC
#elif defined(TARGET_S390X)
diff --git a/arch_init.h b/arch_init.h
index c7cb94a..3dfea3b 100644
--- a/arch_init.h
+++ b/arch_init.h
@@ -16,6 +16,7 @@ enum {
QEMU_ARCH_SH4 = 1024,
QEMU_ARCH_SPARC = 2048,
QEMU_ARCH_XTENSA = 4096,
+QEMU_ARCH_OPENRISC = 8192,
};
extern const uint32_t arch_type;
diff --git a/configure b/configure
index dd0d2b3..0f991f5 100755
--- a/configure
+++ b/configure
@@ -925,6 +925,7 @@ mips-softmmu \
mipsel-softmmu \
mips64-softmmu \
mips64el-softmmu \
+or32-softmmu \
ppc-softmmu \
ppcemb-softmmu \
ppc64-softmmu \
@@ -3481,7 +3482,7 @@ target_arch2=`echo $target | cut -d '-' -f 1`
target_bigendian=no
case $target_arch2 in
-
armeb|lm32|m68k|microblaze|mips|mipsn32|mips64|ppc|ppcemb|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
+
armeb|lm32|m68k|microblaze|mips|mipsn32|mips64|or32|ppc|ppcemb|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
target_bigendian=yes
;;
esac
@@ -3597,6 +3598,11 @@ case $target_arch2 in
target_phys_bits=64
target_long_alignment=8
;;
+ or32)
+TARGET_ARCH=openrisc
+TARGET_BASE_ARCH=openrisc
+target_phys_bits=32
+ ;;
ppc)
gdb_xml_files=power-core.xml power-fpu.xml power-altivec.xml
power-spe.xml
target_phys_bits=64
@@ -3675,7 +3681,7 @@ symlink $source_path/Makefile.target
$target_dir/Makefile
case $target_arch2 in
- alpha | sparc* | xtensa*)
+ alpha | or32 | sparc* | xtensa*)
echo CONFIG_TCG_PASS_AREG0=y $config_target_mak
;;
esac
@@ -3846,6 +3852,10 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
echo CONFIG_MIPS_DIS=y $config_target_mak
echo CONFIG_MIPS_DIS=y $libdis_config_mak
;;
+ or32)
+echo CONFIG_OPENRISC_DIS=y $config_target_mak
+echo CONFIG_OPENRISC_DIS=y $libdis_config_mak
+ ;;
ppc*)
echo CONFIG_PPC_DIS=y $config_target_mak
echo CONFIG_PPC_DIS=y $libdis_config_mak
diff --git a/cpu-exec.c b/cpu-exec.c
index 83cac93..17660bb 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -225,6 +225,7 @@ int cpu_exec(CPUArchState *env)
#elif defined(TARGET_LM32)
#elif defined(TARGET_MICROBLAZE)
#elif defined(TARGET_MIPS)
+#elif defined(TARGET_OPENRISC)
#elif defined(TARGET_SH4)
#elif defined(TARGET_CRIS)
#elif defined(TARGET_S390X)
@@ -623,6 +624,7 @@ int cpu_exec(CPUArchState *env)
| env-cc_dest | (env-cc_x 4);
#elif defined(TARGET_MICROBLAZE)
#elif defined(TARGET_MIPS)
+#elif defined(TARGET_OPENRISC)
#elif defined(TARGET_SH4)
#elif defined(TARGET_ALPHA)
#elif defined(TARGET_CRIS)
diff --git a/default-configs/or32-softmmu.mak b/default-configs/or32-softmmu.mak
new file mode 100644
index 000..7590eed
--- /dev/null
+++ b/default-configs/or32-softmmu.mak
@@ -0,0 +1,6 @@
+# Default configuration for or32-softmmu
+
+include pci.mak
+CONFIG_SERIAL=y
+CONFIG_NE2000_ISA=y
+CONFIG_I8259=y
diff --git a/elf.h b/elf.h
index 9c9acfa..a21ea53 100644
--- a/elf.h
+++ b/elf.h
@@ -106,6 +106,8 @@
[Qemu-devel] [PATCH v4 02/16] target-or32: Add target machine
Add OpenRISC target machine.
Signed-off-by: Jia Liu pro...@gmail.com
---
target-openrisc/cpu.h | 67 -
target-openrisc/machine.c | 22 ++-
2 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/target-openrisc/cpu.h b/target-openrisc/cpu.h
index 9f9f4b5..498075a 100644
--- a/target-openrisc/cpu.h
+++ b/target-openrisc/cpu.h
@@ -44,6 +44,15 @@ struct CPUOpenRISCState;
#define TARGET_PHYS_ADDR_SPACE_BITS 32
#define TARGET_VIRT_ADDR_SPACE_BITS 32
+#define SET_FP_CAUSE(reg, v)do {\
+(reg) = ((reg) ~(0x3f 12)) | \
+((v 0x3f) 12);\
+} while (0)
+#define GET_FP_ENABLE(reg) (((reg) 7) 0x1f)
+#define UPDATE_FP_FLAGS(reg, v) do {\
+ (reg) |= ((v 0x1f) 2);\
+ } while (0)
+
/* Internel flags, delay slot flag */
#define D_FLAG1
@@ -117,6 +126,40 @@ enum {
IMMUCFGR_HTR = (1 11),
};
+/* Float piont control status register */
+enum {
+FPCSR_FPEE = 1,
+FPCSR_RM = (3 1),
+FPCSR_OVF = (1 3),
+FPCSR_UNF = (1 4),
+FPCSR_SNF = (1 5),
+FPCSR_QNF = (1 6),
+FPCSR_ZF = (1 7),
+FPCSR_IXF = (1 8),
+FPCSR_IVF = (1 9),
+FPCSR_INF = (1 10),
+FPCSR_DZF = (1 11),
+};
+
+/* Exceptions indices */
+enum {
+EXCP_RESET= 0x1,
+EXCP_BUSERR = 0x2,
+EXCP_DPF = 0x3,
+EXCP_IPF = 0x4,
+EXCP_TICK = 0x5,
+EXCP_ALIGN= 0x6,
+EXCP_ILLEGAL = 0x7,
+EXCP_INT = 0x8,
+EXCP_DTLBMISS = 0x9,
+EXCP_ITLBMISS = 0xa,
+EXCP_RANGE= 0xb,
+EXCP_SYSCALL = 0xc,
+EXCP_FPE = 0xd,
+EXCP_TRAP = 0xe,
+EXCP_NR,
+};
+
/* Supervisor register */
enum {
SR_SM = 1,
@@ -151,6 +194,14 @@ enum {
OPENRISC_FEATURE_OR1200,
};
+/* Tick Timer Mode Register */
+enum {
+TTMR_TP = (0xfff),
+TTMR_IP = (1 28),
+TTMR_IE = (1 29),
+TTMR_M = (3 30),
+};
+
typedef struct CPUOpenRISCState CPUOpenRISCState;
struct CPUOpenRISCState {
target_ulong gpr[32]; /* General registers */
@@ -159,12 +210,25 @@ struct CPUOpenRISCState {
target_ulong ppc; /* Prev PC */
target_ulong jmp_pc; /* Jump PC */
+target_ulong machi; /* Multiply register MACHI */
+target_ulong maclo; /* Multiply register MACLO */
+
+target_ulong fpmaddhi;/* Multiply and add float register FPMADDHI */
+target_ulong fpmaddlo;/* Multiply and add float register FPMADDLO */
+
+target_ulong epcr;/* Exception PC register */
+target_ulong eear;/* Exception EA register */
+
uint32_t sr; /* Supervisor register */
uint32_t vr; /* Version register */
uint32_t upr; /* Unit presence register */
uint32_t cpucfgr; /* CPU configure register */
uint32_t dmmucfgr;/* DMMU configure register */
uint32_t immucfgr;/* IMMU configure register */
+uint32_t esr; /* Exception supervisor register */
+uint32_t fpcsr; /* Float register */
+float_status fp_status;
+
uint32_t flags; /* cpu_flags, we only use it for exception
in solt so far. */
uint32_t btaken; /* the SR_F bit */
@@ -265,7 +329,8 @@ static inline void cpu_get_tb_cpu_state(CPUOpenRISCState
*env,
{
*pc = env-pc;
*cs_base = 0;
-*flags = 0;
+/* D_FLAG -- branch insrtuction exception */
+*flags = (env-flagsD_FLAG);
}
static inline int cpu_mmu_index(CPUOpenRISCState *env)
diff --git a/target-openrisc/machine.c b/target-openrisc/machine.c
index 11bf275..e5d59a7 100644
--- a/target-openrisc/machine.c
+++ b/target-openrisc/machine.c
@@ -20,11 +20,31 @@
#include hw/hw.h
#include hw/boards.h
+static const VMStateDescription vmstate_cpu = {
+.name = cpu,
+.version_id = CPU_SAVE_VERSION,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32_ARRAY(gpr, CPUOpenRISCState, 32),
+VMSTATE_UINT32(sr, CPUOpenRISCState),
+VMSTATE_UINT32(epcr, CPUOpenRISCState),
+VMSTATE_UINT32(eear, CPUOpenRISCState),
+VMSTATE_UINT32(esr, CPUOpenRISCState),
+VMSTATE_UINT32(fpcsr, CPUOpenRISCState),
+VMSTATE_UINT32(pc, CPUOpenRISCState),
+VMSTATE_UINT32(npc, CPUOpenRISCState),
+VMSTATE_UINT32(ppc, CPUOpenRISCState),
+VMSTATE_END_OF_LIST()
+}
+};
+
void cpu_save(QEMUFile *f, void *opaque)
{
+vmstate_save_state(f, vmstate_cpu, opaque);
}
int cpu_load(QEMUFile *f, void *opaque, int version_id)
{
-return 0;
+return vmstate_load_state(f, vmstate_cpu, opaque, version_id);
}
--
1.7.9.5
[Qemu-devel] [PATCH v4 03/16] target-or32: Add MMU support
Add OpenRISC MMU support.
Signed-off-by: Jia Liu pro...@gmail.com
---
target-openrisc/cpu.h| 75 +++-
target-openrisc/mmu.c| 199 +-
target-openrisc/mmu_helper.c | 20 +
3 files changed, 292 insertions(+), 2 deletions(-)
diff --git a/target-openrisc/cpu.h b/target-openrisc/cpu.h
index 498075a..4143dca 100644
--- a/target-openrisc/cpu.h
+++ b/target-openrisc/cpu.h
@@ -39,6 +39,12 @@ struct CPUOpenRISCState;
#define NB_MMU_MODES3
+enum {
+MMU_NOMMU_IDX = 0,
+MMU_SUPERVISOR_IDX = 1,
+MMU_USER_IDX = 2,
+};
+
#define TARGET_PAGE_BITS 13
#define TARGET_PHYS_ADDR_SPACE_BITS 32
@@ -202,6 +208,54 @@ enum {
TTMR_M = (3 30),
};
+/* TLB size */
+enum {
+DTLB_WAYS = 1,
+DTLB_SIZE = 64,
+DTLB_MASK = (DTLB_SIZE-1),
+ITLB_WAYS = 1,
+ITLB_SIZE = 64,
+ITLB_MASK = (ITLB_SIZE-1),
+};
+
+/* TLB prot */
+enum {
+URE = (1 6),
+UWE = (1 7),
+SRE = (1 8),
+SWE = (1 9),
+
+SXE = (1 6),
+UXE = (1 7),
+};
+
+/* check if tlb available */
+enum {
+TLBRET_INVALID = -3,
+TLBRET_NOMATCH = -2,
+TLBRET_BADADDR = -1,
+TLBRET_MATCH = 0
+};
+
+typedef struct OpenRISCTLBEntry {
+uint32_t mr;
+uint32_t tr;
+} OpenRISCTLBEntry;
+
+#if !defined(CONFIG_USER_ONLY)
+typedef struct CPUOpenRISCTLBContext {
+OpenRISCTLBEntry itlb[ITLB_WAYS][ITLB_SIZE];
+OpenRISCTLBEntry dtlb[DTLB_WAYS][DTLB_SIZE];
+
+int (*map_address_code)(struct CPUOpenRISCState *env,
+target_phys_addr_t *physical, int *prot,
+target_ulong address, int rw);
+int (*map_address_data)(struct CPUOpenRISCState *env,
+target_phys_addr_t *physical, int *prot,
+target_ulong address, int rw);
+} CPUOpenRISCTLBContext;
+#endif
+
typedef struct CPUOpenRISCState CPUOpenRISCState;
struct CPUOpenRISCState {
target_ulong gpr[32]; /* General registers */
@@ -236,6 +290,8 @@ struct CPUOpenRISCState {
CPU_COMMON
#if !defined(CONFIG_USER_ONLY)
+CPUOpenRISCTLBContext * tlb;
+
struct QEMUTimer *timer;
uint32_t ttmr; /* Timer tick mode register */
uint32_t ttcr; /* Timer tick count register */
@@ -297,19 +353,33 @@ OpenRISCCPU *cpu_openrisc_init(const char *cpu_model);
int cpu_openrisc_exec(CPUOpenRISCState *s);
void do_interrupt(CPUOpenRISCState *env);
void openrisc_translate_init(void);
+int cpu_openrisc_handle_mmu_fault(CPUOpenRISCState *env, target_ulong address,
+ int rw, int mmu_idx);
#define cpu_list cpu_openrisc_list
#define cpu_exec cpu_openrisc_exec
#define cpu_gen_code cpu_openrisc_gen_code
+#define cpu_handle_mmu_fault cpu_openrisc_handle_mmu_fault
#define CPU_SAVE_VERSION 1
#if !defined(CONFIG_USER_ONLY)
void cpu_openrisc_pic_reset(CPUOpenRISCState *env);
+void cpu_openrisc_store_picsr(CPUOpenRISCState *env, uint32_t value);
+void cpu_openrisc_store_picmr(CPUOpenRISCState *env, uint32_t value);
void cpu_openrisc_timer_reset(CPUOpenRISCState *env);
+void cpu_openrisc_store_count(CPUOpenRISCState *env, target_ulong count);
+void cpu_openrisc_store_compare(CPUOpenRISCState *env, target_ulong value);
+uint32_t cpu_openrisc_get_count(CPUOpenRISCState *env);
void openrisc_mmu_init(CPUOpenRISCState *env);
+int get_phys_nommu(CPUOpenRISCState *env, target_phys_addr_t *physical,
+ int *prot, target_ulong address, int rw);
+int get_phys_code(CPUOpenRISCState *env, target_phys_addr_t *physical,
+ int *prot, target_ulong address, int rw);
+int get_phys_data(CPUOpenRISCState *env, target_phys_addr_t *physical,
+ int *prot, target_ulong address, int rw);
#endif
static inline CPUOpenRISCState *cpu_init(const char *cpu_model)
@@ -335,7 +405,10 @@ static inline void cpu_get_tb_cpu_state(CPUOpenRISCState
*env,
static inline int cpu_mmu_index(CPUOpenRISCState *env)
{
-return 0;
+if (!(env-sr SR_IME)) {
+return MMU_NOMMU_IDX;
+}
+return (env-sr SR_SM) == 0 ? MMU_USER_IDX : MMU_SUPERVISOR_IDX;
}
static inline bool cpu_has_work(CPUOpenRISCState *env)
diff --git a/target-openrisc/mmu.c b/target-openrisc/mmu.c
index 20a1b5a..80af05a 100644
--- a/target-openrisc/mmu.c
+++ b/target-openrisc/mmu.c
@@ -27,13 +27,210 @@
#endif
#if !defined(CONFIG_USER_ONLY)
+int get_phys_nommu(CPUOpenRISCState *env, target_phys_addr_t *physical,
+ int *prot, target_ulong address, int rw)
+{
+*physical = address;
+*prot = PAGE_READ | PAGE_WRITE;
+return TLBRET_MATCH;
+}
+
+int get_phys_code(CPUOpenRISCState *env, target_phys_addr_t *physical,
+ int *prot, target_ulong address, int rw)
+{
+int vpn = address TARGET_PAGE_BITS;
+int idx = vpn ITLB_MASK;
+int right = 0;
+
+if ((env-tlb-itlb[0][idx].mr TARGET_PAGE_BITS) != vpn) {
+return TLBRET_NOMATCH;
+
[Qemu-devel] [PATCH v4 04/16] target-or32: Add interrupt support
Add OpenRISC interrupt support.
Signed-off-by: Jia Liu pro...@gmail.com
---
cpu-exec.c | 17 +
target-openrisc/Makefile.objs |2 +-
target-openrisc/cpu.h |9 ++-
target-openrisc/helper.h| 25 +++
target-openrisc/intrpt.c| 44 +
target-openrisc/intrpt_helper.c | 52 +++
6 files changed, 147 insertions(+), 2 deletions(-)
create mode 100644 target-openrisc/helper.h
create mode 100644 target-openrisc/intrpt_helper.c
diff --git a/cpu-exec.c b/cpu-exec.c
index 17660bb..66af3c3 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -378,6 +378,23 @@ int cpu_exec(CPUArchState *env)
do_interrupt(env);
next_tb = 0;
}
+#elif defined(TARGET_OPENRISC)
+{
+int idx = -1;
+if ((interrupt_request CPU_INTERRUPT_HARD)
+ (env-sr SR_IEE)) {
+idx = EXCP_INT;
+}
+if ((interrupt_request CPU_INTERRUPT_TIMER)
+ (env-sr SR_TEE)) {
+idx = EXCP_TICK;
+}
+if (idx = 0) {
+env-exception_index = idx;
+do_interrupt(env);
+next_tb = 0;
+}
+}
#elif defined(TARGET_SPARC)
if (interrupt_request CPU_INTERRUPT_HARD) {
if (cpu_interrupts_enabled(env)
diff --git a/target-openrisc/Makefile.objs b/target-openrisc/Makefile.objs
index 21b76b2..65f9391 100644
--- a/target-openrisc/Makefile.objs
+++ b/target-openrisc/Makefile.objs
@@ -1,3 +1,3 @@
obj-$(CONFIG_SOFTMMU) += machine.o
obj-y += cpu.o intrpt.o mmu.o translate.o
-obj-y += mmu_helper.o
+obj-y += intrpt_helper.o mmu_helper.o
diff --git a/target-openrisc/cpu.h b/target-openrisc/cpu.h
index 4143dca..337ec1b 100644
--- a/target-openrisc/cpu.h
+++ b/target-openrisc/cpu.h
@@ -62,6 +62,10 @@ enum {
/* Internel flags, delay slot flag */
#define D_FLAG1
+/* Interrupt */
+#define NR_IRQS 32
+#define PIC_MASK 0x
+
/* Verison Register */
#define SPR_VR 0x003F
@@ -300,6 +304,7 @@ struct CPUOpenRISCState {
uint32_t picsr; /* Interrupt contrl register*/
#endif
uint32_t feature; /* CPU Capabilities */
+void *irq[32]; /* Interrupt irq input */
};
#define TYPE_OPENRISC_CPU or32-cpu
@@ -411,9 +416,11 @@ static inline int cpu_mmu_index(CPUOpenRISCState *env)
return (env-sr SR_SM) == 0 ? MMU_USER_IDX : MMU_SUPERVISOR_IDX;
}
+#define CPU_INTERRUPT_TIMER CPU_INTERRUPT_TGT_INT_0
static inline bool cpu_has_work(CPUOpenRISCState *env)
{
-return true;
+return env-interrupt_request (CPU_INTERRUPT_HARD |
+ CPU_INTERRUPT_TIMER);
}
#include exec-all.h
diff --git a/target-openrisc/helper.h b/target-openrisc/helper.h
new file mode 100644
index 000..16d99b6
--- /dev/null
+++ b/target-openrisc/helper.h
@@ -0,0 +1,25 @@
+/*
+ * OpenRISC helper defines
+ *
+ * Copyright (c) 2011-2012 Jia Liu pro...@gmail.com
+ *
+ * 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 def-helper.h
+
+/* interrupt */
+DEF_HELPER_FLAGS_1(rfe, 0, void, env)
+
+#include def-helper.h
diff --git a/target-openrisc/intrpt.c b/target-openrisc/intrpt.c
index 72ee402..85f3d25 100644
--- a/target-openrisc/intrpt.c
+++ b/target-openrisc/intrpt.c
@@ -27,4 +27,48 @@
void do_interrupt(CPUOpenRISCState *env)
{
+#if !defined(CONFIG_USER_ONLY)
+if (env-flags D_FLAG) { /* Delay Slot insn */
+env-flags = ~D_FLAG;
+env-sr |= SR_DSX;
+if (env-exception_index == EXCP_TICK||
+env-exception_index == EXCP_INT ||
+env-exception_index == EXCP_SYSCALL ||
+env-exception_index == EXCP_FPE) {
+env-epcr = env-jmp_pc;
+} else {
+env-epcr = env-pc - 4;
+}
+} else {
+if (env-exception_index == EXCP_TICK||
+env-exception_index == EXCP_INT ||
+env-exception_index == EXCP_SYSCALL ||
+
[Qemu-devel] [PATCH v4 06/16] target-or32: Add int instruction helpers
Add OpenRISC int instruction helpers.
Signed-off-by: Jia Liu pro...@gmail.com
---
target-openrisc/Makefile.objs |2 +-
target-openrisc/helper.h |8 +++
target-openrisc/int_helper.c | 155 +
3 files changed, 164 insertions(+), 1 deletion(-)
create mode 100644 target-openrisc/int_helper.c
diff --git a/target-openrisc/Makefile.objs b/target-openrisc/Makefile.objs
index 382190a..4286462 100644
--- a/target-openrisc/Makefile.objs
+++ b/target-openrisc/Makefile.objs
@@ -1,3 +1,3 @@
obj-$(CONFIG_SOFTMMU) += machine.o
obj-y += cpu.o excp.o intrpt.o mmu.o translate.o
-obj-y += excp_helper.o intrpt_helper.o mmu_helper.o
+obj-y += excp_helper.o int_helper.o intrpt_helper.o mmu_helper.o
diff --git a/target-openrisc/helper.h b/target-openrisc/helper.h
index 4e2a49f..df354a5 100644
--- a/target-openrisc/helper.h
+++ b/target-openrisc/helper.h
@@ -22,6 +22,14 @@
/* exception */
DEF_HELPER_FLAGS_2(exception, 0, void, env, i32)
+/* int */
+DEF_HELPER_FLAGS_1(ff1, 0, tl, tl)
+DEF_HELPER_FLAGS_1(fl1, 0, tl, tl)
+DEF_HELPER_FLAGS_3(add, 0, tl, env, tl, tl)
+DEF_HELPER_FLAGS_3(addc, 0, tl, env, tl, tl)
+DEF_HELPER_FLAGS_3(sub, 0, tl, env, tl, tl)
+DEF_HELPER_FLAGS_3(mul, 0, tl, env, tl, tl)
+
/* interrupt */
DEF_HELPER_FLAGS_1(rfe, 0, void, env)
diff --git a/target-openrisc/int_helper.c b/target-openrisc/int_helper.c
new file mode 100644
index 000..20f8639
--- /dev/null
+++ b/target-openrisc/int_helper.c
@@ -0,0 +1,155 @@
+/*
+ * OpenRISC int helper routines
+ *
+ * Copyright (c) 2011-2012 Jia Liu pro...@gmail.com
+ * Feng Gao gf91...@gmail.com
+ *
+ * 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 cpu.h
+#include helper.h
+#include excp.h
+
+target_ulong HELPER(ff1)(target_ulong x)
+{
+target_ulong n = 0;
+
+if (x == 0) {
+return 0;
+}
+
+for (n = 32; x; n--) {
+x = 1;
+}
+return n+1;
+}
+
+target_ulong HELPER(fl1)(target_ulong x)
+{
+target_ulong n = 0;
+
+if (x == 0) {
+return 0;
+}
+
+for (n = 0; x; n++) {
+x = 1;
+}
+return n;
+}
+
+target_ulong HELPER(add)(CPUOpenRISCState * env, target_ulong a, target_ulong
b)
+{
+target_ulong result;
+result = a + b;
+
+if (result a) {
+env-sr |= SR_CY;
+} else {
+env-sr = ~SR_CY;
+}
+
+if ((a ^ b ^ -1) (a ^ result)) {
+env-sr |= SR_OV;
+if (env-sr SR_OVE) {
+raise_exception(env, EXCP_RANGE);
+}
+} else {
+env-sr = ~SR_OV;
+}
+return result;
+}
+
+target_ulong HELPER(addc)(CPUOpenRISCState * env,
+ target_ulong a, target_ulong b)
+{
+target_ulong result;
+int cf = env-sr SR_CY;
+
+if (!cf) {
+result = a + b;
+cf = result a;
+} else {
+result = a + b + 1;
+cf = result = a;
+}
+
+if (cf) {
+env-sr |= SR_CY;
+} else {
+env-sr = ~SR_CY;
+}
+
+if ((a ^ b ^ -1) (a ^ result)) {
+env-sr |= SR_OV;
+if (env-sr SR_OVE) {
+raise_exception(env, EXCP_RANGE);
+}
+} else {
+env-sr = ~SR_OV;
+}
+return result;
+}
+
+target_ulong HELPER(sub)(CPUOpenRISCState * env, target_ulong a, target_ulong
b)
+{
+target_ulong result;
+result = a - b;
+if (a = b) {
+env-sr |= SR_CY;
+} else {
+env-sr = ~SR_CY;
+}
+
+if ((a ^ b) (a ^ result)) {
+env-sr |= SR_OV;
+if (env-sr SR_OVE) {
+raise_exception(env, EXCP_RANGE);
+}
+} else {
+env-sr = ~SR_OV;
+}
+return result;
+}
+
+target_ulong HELPER(mul)(CPUOpenRISCState * env, target_ulong a, target_ulong
b)
+{
+uint64_t result;
+result = a * b;
+target_ulong high;
+
+high = result TARGET_LONG_BITS;
+
+if (((result (TARGET_LONG_BITS - 1)) 0x1) == 0) {
+if (high == 0) {
+return result;
+}
+}
+
+if (((result (TARGET_LONG_BITS - 1)) 0x1) == 1) {
+if (high == 0x) {
+return result;
+}
+}
+
+env-sr |= SR_OV;
+env-sr |= SR_CY;
+
+if (env-sr SR_OVE) {
+raise_exception(env, EXCP_RANGE);
+}
+
+return result;
+}
--
1.7.9.5
[Qemu-devel] [PATCH 1/3] qxl: add fb_size_mb and fb_size
In preperation for supporting a larger framebuffer for multiple monitors
on a single card, add a property to qxl fb_size_mb, and corresponding
byte sized fb_size, and use instead of VGA_RAM_SIZE.
Signed-off-by: Alon Levy al...@redhat.com
---
hw/qxl.c | 31 ---
hw/qxl.h |2 ++
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index b5e53ce..a9b4fd1 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -114,20 +114,16 @@ static QXLMode qxl_modes[] = {
QXL_MODE_EX(1600, 1200),
QXL_MODE_EX(1680, 1050),
QXL_MODE_EX(1920, 1080),
-#if VGA_RAM_SIZE = (16 * 1024 * 1024)
/* these modes need more than 8 MB video memory */
QXL_MODE_EX(1920, 1200),
QXL_MODE_EX(1920, 1440),
QXL_MODE_EX(2048, 1536),
QXL_MODE_EX(2560, 1440),
QXL_MODE_EX(2560, 1600),
-#endif
-#if VGA_RAM_SIZE = (32 * 1024 * 1024)
/* these modes need more than 16 MB video memory */
QXL_MODE_EX(2560, 2048),
QXL_MODE_EX(2800, 2100),
QXL_MODE_EX(3200, 2400),
-#endif
};
static PCIQXLDevice *qxl0;
@@ -284,6 +280,7 @@ static inline uint32_t msb_mask(uint32_t val)
static ram_addr_t qxl_rom_size(void)
{
uint32_t rom_size = sizeof(QXLRom) + sizeof(QXLModes) + sizeof(qxl_modes);
+
rom_size = MAX(rom_size, TARGET_PAGE_SIZE);
rom_size = msb_mask(rom_size * 2 - 1);
return rom_size;
@@ -296,8 +293,9 @@ static void init_qxl_rom(PCIQXLDevice *d)
uint32_t ram_header_size;
uint32_t surface0_area_size;
uint32_t num_pages;
-uint32_t fb, maxfb = 0;
+uint32_t fb;
int i;
+int n_modes = 0;
memset(rom, 0, d-rom_size);
@@ -312,11 +310,13 @@ static void init_qxl_rom(PCIQXLDevice *d)
rom-slots_end = NUM_MEMSLOTS - 1;
rom-n_surfaces= cpu_to_le32(NUM_SURFACES);
-modes-n_modes = cpu_to_le32(ARRAY_SIZE(qxl_modes));
for (i = 0; i modes-n_modes; i++) {
fb = qxl_modes[i].y_res * qxl_modes[i].stride;
-if (maxfb fb) {
-maxfb = fb;
+if (d-fb_size fb) {
+d-fb_size = fb;
+}
+if (fb = d-fb_size) {
+n_modes++;
}
modes-modes[i].id = cpu_to_le32(i);
modes-modes[i].x_res = cpu_to_le32(qxl_modes[i].x_res);
@@ -327,11 +327,13 @@ static void init_qxl_rom(PCIQXLDevice *d)
modes-modes[i].y_mili = cpu_to_le32(qxl_modes[i].y_mili);
modes-modes[i].orientation = cpu_to_le32(qxl_modes[i].orientation);
}
-if (maxfb VGA_RAM_SIZE d-id == 0)
-maxfb = VGA_RAM_SIZE;
+if (d-fb_size VGA_RAM_SIZE d-id == 0) {
+d-fb_size = VGA_RAM_SIZE;
+}
+modes-n_modes = cpu_to_le32(n_modes);
ram_header_size= ALIGN(sizeof(QXLRam), 4096);
-surface0_area_size = ALIGN(maxfb, 4096);
+surface0_area_size = ALIGN(d-fb_size, 4096);
num_pages = d-vga.vram_size;
num_pages -= ram_header_size;
num_pages -= surface0_area_size;
@@ -1720,6 +1722,12 @@ static void qxl_init_ramsize(PCIQXLDevice *qxl, uint32_t
ram_min_mb)
if (qxl-vga.vram_size ram_min_mb * 1024 * 1024) {
qxl-vga.vram_size = ram_min_mb * 1024 * 1024;
}
+if (qxl-fb_size_mb != -1
+qxl-fb_size_mb * 1024 * 1024 qxl-vga.vram_size) {
+qxl-fb_size = qxl-fb_size_mb * 1024 * 1024;
+} else {
+qxl-fb_size = VGA_RAM_SIZE;
+}
/* vram32 (surfaces, 32bit, bar 1) */
if (qxl-vram32_size_mb != -1) {
@@ -2052,6 +2060,7 @@ static Property qxl_properties[] = {
DEFINE_PROP_UINT32(ram_size_mb, PCIQXLDevice, ram_size_mb, -1),
DEFINE_PROP_UINT32(vram_size_mb, PCIQXLDevice, vram32_size_mb, -1),
DEFINE_PROP_UINT32(vram64_size_mb, PCIQXLDevice, vram_size_mb, -1),
+DEFINE_PROP_UINT32(fb_size_mb, PCIQXLDevice, fb_size_mb, -1),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/qxl.h b/hw/qxl.h
index a4ab7cc..1b4ec16 100644
--- a/hw/qxl.h
+++ b/hw/qxl.h
@@ -84,6 +84,7 @@ typedef struct PCIQXLDevice {
QXLReleaseInfo *last_release;
uint32_t last_release_offset;
uint32_t oom_running;
+uint32_t fb_size;
/* rom pci bar */
QXLRom shadow_rom;
@@ -105,6 +106,7 @@ typedef struct PCIQXLDevice {
uint32_t ram_size_mb;
uint32_t vram_size_mb;
uint32_t vram32_size_mb;
+uint32_t fb_size_mb;
/* qxl_render_update state */
intrender_update_cookie_num;
--
1.7.10.1
[Qemu-devel] [PATCH v4 11/16] target-or32: Add a IIS dummy board
Add a OpenRISC ISS dummy board.
Signed-off-by: Jia Liu pro...@gmail.com
---
hw/openrisc/Makefile.objs |2 +-
hw/openrisc_sim.c | 145 +
2 files changed, 146 insertions(+), 1 deletion(-)
create mode 100644 hw/openrisc_sim.c
diff --git a/hw/openrisc/Makefile.objs b/hw/openrisc/Makefile.objs
index 1c541a5..38ff8f5 100644
--- a/hw/openrisc/Makefile.objs
+++ b/hw/openrisc/Makefile.objs
@@ -1,3 +1,3 @@
-obj-y = openrisc_pic.o openrisc_timer.o
+obj-y = openrisc_pic.o openrisc_sim.o openrisc_timer.o
obj-y := $(addprefix ../,$(obj-y))
diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c
new file mode 100644
index 000..2fe27f5
--- /dev/null
+++ b/hw/openrisc_sim.c
@@ -0,0 +1,145 @@
+/*
+ * OpenRISC simulator for use as an ISS.
+ *
+ * Copyright (c) 2011-2012 Jia Liu pro...@gmail.com
+ * Feng Gao gf91...@gmail.com
+ *
+ * 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.h
+#include openrisc_cpudev.h
+#include boards.h
+#include elf.h
+#include pc.h
+#include loader.h
+#include exec-memory.h
+#include sysemu.h
+#include isa.h
+#include qtest.h
+
+#define KERNEL_LOAD_ADDR 0x100
+
+static struct _loaderparams {
+uint64_t ram_size;
+const char *kernel_filename;
+const char *kernel_cmdline;
+const char *initrd_filename;
+} loaderparams;
+
+static void main_cpu_reset(void *opaque)
+{
+CPUOpenRISCState *env = opaque;
+cpu_reset(ENV_GET_CPU(env));
+}
+
+static uint64_t openrisc_load_kernel(void)
+{
+long kernel_size;
+uint64_t elf_entry;
+target_phys_addr_t entry;
+
+if (loaderparams.kernel_filename !qtest_enabled()) {
+kernel_size = load_elf(loaderparams.kernel_filename, NULL, NULL,
+ elf_entry, NULL, NULL, 1, ELF_MACHINE, 1);
+entry = elf_entry;
+if (kernel_size 0) {
+kernel_size = load_uimage(loaderparams.kernel_filename,
+ entry, NULL, NULL);
+}
+if (kernel_size 0) {
+kernel_size = load_image_targphys(loaderparams.kernel_filename,
+ KERNEL_LOAD_ADDR,
+ ram_size - KERNEL_LOAD_ADDR);
+entry = KERNEL_LOAD_ADDR;
+}
+if (kernel_size 0) {
+fprintf(stderr, qemu: could not load kernel '%s'\n,
+loaderparams.kernel_filename);
+exit(1);
+}
+
+if (kernel_size 0) {
+return elf_entry;
+}
+} else {
+entry = 0;
+}
+
+return entry;
+}
+
+static void openrisc_sim_init(ram_addr_t ram_size,
+ const char *boot_device,
+ const char *kernel_filename,
+ const char *kernel_cmdline,
+ const char *initrd_filename,
+ const char *cpu_model)
+{
+CPUOpenRISCState *env;
+MemoryRegion *ram = g_new(MemoryRegion, 1);
+qemu_irq *i8259;
+ISABus *isa_bus;
+
+if (!cpu_model) {
+cpu_model = or1200;
+}
+env = cpu_init(cpu_model);
+if (!env) {
+fprintf(stderr, Unable to find CPU definition!\n);
+exit(1);
+}
+
+qemu_register_reset(main_cpu_reset, env);
+main_cpu_reset(env);
+
+memory_region_init_ram(ram, openrisc.ram, ram_size);
+memory_region_add_subregion(get_system_memory(), 0, ram);
+
+if (kernel_filename) {
+loaderparams.ram_size = ram_size;
+loaderparams.kernel_filename = kernel_filename;
+loaderparams.kernel_cmdline = kernel_cmdline;
+env-pc = openrisc_load_kernel();
+}
+
+cpu_openrisc_pic_init(env);
+cpu_openrisc_clock_init(env);
+
+isa_bus = isa_bus_new(NULL, get_system_io());
+i8259 = i8259_init(isa_bus, env-irq[3]);
+isa_bus_irqs(isa_bus, i8259);
+
+serial_mm_init(get_system_memory(), 0x9000, 0,
+ env-irq[2], 115200, serial_hds[0], DEVICE_NATIVE_ENDIAN);
+
+if (nd_table[0].vlan) {
+isa_ne2000_init(isa_bus, 0x9200, 4, nd_table[0]);
+}
+}
+
+static QEMUMachine openrisc_sim_machine = {
+.name = or32-sim,
+.desc = or32 simulation,
+.init = openrisc_sim_init,
+.max_cpus = 1,
+.is_default = 1,
+};
+
+static
[Qemu-devel] [PATCH v4 13/16] target-or32: Add gdb stub support
Add OpenRISC gdb stub support.
Signed-off-by: Jia Liu pro...@gmail.com
---
gdbstub.c | 64 +
1 file changed, 64 insertions(+)
diff --git a/gdbstub.c b/gdbstub.c
index 08cf864..5d37dd9 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1155,6 +1155,68 @@ static int cpu_gdb_write_register(CPUMIPSState *env,
uint8_t *mem_buf, int n)
return sizeof(target_ulong);
}
+#elif defined(TARGET_OPENRISC)
+
+#define NUM_CORE_REGS (32 + 3)
+
+static int cpu_gdb_read_register(CPUOpenRISCState *env, uint8_t *mem_buf, int
n)
+{
+if (n 32) {
+GET_REG32(env-gpr[n]);
+} else {
+switch (n) {
+case 32:/* PPC */
+GET_REG32(env-ppc);
+break;
+
+case 33:/* NPC */
+GET_REG32(env-npc);
+break;
+
+case 34:/* SR */
+GET_REG32(env-sr);
+break;
+
+default:
+break;
+}
+}
+return 0;
+}
+
+static int cpu_gdb_write_register(CPUOpenRISCState *env,
+ uint8_t *mem_buf, int n)
+{
+uint32_t tmp;
+
+if (n NUM_CORE_REGS) {
+return 0;
+}
+
+tmp = ldl_p(mem_buf);
+
+if (n 32) {
+env-gpr[n] = tmp;
+} else {
+switch (n) {
+case 32: /* PPC */
+env-ppc = tmp;
+break;
+
+case 33: /* NPC */
+env-npc = tmp;
+break;
+
+case 34: /* SR */
+env-sr = tmp;
+break;
+
+default:
+break;
+}
+}
+return 4;
+}
#elif defined (TARGET_SH4)
/* Hint: Use set architecture sh4 in GDB to see fpu registers */
@@ -1924,6 +1986,8 @@ static void gdb_set_cpu_pc(GDBState *s, target_ulong pc)
}
#elif defined (TARGET_MICROBLAZE)
s-c_cpu-sregs[SR_PC] = pc;
+#elif defined(TARGET_OPENRISC)
+s-c_cpu-pc = pc;
#elif defined (TARGET_CRIS)
s-c_cpu-pc = pc;
#elif defined (TARGET_ALPHA)
--
1.7.9.5
Re: [Qemu-devel] [PATCH v3 7/7] qcow2: always operate caches in writeback mode
Maybe we should add flushes in the right places in higher level functions like bdrv_snapshot_create(). Yes, that would be better. Paolo
[Qemu-devel] [PATCH v4 05/16] target-or32: Add exception support
Add OpenRISC exception support.
Signed-off-by: Jia Liu pro...@gmail.com
---
target-openrisc/Makefile.objs |4 ++--
target-openrisc/excp.c| 27 +++
target-openrisc/excp.h| 28
target-openrisc/excp_helper.c | 27 +++
target-openrisc/helper.h |3 +++
5 files changed, 87 insertions(+), 2 deletions(-)
create mode 100644 target-openrisc/excp.c
create mode 100644 target-openrisc/excp.h
create mode 100644 target-openrisc/excp_helper.c
diff --git a/target-openrisc/Makefile.objs b/target-openrisc/Makefile.objs
index 65f9391..382190a 100644
--- a/target-openrisc/Makefile.objs
+++ b/target-openrisc/Makefile.objs
@@ -1,3 +1,3 @@
obj-$(CONFIG_SOFTMMU) += machine.o
-obj-y += cpu.o intrpt.o mmu.o translate.o
-obj-y += intrpt_helper.o mmu_helper.o
+obj-y += cpu.o excp.o intrpt.o mmu.o translate.o
+obj-y += excp_helper.o intrpt_helper.o mmu_helper.o
diff --git a/target-openrisc/excp.c b/target-openrisc/excp.c
new file mode 100644
index 000..6d8c5dd
--- /dev/null
+++ b/target-openrisc/excp.c
@@ -0,0 +1,27 @@
+/*
+ * OpenRISC exception.
+ *
+ * Copyright (c) 2011-2012 Jia Liu pro...@gmail.com
+ *
+ * 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 cpu.h
+#include excp.h
+
+void QEMU_NORETURN raise_exception(CPUOpenRISCState *env, uint32_t excp)
+{
+env-exception_index = excp;
+cpu_loop_exit(env);
+}
diff --git a/target-openrisc/excp.h b/target-openrisc/excp.h
new file mode 100644
index 000..885203b
--- /dev/null
+++ b/target-openrisc/excp.h
@@ -0,0 +1,28 @@
+/*
+ * OpenRISC exception header.
+ *
+ * Copyright (c) 2011-2012 Jia Liu pro...@gmail.com
+ *
+ * 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/.
+ */
+
+#ifndef QEMU_OPENRISC_EXCP_H
+#define QEMU_OPENRISC_EXCP_H
+
+#include cpu.h
+#include qemu-common.h
+
+void QEMU_NORETURN raise_exception(CPUOpenRISCState *env, uint32_t excp);
+
+#endif /* QEMU_OPENRISC_EXCP_H */
diff --git a/target-openrisc/excp_helper.c b/target-openrisc/excp_helper.c
new file mode 100644
index 000..c7d4110
--- /dev/null
+++ b/target-openrisc/excp_helper.c
@@ -0,0 +1,27 @@
+/*
+ * OpenRISC exception helper routines
+ *
+ * Copyright (c) 2011-2012 Jia Liu pro...@gmail.com
+ *
+ * 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 cpu.h
+#include helper.h
+#include excp.h
+
+void HELPER(exception)(CPUOpenRISCState *env, uint32_t excp)
+{
+raise_exception(env, excp);
+}
diff --git a/target-openrisc/helper.h b/target-openrisc/helper.h
index 16d99b6..4e2a49f 100644
--- a/target-openrisc/helper.h
+++ b/target-openrisc/helper.h
@@ -19,6 +19,9 @@
#include def-helper.h
+/* exception */
+DEF_HELPER_FLAGS_2(exception, 0, void, env, i32)
+
/* interrupt */
DEF_HELPER_FLAGS_1(rfe, 0, void, env)
--
1.7.9.5
[Qemu-devel] [PATCH v4 12/16] target-or32: Add system instructions
Add OpenRISC system instruction helpers and translation.
Signed-off-by: Jia Liu pro...@gmail.com
---
target-openrisc/Makefile.objs |3 +-
target-openrisc/helper.h |4 +
target-openrisc/sys_helper.c | 235 +
target-openrisc/translate.c | 18
4 files changed, 259 insertions(+), 1 deletion(-)
create mode 100644 target-openrisc/sys_helper.c
diff --git a/target-openrisc/Makefile.objs b/target-openrisc/Makefile.objs
index 0d72c33..9d13a5d 100644
--- a/target-openrisc/Makefile.objs
+++ b/target-openrisc/Makefile.objs
@@ -1,3 +1,4 @@
obj-$(CONFIG_SOFTMMU) += machine.o
obj-y += cpu.o excp.o intrpt.o mmu.o translate.o
-obj-y += excp_helper.o fpu_helper.o int_helper.o intrpt_helper.o mmu_helper.o
+obj-y += excp_helper.o fpu_helper.o int_helper.o intrpt_helper.o \
+ mmu_helper.o sys_helper.o
diff --git a/target-openrisc/helper.h b/target-openrisc/helper.h
index b3c1a17..6e95f9f 100644
--- a/target-openrisc/helper.h
+++ b/target-openrisc/helper.h
@@ -66,4 +66,8 @@ DEF_HELPER_FLAGS_3(mul, 0, tl, env, tl, tl)
/* interrupt */
DEF_HELPER_FLAGS_1(rfe, 0, void, env)
+/* sys */
+DEF_HELPER_FLAGS_4(mtspr, 0, void, env, tl, tl, tl)
+DEF_HELPER_FLAGS_4(mfspr, 0, void, env, tl, tl, tl)
+
#include def-helper.h
diff --git a/target-openrisc/sys_helper.c b/target-openrisc/sys_helper.c
new file mode 100644
index 000..89faab1
--- /dev/null
+++ b/target-openrisc/sys_helper.c
@@ -0,0 +1,235 @@
+/*
+ * OpenRISC system instructions helper routines
+ *
+ * Copyright (c) 2011-2012 Jia Liu pro...@gmail.com
+ * Zhizhou Zhang eto...@gmail.com
+ *
+ * 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 cpu.h
+#include helper.h
+
+#define TO_SPR(group, number) (((group)11)+(number))
+void HELPER(mtspr)(CPUOpenRISCState * env,
+ target_ulong ra, target_ulong rb, uint32_t offset)
+{
+#if !defined(CONFIG_USER_ONLY)
+int spr = env-gpr[ra] | offset;
+int idx;
+
+switch (spr) {
+case TO_SPR(0, 0): /* VR */
+env-vr = env-gpr[rb];
+break;
+
+case TO_SPR(0, 16): /* NPC */
+env-npc = env-gpr[rb];
+break;
+
+case TO_SPR(0, 17): /* SR */
+if ((env-sr (SR_IME | SR_DME | SR_SM)) ^
+(env-gpr[rb] (SR_IME | SR_DME | SR_SM))) {
+tlb_flush(env, 1);
+}
+env-sr = env-gpr[rb];
+env-sr |= SR_FO; /* FO is const equal to 1 */
+if (env-sr SR_DME) {
+env-tlb-map_address_data = get_phys_data;
+} else {
+env-tlb-map_address_data = get_phys_nommu;
+}
+
+if (env-sr SR_IME) {
+env-tlb-map_address_code = get_phys_code;
+} else {
+env-tlb-map_address_code = get_phys_nommu;
+}
+break;
+
+case TO_SPR(0, 18): /* PPC */
+env-ppc = env-gpr[rb];
+break;
+
+case TO_SPR(0, 32): /* EPCR */
+env-epcr = env-gpr[rb];
+break;
+
+case TO_SPR(0, 48): /* EEAR */
+env-eear = env-gpr[rb];
+break;
+
+case TO_SPR(0, 64): /* ESR */
+env-esr = env-gpr[rb];
+break;
+case TO_SPR(1, 512) ... TO_SPR(1, 639): /* DTLBW0MR 0-127 */
+idx = spr - TO_SPR(1, 512);
+if (!(env-gpr[rb] 1)) {
+tlb_flush_page(env, env-tlb-dtlb[0][idx].mr TARGET_PAGE_MASK);
+}
+env-tlb-dtlb[0][idx].mr = env-gpr[rb];
+break;
+
+case TO_SPR(1, 640) ... TO_SPR(1, 767): /* DTLBW0TR 0-127 */
+idx = spr - TO_SPR(1, 640);
+env-tlb-dtlb[0][idx].tr = env-gpr[rb];
+break;
+case TO_SPR(1, 768) ... TO_SPR(1, 895): /* DTLBW1MR 0-127 */
+case TO_SPR(1, 896) ... TO_SPR(1, 1023): /* DTLBW1TR 0-127 */
+case TO_SPR(1, 1024) ... TO_SPR(1, 1151): /* DTLBW2MR 0-127 */
+case TO_SPR(1, 1152) ... TO_SPR(1, 1279): /* DTLBW2TR 0-127 */
+case TO_SPR(1, 1280) ... TO_SPR(1, 1407): /* DTLBW3MR 0-127 */
+case TO_SPR(1, 1408) ... TO_SPR(1, 1535): /* DTLBW3TR 0-127 */
+break;
+case TO_SPR(2, 512) ... TO_SPR(2, 639): /* ITLBW0MR 0-127 */
+idx = spr - TO_SPR(2, 512);
+if (!(env-gpr[rb] 1)) {
+tlb_flush_page(env, env-tlb-itlb[0][idx].mr TARGET_PAGE_MASK);
+}
+env-tlb-itlb[0][idx].mr = env-gpr[rb];
+break;
+
+case TO_SPR(2, 640) ...
[Qemu-devel] [PATCH v4 09/16] target-or32: Add PIC support
Add OpenRISC Programmable Interrupt Controller.
Signed-off-by: Jia Liu pro...@gmail.com
---
hw/openrisc_pic.c | 48
1 file changed, 48 insertions(+)
diff --git a/hw/openrisc_pic.c b/hw/openrisc_pic.c
index 0d14bbe..76bd792 100644
--- a/hw/openrisc_pic.c
+++ b/hw/openrisc_pic.c
@@ -28,3 +28,51 @@ void cpu_openrisc_pic_reset(CPUOpenRISCState *env)
env-picmr = 0x;
env-picsr = 0x;
}
+
+/* OpenRISC pic handler */
+static void openrisc_pic_cpu_handler(void *opaque, int irq, int level)
+{
+CPUOpenRISCState *env = (CPUOpenRISCState *)opaque;
+int i;
+uint32_t irq_bit = 1 irq;
+
+if (irq 31 || irq 0) {
+return;
+}
+
+if (level) {
+env-picsr |= irq_bit;
+} else {
+env-picsr = ~irq_bit;
+}
+
+for (i = 0; i 32; i++) {
+if ((env-picsr (1 i)) (env-picmr (1 i))) {
+cpu_interrupt(env, CPU_INTERRUPT_HARD);
+} else {
+cpu_reset_interrupt(env, CPU_INTERRUPT_HARD);
+env-picsr = ~(1 i);
+}
+}
+}
+
+void cpu_openrisc_pic_init(CPUOpenRISCState *env)
+{
+int i;
+qemu_irq *qi;
+qi = qemu_allocate_irqs(openrisc_pic_cpu_handler, env, NR_IRQS);
+
+for (i = 0; i NR_IRQS; i++) {
+env-irq[i] = qi[i];
+}
+}
+
+void cpu_openrisc_store_picmr(CPUOpenRISCState *env, uint32_t value)
+{
+env-picmr |= value;
+}
+
+void cpu_openrisc_store_picsr(CPUOpenRISCState *env, uint32_t value)
+{
+env-picsr = ~value;
+}
--
1.7.9.5
[Qemu-devel] [PATCH v4 16/16] target-or32: Add testcases
Add testcases. Signed-off-by: Jia Liu pro...@gmail.com --- tests/tcg/openrisc/Makefile | 67 + tests/tcg/openrisc/test_add.c| 34 + tests/tcg/openrisc/test_addc.c | 37 ++ tests/tcg/openrisc/test_addi.c | 31 tests/tcg/openrisc/test_addic.c | 32 tests/tcg/openrisc/test_and_or.c | 61 +++ tests/tcg/openrisc/test_bf.c | 46 ++ tests/tcg/openrisc/test_bnf.c| 50 +++ tests/tcg/openrisc/test_div.c| 32 tests/tcg/openrisc/test_extx.c | 72 +++ tests/tcg/openrisc/test_fx.c | 53 tests/tcg/openrisc/test_j.c | 26 ++ tests/tcg/openrisc/test_jal.c| 26 ++ tests/tcg/openrisc/test_lf_add.c | 39 +++ tests/tcg/openrisc/test_lf_div.c | 34 + tests/tcg/openrisc/test_lf_eqs.c | 84 tests/tcg/openrisc/test_lf_ges.c | 84 tests/tcg/openrisc/test_lf_gts.c | 84 tests/tcg/openrisc/test_lf_les.c | 84 tests/tcg/openrisc/test_lf_lts.c | 91 ++ tests/tcg/openrisc/test_lf_mul.c | 22 + tests/tcg/openrisc/test_lf_nes.c | 87 + tests/tcg/openrisc/test_lf_rem.c | 32 tests/tcg/openrisc/test_lf_sub.c | 33 + tests/tcg/openrisc/test_logic.c | 100 ++ tests/tcg/openrisc/test_lx.c | 78 + tests/tcg/openrisc/test_movhi.c | 30 tests/tcg/openrisc/test_mul.c| 47 ++ tests/tcg/openrisc/test_sfeq.c | 44 + tests/tcg/openrisc/test_sfeqi.c | 39 +++ tests/tcg/openrisc/test_sfges.c | 44 + tests/tcg/openrisc/test_sfgesi.c | 40 +++ tests/tcg/openrisc/test_sfgeu.c | 44 + tests/tcg/openrisc/test_sfgeui.c | 41 tests/tcg/openrisc/test_sfgts.c | 45 + tests/tcg/openrisc/test_sfgtsi.c | 41 tests/tcg/openrisc/test_sfgtu.c | 43 tests/tcg/openrisc/test_sfgtui.c | 42 tests/tcg/openrisc/test_sfles.c | 26 ++ tests/tcg/openrisc/test_sflesi.c | 39 +++ tests/tcg/openrisc/test_sfleu.c | 43 tests/tcg/openrisc/test_sfleui.c | 39 +++ tests/tcg/openrisc/test_sflts.c | 43 tests/tcg/openrisc/test_sfltsi.c | 38 +++ tests/tcg/openrisc/test_sfltu.c | 41 tests/tcg/openrisc/test_sfltui.c | 39 +++ tests/tcg/openrisc/test_sfne.c | 43 tests/tcg/openrisc/test_sfnei.c | 38 +++ 48 files changed, 2308 insertions(+) create mode 100644 tests/tcg/openrisc/Makefile create mode 100644 tests/tcg/openrisc/test_add.c create mode 100644 tests/tcg/openrisc/test_addc.c create mode 100644 tests/tcg/openrisc/test_addi.c create mode 100644 tests/tcg/openrisc/test_addic.c create mode 100644 tests/tcg/openrisc/test_and_or.c create mode 100644 tests/tcg/openrisc/test_bf.c create mode 100644 tests/tcg/openrisc/test_bnf.c create mode 100644 tests/tcg/openrisc/test_div.c create mode 100644 tests/tcg/openrisc/test_extx.c create mode 100644 tests/tcg/openrisc/test_fx.c create mode 100644 tests/tcg/openrisc/test_j.c create mode 100644 tests/tcg/openrisc/test_jal.c create mode 100644 tests/tcg/openrisc/test_lf_add.c create mode 100644 tests/tcg/openrisc/test_lf_div.c create mode 100644 tests/tcg/openrisc/test_lf_eqs.c create mode 100644 tests/tcg/openrisc/test_lf_ges.c create mode 100644 tests/tcg/openrisc/test_lf_gts.c create mode 100644 tests/tcg/openrisc/test_lf_les.c create mode 100644 tests/tcg/openrisc/test_lf_lts.c create mode 100644 tests/tcg/openrisc/test_lf_mul.c create mode 100644 tests/tcg/openrisc/test_lf_nes.c create mode 100644 tests/tcg/openrisc/test_lf_rem.c create mode 100644 tests/tcg/openrisc/test_lf_sub.c create mode 100644 tests/tcg/openrisc/test_logic.c create mode 100644 tests/tcg/openrisc/test_lx.c create mode 100644 tests/tcg/openrisc/test_movhi.c create mode 100644 tests/tcg/openrisc/test_mul.c create mode 100644 tests/tcg/openrisc/test_sfeq.c create mode 100644 tests/tcg/openrisc/test_sfeqi.c create mode 100644 tests/tcg/openrisc/test_sfges.c create mode 100644 tests/tcg/openrisc/test_sfgesi.c create mode 100644 tests/tcg/openrisc/test_sfgeu.c create mode 100644 tests/tcg/openrisc/test_sfgeui.c create mode 100644 tests/tcg/openrisc/test_sfgts.c create mode 100644 tests/tcg/openrisc/test_sfgtsi.c create mode 100644 tests/tcg/openrisc/test_sfgtu.c create mode 100644 tests/tcg/openrisc/test_sfgtui.c create mode 100644
Re: [Qemu-devel] [PATCH 00/16] introduce OptsVisitor, rebase -net/-netdev parsing
Il 09/06/2012 17:30, Laszlo Ersek ha scritto:
The net init functions all depend on integer optarg values being
non-negative. Originally this is (or should be...) ensured by
parse_option_number() [qemu-option.c] calling strtoull(), and more
recently by opts_type_int() in this series.
i. If the opts visitor should be able to parse negative integers
(currently not necessary for net/netdev types), then I have to change
opts_type_int() accordingly. To restore the non-negative invariants, I
must either reintroduce = 0 manual checks in the net init funcs
(conflicts with our frugality), or constrain myself to
uint8/uint16/uint32/uint64 field types in the json.
I think this is the best choice. Use uint* types.
+{ 'type': 'NetdevVdeOptions',
+ 'data': {
+'*sock': 'str',
+'*port': 'int',
+'*group': 'str',
+'*mode': 'int' } }
Lucky, both of these can be uint16 so that assignment to int is safe.
+{ 'type': 'NetLegacy',
+ 'data': {
+'*vlan': 'int',
+'name': 'str',
+'opts': 'NetClientOptions' } }
Just a 32-bit token, int32 will be fine.
+{ 'type': 'NetLegacyNicOptions',
+ 'data': {
+'*netdev': 'str',
+'*macaddr': 'str',
+'*model': 'str',
+'*addr':'str',
+'*vectors': 'int' } }
Has to be tested anyway against 0x7ff (only six fs), so uint32 is
good here too.
Paolo
[Qemu-devel] [PATCH v4 15/16] target-or32: Add linux user support
Add QEMU OpenRISC linux user support.
Signed-off-by: Jia Liu pro...@gmail.com
---
configure |1 +
default-configs/or32-linux-user.mak |2 +
linux-user/elfload.c| 41 +++
linux-user/main.c | 100 +++
linux-user/signal.c | 229 +++
linux-user/syscall.c|2 +-
linux-user/syscall_defs.h | 40 +-
target-openrisc/cpu.h | 12 ++
8 files changed, 423 insertions(+), 4 deletions(-)
create mode 100644 default-configs/or32-linux-user.mak
diff --git a/configure b/configure
index 0f991f5..ac8775f 100755
--- a/configure
+++ b/configure
@@ -952,6 +952,7 @@ microblaze-linux-user \
microblazeel-linux-user \
mips-linux-user \
mipsel-linux-user \
+or32-linux-user \
ppc-linux-user \
ppc64-linux-user \
ppc64abi32-linux-user \
diff --git a/default-configs/or32-linux-user.mak
b/default-configs/or32-linux-user.mak
new file mode 100644
index 000..d2fdf22
--- /dev/null
+++ b/default-configs/or32-linux-user.mak
@@ -0,0 +1,2 @@
+# Default configuration for or32-linux-user
+
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index f3b1552..6b622d4 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -787,6 +787,47 @@ static void elf_core_copy_regs(target_elf_gregset_t *regs,
const CPUMBState *env
#endif /* TARGET_MICROBLAZE */
+#ifdef TARGET_OPENRISC
+
+#define ELF_START_MMAP 0x0800
+
+#define elf_check_arch(x) ((x) == EM_OPENRISC)
+
+#define ELF_ARCH EM_OPENRISC
+#define ELF_CLASS ELFCLASS32
+#define ELF_DATA ELFDATA2MSB
+
+static inline void init_thread(struct target_pt_regs *regs,
+ struct image_info *infop)
+{
+regs-pc = infop-entry;
+regs-gpr[1] = infop-start_stack;
+}
+
+#define USE_ELF_CORE_DUMP
+#define ELF_EXEC_PAGESIZE 8192
+
+/* See linux kernel arch/openrisc/include/asm/elf.h. */
+#define ELF_NREG 34 /* gprs and pc, sr */
+typedef target_elf_greg_t target_elf_gregset_t[ELF_NREG];
+
+static void elf_core_copy_regs(target_elf_gregset_t *regs,
+ const CPUOpenRISCState *env)
+{
+int i;
+
+for (i = 0; i 32; i++) {
+(*regs)[i] = tswapl(env-gpr[i]);
+}
+
+(*regs)[32] = tswapl(env-pc);
+(*regs)[33] = tswapl(env-sr);
+}
+#define ELF_HWCAP 0
+#define ELF_PLATFORM NULL
+
+#endif /* TARGET_OPENRISC */
+
#ifdef TARGET_SH4
#define ELF_START_MMAP 0x8000
diff --git a/linux-user/main.c b/linux-user/main.c
index 49108b8..a066479 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2305,6 +2305,93 @@ done_syscall:
}
#endif
+#ifdef TARGET_OPENRISC
+
+void cpu_loop(CPUOpenRISCState *env)
+{
+int trapnr, gdbsig;
+
+for (;;) {
+trapnr = cpu_exec(env);
+gdbsig = 0;
+
+switch (trapnr) {
+case EXCP_RESET:
+fprintf(stderr, \nReset request, exit, pc is %#x\n, env-pc);
+exit(1);
+break;
+case EXCP_BUSERR:
+fprintf(stderr, \nBus error, exit, pc is %#x\n, env-pc);
+gdbsig = SIGBUS;
+break;
+case EXCP_DPF:
+case EXCP_IPF:
+cpu_dump_state(env, stderr, fprintf, 0);
+gdbsig = TARGET_SIGSEGV;
+break;
+case EXCP_TICK:
+fprintf(stderr, \nTick time interrupt pc is %#x\n, env-pc);
+break;
+case EXCP_ALIGN:
+fprintf(stderr, \nAlignment pc is %#x\n, env-pc);
+gdbsig = SIGBUS;
+break;
+case EXCP_ILLEGAL:
+fprintf(stderr, \nIllegal instructionpc is %#x\n, env-pc);
+gdbsig = SIGILL;
+break;
+case EXCP_INT:
+fprintf(stderr, \nExternal interruptpc is %#x\n, env-pc);
+break;
+case EXCP_DTLBMISS:
+case EXCP_ITLBMISS:
+printf(TLB miss\n);
+break;
+case EXCP_RANGE:
+fprintf(stderr, \nRange\n);
+gdbsig = SIGSEGV;
+break;
+case EXCP_SYSCALL:
+env-pc += 4; /* 0xc00; */
+env-gpr[11] = do_syscall(env,
+ env-gpr[11], /* return value */
+ env-gpr[3], /* r3 - r7 are params */
+ env-gpr[4],
+ env-gpr[5],
+ env-gpr[6],
+ env-gpr[7],
+ env-gpr[8], 0, 0);
+break;
+case EXCP_FPE:
+fprintf(stderr, Floating point error\n);
+break;
+case EXCP_TRAP:
+fprintf(stderr, Trap\n);
+gdbsig = SIGTRAP;
+break;
+case EXCP_NR:
+fprintf(stderr, NR\n);
+break;
+default:
+fprintf(stderr, qemu: unhandled CPU exception %#x -
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
Am 05.06.2012 12:00, schrieb Peter Maydell: On 5 June 2012 02:00, Michael Roth mdr...@linux.vnet.ibm.com wrote: +The first step is to move your device struct definition to a header file. This +header file should only contain the struct definition and any preprocessor +declarations you need to define the structure. This header file will act as +the source for the QC IDL compiler. I don't think this is a fantastic idea -- the device struct should be private to the device, and having it in a standalone header file is asking for users of the device to illicitly include it and access internals that they shouldn't. But that is exactly where realize is headed. PCIBus, a9mp_priv etc. structs will need to be made public so that they can be embedded. 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 v4 14/16] target-or32: Add linux syscall, signal and termbits
Add OpenRISC linux syscall, signal and termbits.
Signed-off-by: Jia Liu pro...@gmail.com
---
linux-user/openrisc/syscall.h | 24 ++
linux-user/openrisc/syscall_nr.h| 506 +++
linux-user/openrisc/target_signal.h | 26 ++
linux-user/openrisc/termbits.h | 294
4 files changed, 850 insertions(+)
create mode 100644 linux-user/openrisc/syscall.h
create mode 100644 linux-user/openrisc/syscall_nr.h
create mode 100644 linux-user/openrisc/target_signal.h
create mode 100644 linux-user/openrisc/termbits.h
diff --git a/linux-user/openrisc/syscall.h b/linux-user/openrisc/syscall.h
new file mode 100644
index 000..bdbb577
--- /dev/null
+++ b/linux-user/openrisc/syscall.h
@@ -0,0 +1,24 @@
+struct target_pt_regs {
+union {
+struct {
+/* Named registers */
+uint32_t sr; /* Stored in place of r0 */
+target_ulong sp; /* r1 */
+};
+struct {
+/* Old style */
+target_ulong offset[2];
+target_ulong gprs[30];
+};
+struct {
+/* New style */
+target_ulong gpr[32];
+};
+};
+target_ulong pc;
+target_ulong orig_gpr11; /* For restarting system calls */
+uint32_t syscallno;/* Syscall number (used by strace) */
+target_ulong dummy; /* Cheap alignment fix */
+};
+
+#define UNAME_MACHINE openrisc
diff --git a/linux-user/openrisc/syscall_nr.h b/linux-user/openrisc/syscall_nr.h
new file mode 100644
index 000..f4ac91e
--- /dev/null
+++ b/linux-user/openrisc/syscall_nr.h
@@ -0,0 +1,506 @@
+#define TARGET_NR_io_setup 0
+#define TARGET_NR_io_destroy 1
+#define TARGET_NR_io_submit 2
+#define TARGET_NR_io_cancel 3
+#define TARGET_NR_io_getevents 4
+
+/* fs/xattr.c */
+#define TARGET_NR_setxattr 5
+#define TARGET_NR_lsetxattr 6
+#define TARGET_NR_fsetxattr 7
+#define TARGET_NR_getxattr 8
+#define TARGET_NR_lgetxattr 9
+#define TARGET_NR_fgetxattr 10
+#define TARGET_NR_listxattr 11
+#define TARGET_NR_llistxattr 12
+#define TARGET_NR_flistxattr 13
+#define TARGET_NR_removexattr 14
+#define TARGET_NR_lremovexattr 15
+#define TARGET_NR_fremovexattr 16
+
+/* fs/dcache.c */
+#define TARGET_NR_getcwd 17
+
+/* fs/cookies.c */
+#define TARGET_NR_lookup_dcookie 18
+
+/* fs/eventfd.c */
+#define TARGET_NR_eventfd2 19
+
+/* fs/eventpoll.c */
+#define TARGET_NR_epoll_create1 20
+#define TARGET_NR_epoll_ctl 21
+#define TARGET_NR_epoll_pwait 22
+
+/* fs/fcntl.c */
+#define TARGET_NR_dup 23
+#define TARGET_NR_dup3 24
+#define TARGET_NR_3264_fcntl 25
+
+/* fs/inotify_user.c */
+#define TARGET_NR_inotify_init1 26
+#define TARGET_NR_inotify_add_watch 27
+#define TARGET_NR_inotify_rm_watch 28
+
+/* fs/ioctl.c */
+#define TARGET_NR_ioctl 29
+
+/* fs/ioprio.c */
+#define TARGET_NR_ioprio_set 30
+#define TARGET_NR_ioprio_get 31
+
+/* fs/locks.c */
+#define TARGET_NR_flock 32
+
+/* fs/namei.c */
+#define TARGET_NR_mknodat 33
+#define TARGET_NR_mkdirat 34
+#define TARGET_NR_unlinkat 35
+#define TARGET_NR_symlinkat 36
+#define TARGET_NR_linkat 37
+#define TARGET_NR_renameat 38
+
+/* fs/namespace.c */
+#define TARGET_NR_umount2 39
+#define TARGET_NR_mount 40
+#define TARGET_NR_pivot_root 41
+
+/* fs/nfsctl.c */
+#define TARGET_NR_nfsservctl 42
+
+/* fs/open.c */
+#define TARGET_NR_3264_statfs 43
+#define TARGET_NR_3264_fstatfs 44
+#define TARGET_NR_3264_truncate 45
+#define TARGET_NR_3264_ftruncate 46
+
+#define TARGET_NR_fallocate 47
+#define TARGET_NR_faccessat 48
+#define TARGET_NR_chdir 49
+#define TARGET_NR_fchdir 50
+#define TARGET_NR_chroot 51
+#define TARGET_NR_fchmod 52
+#define TARGET_NR_fchmodat 53
+#define TARGET_NR_fchownat 54
+#define TARGET_NR_fchown 55
+#define TARGET_NR_openat 56
+#define TARGET_NR_close 57
+#define TARGET_NR_vhangup 58
+
+/* fs/pipe.c */
+#define TARGET_NR_pipe2 59
+
+/* fs/quota.c */
+#define TARGET_NR_quotactl 60
+
+/* fs/readdir.c */
+#define TARGET_NR_getdents64 61
+
+/* fs/read_write.c */
+#define TARGET_NR_3264_lseek 62
+#define TARGET_NR_read 63
+#define TARGET_NR_write 64
+#define TARGET_NR_readv 65
+#define TARGET_NR_writev 66
+#define TARGET_NR_pread64 67
+#define TARGET_NR_pwrite64 68
+#define TARGET_NR_preadv 69
+#define TARGET_NR_pwritev 70
+
+/* fs/sendfile.c */
+#define TARGET_NR_3264_sendfile 71
+
+/* fs/select.c */
+#define TARGET_NR_pselect6 72
+#define TARGET_NR_ppoll 73
+
+/* fs/signalfd.c */
+#define TARGET_NR_signalfd4 74
+
+/* fs/splice.c */
+#define TARGET_NR_vmsplice 75
+#define TARGET_NR_splice 76
+#define TARGET_NR_tee 77
+
+/* fs/stat.c */
+#define TARGET_NR_readlinkat 78
+#define TARGET_NR_3264_fstatat 79
+#define TARGET_NR_3264_fstat 80
+
+/* fs/sync.c */
+#define TARGET_NR_sync 81
+#define TARGET_NR_fsync 82
+#define TARGET_NR_fdatasync 83
+
+#ifdef __ARCH_WANT_SYNC_FILE_RANGE2
+#define TARGET_NR_sync_file_range2 84
+#else
+#define TARGET_NR_sync_file_range 84
+#endif
+
+/* fs/timerfd.c */
+#define TARGET_NR_timerfd_create 85
+#define
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
Il 11/06/2012 09:13, Andreas Färber ha scritto: +The first step is to move your device struct definition to a header file. This +header file should only contain the struct definition and any preprocessor +declarations you need to define the structure. This header file will act as +the source for the QC IDL compiler. I don't think this is a fantastic idea -- the device struct should be private to the device, and having it in a standalone header file is asking for users of the device to illicitly include it and access internals that they shouldn't. But that is exactly where realize is headed. PCIBus, a9mp_priv etc. structs will need to be made public so that they can be embedded. I thought that was just a convenience choice, not a necessity. The children objects could just as well be heap-allocated. Paolo
[Qemu-devel] [PATCH v4 07/16] target-or32: Add float instruction helpers
Add OpenRISC float instruction helpers.
Signed-off-by: Jia Liu pro...@gmail.com
---
target-openrisc/Makefile.objs |2 +-
target-openrisc/fpu_helper.c | 275 +
target-openrisc/helper.h | 33 +
3 files changed, 309 insertions(+), 1 deletion(-)
create mode 100644 target-openrisc/fpu_helper.c
diff --git a/target-openrisc/Makefile.objs b/target-openrisc/Makefile.objs
index 4286462..0d72c33 100644
--- a/target-openrisc/Makefile.objs
+++ b/target-openrisc/Makefile.objs
@@ -1,3 +1,3 @@
obj-$(CONFIG_SOFTMMU) += machine.o
obj-y += cpu.o excp.o intrpt.o mmu.o translate.o
-obj-y += excp_helper.o int_helper.o intrpt_helper.o mmu_helper.o
+obj-y += excp_helper.o fpu_helper.o int_helper.o intrpt_helper.o mmu_helper.o
diff --git a/target-openrisc/fpu_helper.c b/target-openrisc/fpu_helper.c
new file mode 100644
index 000..40f5857
--- /dev/null
+++ b/target-openrisc/fpu_helper.c
@@ -0,0 +1,275 @@
+/*
+ * OpenRISC float helper routines
+ *
+ * Copyright (c) 2011-2012 Jia Liu pro...@gmail.com
+ * Feng Gao gf91...@gmail.com
+ *
+ * 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 cpu.h
+#include helper.h
+#include excp.h
+
+static inline uint32_t ieee_ex_to_openrisc(CPUOpenRISCState *env, int fexcp)
+{
+int ret = 0;
+if (fexcp) {
+if (fexcp float_flag_invalid) {
+env-fpcsr |= FPCSR_IVF;
+ret = 1;
+}
+if (fexcp float_flag_overflow) {
+env-fpcsr |= FPCSR_OVF;
+ret = 1;
+}
+if (fexcp float_flag_underflow) {
+env-fpcsr |= FPCSR_UNF;
+ret = 1;
+}
+if (fexcp float_flag_divbyzero) {
+env-fpcsr |= FPCSR_DZF;
+ret = 1;
+}
+if (fexcp float_flag_inexact) {
+env-fpcsr |= FPCSR_IXF;
+ret = 1;
+}
+}
+
+return ret;
+}
+
+static inline void update_fpcsr(CPUOpenRISCState *env)
+{
+int tmp = ieee_ex_to_openrisc(env,
+ get_float_exception_flags(env-fp_status));
+
+SET_FP_CAUSE(env-fpcsr, tmp);
+if ((GET_FP_ENABLE(env-fpcsr) tmp) (env-fpcsr FPCSR_FPEE)) {
+helper_exception(env, EXCP_FPE);
+} else {
+UPDATE_FP_FLAGS(env-fpcsr, tmp);
+}
+}
+
+uint64_t HELPER(itofd)(CPUOpenRISCState *env, uint64_t val)
+{
+uint64_t itofd;
+set_float_exception_flags(0, env-fp_status);
+itofd = int32_to_float64(val, env-fp_status);
+update_fpcsr(env);
+return itofd;
+}
+
+uint32_t HELPER(itofs)(CPUOpenRISCState *env, uint32_t val)
+{
+uint32_t itofs;
+set_float_exception_flags(0, env-fp_status);
+itofs = int32_to_float32(val, env-fp_status);
+update_fpcsr(env);
+return itofs;
+}
+
+uint64_t HELPER(ftoid)(CPUOpenRISCState *env, uint64_t val)
+{
+uint64_t ftoid;
+set_float_exception_flags(0, env-fp_status);
+ftoid = float32_to_int64(val, env-fp_status);
+update_fpcsr(env);
+return ftoid;
+}
+
+uint32_t HELPER(ftois)(CPUOpenRISCState *env, uint32_t val)
+{
+uint32_t ftois;
+set_float_exception_flags(0, env-fp_status);
+ftois = float32_to_int32(val, env-fp_status);
+update_fpcsr(env);
+return ftois;
+}
+
+#define FLOAT_OP(name, p) void helper_float_##_##p(void)
+
+#define FLOAT_CALC(name) \
+uint64_t helper_float_ ## name ## _d(CPUOpenRISCState *env, \
+ uint64_t fdt0, uint64_t fdt1)\
+{ \
+uint64_t result; \
+set_float_exception_flags(0, env-fp_status);\
+result = float64_ ## name(fdt0, fdt1, env-fp_status); \
+update_fpcsr(env);\
+return result;\
+} \
+ \
+uint32_t helper_float_ ## name ## _s(CPUOpenRISCState *env, \
+ uint32_t fdt0, uint32_t fdt1)\
+{
[Qemu-devel] [PATCH v4 08/16] target-or32: Add translation routines
Add OpenRISC translation routines.
Signed-off-by: Jia Liu pro...@gmail.com
---
target-openrisc/translate.c | 1523 +++
1 file changed, 1523 insertions(+)
diff --git a/target-openrisc/translate.c b/target-openrisc/translate.c
index 1d87d76..ec004be 100644
--- a/target-openrisc/translate.c
+++ b/target-openrisc/translate.c
@@ -26,6 +26,10 @@
#include qemu-log.h
#include config.h
+#include helper.h
+#define GEN_HELPER 1
+#include helper.h
+
#define OPENRISC_DISAS
#ifdef OPENRISC_DISAS
@@ -34,14 +38,1533 @@
# define LOG_DIS(...) do { } while (0)
#endif
+typedef struct DisasContext {
+CPUOpenRISCState *env;
+TranslationBlock *tb;
+target_ulong pc, ppc, npc;
+uint32_t tb_flags, synced_flags, flags;
+uint32_t is_jmp;
+uint32_t mem_idx;
+int singlestep_enabled;
+uint32_t delayed_branch;
+} DisasContext;
+
+static TCGv_ptr cpu_env;
+static TCGv cpu_sr;
+static TCGv cpu_R[32];
+static TCGv cpu_pc;
+static TCGv jmp_pc;/* l.jr/l.jalr temp pc */
+static TCGv cpu_npc;
+static TCGv cpu_ppc;
+static TCGv_i32 env_btaken;/* bf/bnf , F flag taken */
+static TCGv_i32 fpcsr;
+static TCGv machi, maclo;
+static TCGv fpmaddhi, fpmaddlo;
+static TCGv_i32 env_flags;
+#include gen-icount.h
+
void openrisc_translate_init(void)
{
+static const char * const regnames[] = {
+r0, r1, r2, r3, r4, r5, r6, r7,
+r8, r9, r10, r11, r12, r13, r14, r15,
+r16, r17, r18, r19, r20, r21, r22, r23,
+r24, r25, r26, r27, r28, r29, r30, r31,
+};
+int i;
+
+cpu_env = tcg_global_reg_new_ptr(TCG_AREG0, env);
+cpu_sr = tcg_global_mem_new(TCG_AREG0,
+offsetof(CPUOpenRISCState, sr), sr);
+env_flags = tcg_global_mem_new_i32(TCG_AREG0,
+ offsetof(CPUOpenRISCState, flags),
+ flags);
+cpu_pc = tcg_global_mem_new(TCG_AREG0,
+offsetof(CPUOpenRISCState, pc), pc);
+cpu_npc = tcg_global_mem_new(TCG_AREG0,
+ offsetof(CPUOpenRISCState, npc), npc);
+cpu_ppc = tcg_global_mem_new(TCG_AREG0,
+ offsetof(CPUOpenRISCState, ppc), ppc);
+jmp_pc = tcg_global_mem_new(TCG_AREG0,
+offsetof(CPUOpenRISCState, jmp_pc), jmp_pc);
+env_btaken = tcg_global_mem_new_i32(TCG_AREG0,
+offsetof(CPUOpenRISCState, btaken),
+btaken);
+fpcsr = tcg_global_mem_new_i32(TCG_AREG0,
+ offsetof(CPUOpenRISCState, fpcsr),
+ fpcsr);
+machi = tcg_global_mem_new(TCG_AREG0,
+ offsetof(CPUOpenRISCState, machi),
+ machi);
+maclo = tcg_global_mem_new(TCG_AREG0,
+ offsetof(CPUOpenRISCState, maclo),
+ maclo);
+fpmaddhi = tcg_global_mem_new(TCG_AREG0,
+ offsetof(CPUOpenRISCState, fpmaddhi),
+ fpmaddhi);
+fpmaddlo = tcg_global_mem_new(TCG_AREG0,
+ offsetof(CPUOpenRISCState, fpmaddlo),
+ fpmaddlo);
+for (i = 0; i 32; i++) {
+cpu_R[i] = tcg_global_mem_new(TCG_AREG0,
+ offsetof(CPUOpenRISCState, gpr[i]),
+ regnames[i]);
+}
+#define GEN_HELPER 2
+#include helper.h
+}
+
+/* Writeback SR_F transaltion-space to execution-space. */
+static inline void wb_SR_F(void)
+{
+int label;
+
+label = gen_new_label();
+tcg_gen_andi_tl(cpu_sr, cpu_sr, ~SR_F);
+tcg_gen_brcondi_tl(TCG_COND_EQ, env_btaken, 0, label);
+tcg_gen_ori_tl(cpu_sr, cpu_sr, SR_F);
+gen_set_label(label);
+}
+
+static inline int zero_extend(unsigned int val, int width)
+{
+return val ((1 width) - 1);
+}
+
+static inline int sign_extend(unsigned int val, int width)
+{
+int sval;
+
+/* LSL */
+val = TARGET_LONG_BITS - width;
+sval = val;
+/* ASR. */
+sval = TARGET_LONG_BITS - width;
+return sval;
+}
+
+static inline void gen_sync_flags(DisasContext *dc)
+{
+/* Sync the tb dependent flag between translate and runtime. */
+if (dc-tb_flags != dc-synced_flags) {
+tcg_gen_movi_tl(env_flags, dc-tb_flags);
+dc-synced_flags = dc-tb_flags;
+}
+}
+
+static void gen_exception(DisasContext *dc, unsigned int excp)
+{
+TCGv_i32 tmp = tcg_const_i32(excp);
+gen_helper_exception(cpu_env, tmp);
+tcg_temp_free(tmp);
+}
+
+static void gen_illegal_exception(DisasContext *dc)
+{
+tcg_gen_movi_tl(cpu_pc, dc-pc);
+gen_exception(dc, EXCP_ILLEGAL);
+dc-is_jmp = DISAS_UPDATE;
+}
+
+static void check_ob64s(DisasContext *dc)
+{
+if (!(dc-flags CPUCFGR_OB64S)) {
+
[Qemu-devel] [PATCH v4 10/16] target-or32: Add timer support
Add OpenRISC timer support.
Signed-off-by: Jia Liu pro...@gmail.com
---
hw/openrisc_timer.c | 130 +++
1 file changed, 130 insertions(+)
diff --git a/hw/openrisc_timer.c b/hw/openrisc_timer.c
index df384f6..25cde1a 100644
--- a/hw/openrisc_timer.c
+++ b/hw/openrisc_timer.c
@@ -22,9 +22,139 @@
#include openrisc_cpudev.h
#include qemu-timer.h
+#define TIMER_FREQ(20 * 1000 * 1000)/* 20MHz */
+
+/* The time when TTCR changes */
+static uint64_t last_clk;
+static int is_counting;
+
+/* Timer Mode */
+enum {
+TIMER_NONE = (0 30),
+TIMER_INTR = (1 30),
+TIMER_SHOT = (2 30),
+TIMER_CONT = (3 30),
+};
+
/* Reset Timer */
void cpu_openrisc_timer_reset(CPUOpenRISCState *env)
{
env-ttmr = 0x;
env-ttcr = 0x;
}
+
+static void count_update(CPUOpenRISCState *env)
+{
+uint64_t now, next;
+uint32_t wait;
+
+now = qemu_get_clock_ns(vm_clock);
+if (!is_counting) {
+qemu_del_timer(env-timer);
+last_clk = now;
+return;
+}
+
+env-ttcr += (uint32_t)muldiv64(now - last_clk, TIMER_FREQ,
+get_ticks_per_sec());
+last_clk = now;
+
+if ((env-ttmr TTMR_TP) = (env-ttcr TTMR_TP)) {
+wait = TTMR_TP - (env-ttcr TTMR_TP) + 1;
+wait += env-ttmr TTMR_TP;
+} else {
+wait = (env-ttmr TTMR_TP) - (env-ttcr TTMR_TP);
+}
+
+next = now + muldiv64(wait, get_ticks_per_sec(), TIMER_FREQ);
+qemu_mod_timer(env-timer, next);
+}
+
+static void count_start(CPUOpenRISCState *env)
+{
+is_counting = 1;
+count_update(env);
+}
+
+static void count_stop(CPUOpenRISCState *env)
+{
+is_counting = 0;
+count_update(env);
+}
+
+uint32_t cpu_openrisc_get_count(CPUOpenRISCState *env)
+{
+count_update(env);
+return env-ttcr;
+}
+
+void cpu_openrisc_store_count(CPUOpenRISCState *env, uint32_t count)
+{
+/* Store new count register */
+env-ttcr = count;
+if (env-ttmr TIMER_NONE) {
+return;
+}
+count_start(env);
+}
+
+void cpu_openrisc_store_compare(CPUOpenRISCState *env, uint32_t value)
+{
+int ip = env-ttmr TTMR_IP;
+
+if (value TTMR_IP) { /* Keep IP bit */
+env-ttmr = (value ~TTMR_IP) + ip;
+} else { /* Clear IP bit */
+env-ttmr = value ~TTMR_IP;
+env-interrupt_request = ~CPU_INTERRUPT_TIMER;
+}
+count_update(env);
+
+switch (env-ttmr TTMR_M) {
+case TIMER_NONE:
+count_stop(env);
+break;
+case TIMER_INTR:
+count_start(env);
+break;
+case TIMER_SHOT:
+count_start(env);
+break;
+case TIMER_CONT:
+count_start(env);
+break;
+}
+}
+
+static void openrisc_timer_cb(void *opaque)
+{
+CPUOpenRISCState *env = opaque;
+
+if ((env-ttmr TTMR_IE)
+ qemu_timer_expired(env-timer, qemu_get_clock_ns(vm_clock))) {
+env-ttmr |= TTMR_IP;
+env-interrupt_request |= CPU_INTERRUPT_TIMER;
+}
+
+switch (env-ttmr TTMR_M) {
+case TIMER_NONE:
+break;
+case TIMER_INTR:
+env-ttcr = 0;
+count_start(env);
+break;
+case TIMER_SHOT:
+count_stop(env);
+break;
+case TIMER_CONT:
+count_start(env);
+break;
+}
+}
+
+void cpu_openrisc_clock_init(CPUOpenRISCState *env)
+{
+env-timer = qemu_new_timer_ns(vm_clock, openrisc_timer_cb, env);
+env-ttmr = 0;
+env-ttcr = 0;
+}
--
1.7.9.5
Re: [Qemu-devel] [PATCH 1/3] qxl: add fb_size_mb and fb_size
Hi,
+if (d-fb_size fb) {
+d-fb_size = fb;
+}
+if (fb = d-fb_size) {
This check doesn't make sense, it will always be true.
+if (qxl-fb_size_mb != -1
+qxl-fb_size_mb * 1024 * 1024 qxl-vga.vram_size) {
+qxl-fb_size = qxl-fb_size_mb * 1024 * 1024;
+} else {
+qxl-fb_size = VGA_RAM_SIZE;
+}
Reminds me that I have some pending work to make vga ram size
configurable which I should finish and repost ...
Current state pushed to http://www.kraxel.org/cgit/qemu/log/?h=vga.1
It probably makes sense to base this on top.
+DEFINE_PROP_UINT32(fb_size_mb, PCIQXLDevice, fb_size_mb, -1),
Maybe also rename this to vgamem_mb for consistency with standard vga.
cheers,
Gerd
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
Am 11.06.2012 09:20, schrieb Paolo Bonzini: Il 11/06/2012 09:13, Andreas Färber ha scritto: +The first step is to move your device struct definition to a header file. This +header file should only contain the struct definition and any preprocessor +declarations you need to define the structure. This header file will act as +the source for the QC IDL compiler. I don't think this is a fantastic idea -- the device struct should be private to the device, and having it in a standalone header file is asking for users of the device to illicitly include it and access internals that they shouldn't. But that is exactly where realize is headed. PCIBus, a9mp_priv etc. structs will need to be made public so that they can be embedded. I thought that was just a convenience choice, not a necessity. The children objects could just as well be heap-allocated. In that case we'd need to change the instance_init signature. As far as I've understood from our discussions with Anthony, realize must not allocate new objects because that may collide with the recursive realize model, and instance_init is not supposed to fail. Thus the in-place init demonstrated for i440fx and now adopted for prep_pci and my tegra2. Saying the device struct should be private to the device leaves virtually no choice, whether for convenience or necessity, and requires also suggesting a design solution for QOM initialization. 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] CoW image commit+shrink(= make_empty) support
Am 09.06.2012 18:52, schrieb Jeff Cody: On 06/08/2012 05:08 PM, Kevin Wolf wrote: Am 08.06.2012 20:33, schrieb Jeff Cody: On 06/08/2012 01:57 PM, Kevin Wolf wrote: The question is what the speed parameter really means for a live commit block job (or for an active mirror). I think it would make sense to limit only the speed of I/O that doesn't come from the guest but is from the background copying. If you did apply it to guest I/O as well, then I think the logical consequence would be that guest I/O is throttled as well because requests only complete when they have reached both source and target. (I know I'm happily mixing terminology of all kinds of live block jobs here, hope you understand anyway what I mean ;-)) I understand what you mean :) My thought is that the block commit 'speed' parameter would essentially only apply to 'old data', that is being copied in the commit coroutine, and it would be ignored (violated) for 'new data' in the mirroring-like case. I assumed we wouldn't want to throttle the guest I/O, but that may be a bad assumption on my part. I don't disagree, I just wanted to point out that throttling the guest would be another option. Applying the limit only to old data probably makes most sense indeed. Given that, perhaps it does make sense to get it implemented in two phases - first the straightforward block commit for images below the active layer, and then a follow-up patch set to implement committing in the top layer alongside an active mirroring approach for convergence. Yes, perhaps that does make sense. I'm not sure how much of it we'll be able to keep when we implement the active mirror approach, and possibly we'll just replace the initial code wholesale then, but doing everything at once sounds too big to be manageable. I am happy to do it that way. I'll shift my focus to the atomic image reopen in r/w mode. I'll go ahead and post my diagrams and other info for block-commit on the wiki, because I don't think it conflicts with we discussed above (although I will modify my diagrams to not show commit from the top-level image). Of course, feel free to change it as necessary. I may have mentioned it before, but just in case: I think Supriya's bdrv_reopen() patches are a good starting point. I don't know why they were never completed, but I think we all agreed on the general design, so it should be possible to pick that up. Though if you have already started with your own work on it, Jeff, I expect that it won't be much different because it's basically the same transactional approach that you know and that we already used for group snapshots. I will definitely use parts of Supriya's as it makes sense - what I started work on is similar to bdrv_append() and the current transaction approach, so there will be plenty in common to reuse, even with some differences. I'm not sure how far a bdrv_append-like approach will work in this case. The problem is that you must not open any image r/w twice. The policy is that you can open an image either once r/w or multiple times read-only. I think there are 3 possibilities that would be OK: open once r/w, one or more times r/o, or once r/w + one or more times r/o. Do you agree with this? Is the latter case against block-layer policy? Yes, it is. The problem is that image formats have data cached in memory, and as soon as you have a writer, the other users of the same image file - no matter whether r/w or r/o - get out of sync. They might mix old (cached) matadata with other new metadata, and I think you can imagine what mess would result. Strictly speaking even raw caches things like the image size, so if the r/w instance happens to resize the image, the additional r/o readers would have a problem even with raw. OK, thanks. I should have qualified that with saying, for this application, that it is not intended to have the images open r/w and r/o for ongoing operations; it is just for the purpose of overlapping the closing of the r/o instance. It's quite possible that it works under these circumstances. Note however that after finishing the merge you will also want to turn it back into an r/o image. The very least you need there is a bdrv_flush(), and I don't think it's enough in all cases (basically you get a problem whenever the image format uses something like QED mode where the image becomes consistent only during a clean shutdown). Things are becoming really tricky quite quickly, and this is why I prefer sticking to the strict one r/w or many r/o rule, even though special cases may happen to work in violation of this rule. In this special case for block commit, we need to do the reopen() to go from a r/o image to a r/w image. If an image is opened r/o, the drv layer can do another open with a new descriptor, this time r/w, without closing the r/o instance. If the new r/w open was successful, then the r/o instance can be closed, and some
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
Il 11/06/2012 09:56, Andreas Färber ha scritto: I thought that was just a convenience choice, not a necessity. The children objects could just as well be heap-allocated. In that case we'd need to change the instance_init signature. As far as I've understood from our discussions with Anthony, realize must not allocate new objects because that may collide with the recursive realize model, and instance_init is not supposed to fail. But qemu_malloc is also not supposed to fail. It will exit QEMU if it fails. Paolo
Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support
Am 10.06.2012 18:10, schrieb Paolo Bonzini: Il 08/06/2012 19:57, Kevin Wolf ha scritto: I agree, doing it like mirroring for new writes on the top layer makes sense, as long as you are willing to violate the (optional) speed parameter. I wouldn't think violating the speed parameter in that case would be an issue, as long as it is a documented affect of performing a live commit on the active (top) layer. The question is what the speed parameter really means for a live commit block job (or for an active mirror). I think it would make sense to limit only the speed of I/O that doesn't come from the guest but is from the background copying. Not necessarily, you can throttle the copying speed. If the I/O from the guest has bursts, you will pick up the work later when the rate calms down. Then it's not an active mirror any more, but a passive one. Kevin
Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support
Il 11/06/2012 09:59, Kevin Wolf ha scritto: I agree, doing it like mirroring for new writes on the top layer makes sense, as long as you are willing to violate the (optional) speed parameter. I wouldn't think violating the speed parameter in that case would be an issue, as long as it is a documented affect of performing a live commit on the active (top) layer. The question is what the speed parameter really means for a live commit block job (or for an active mirror). I think it would make sense to limit only the speed of I/O that doesn't come from the guest but is from the background copying. Not necessarily, you can throttle the copying speed. If the I/O from the guest has bursts, you will pick up the work later when the rate calms down. Then it's not an active mirror any more, but a passive one. Yes, I guess what I was saying is that the passive mirror code can be used also for live commit of the top image. Paolo
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
Am 11.06.2012 09:56, schrieb Andreas Färber: Am 11.06.2012 09:20, schrieb Paolo Bonzini: Il 11/06/2012 09:13, Andreas Färber ha scritto: +The first step is to move your device struct definition to a header file. This +header file should only contain the struct definition and any preprocessor +declarations you need to define the structure. This header file will act as +the source for the QC IDL compiler. I don't think this is a fantastic idea -- the device struct should be private to the device, and having it in a standalone header file is asking for users of the device to illicitly include it and access internals that they shouldn't. But that is exactly where realize is headed. PCIBus, a9mp_priv etc. structs will need to be made public so that they can be embedded. I thought that was just a convenience choice, not a necessity. The children objects could just as well be heap-allocated. In that case we'd need to change the instance_init signature. As far as I've understood from our discussions with Anthony, realize must not allocate new objects because that may collide with the recursive realize model, and instance_init is not supposed to fail. Thus the in-place init demonstrated for i440fx and now adopted for prep_pci and my tegra2. Saying the device struct should be private to the device leaves virtually no choice, whether for convenience or necessity, and requires also suggesting a design solution for QOM initialization. Forgot to mention that this has nothing to do with child properties. It's about composition, i.e. instantiating on object without needing to know about its inner structure - paradoxically this needs that inner structure to be exposed even if not accessed. 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 qom-next 1/7] qdev: Push state up to Object
Am 10.06.2012 19:38, schrieb Andreas Färber:
Am 10.06.2012 17:49, schrieb Paolo Bonzini:
Il 08/06/2012 03:19, Anthony Liguori ha scritto:
+typedef enum ObjectState {
+OBJECT_STATE_INITIALIZED = 1,
+OBJECT_STATE_REALIZED,
+} ObjectState;
I think using a bool would be better since it reduces the temptation to
add additional states.
In fact someone already discussed having a third state for block
devices... :)
I would expect that file_opened state to remain internal to the block
layer. Thought we discussed that on IRC?
I think I still don't understand well enough what 'realized' is really
supposed to mean.
Does some magic happen when an object gets realised? From outside,
what's the difference between an INITIALIZED and a REALIZED object? Is
it more or less an implementation detail of the base class or is it
something that affects the object model itself?
I think the file_opened state should have more or less the same status
as the realisation of an object. They are quite similar, so they should
both be an implementation detail of their respective class, or they
should both be baked into the object model.
A comment in this patch says it means that an object is fully
constructed. So if we add a file_opened state in the block layer, in
order to keep this consistent, it would have to be a state that comes
between INITIALIZED and REALIZED.
Where would we have checks, for example whether the image that you
assign to a block device is really opened? Would QOM commands to create
a link only link to already realised objects? Would each single block
device have to check this during its own realisation phase? Would we
check object_is_realized() or rather bdrv_file_is_opened()? If the
latter, it can't be generic monitor code that checks it.
Let's start with this, I'm sure I'll have more questions...
Kevin
Re: [Qemu-devel] [PATCH 1/3] qxl: add fb_size_mb and fb_size
On Mon, Jun 11, 2012 at 09:42:28AM +0200, Gerd Hoffmann wrote:
Hi,
+if (d-fb_size fb) {
+d-fb_size = fb;
+}
+if (fb = d-fb_size) {
This check doesn't make sense, it will always be true.
My mistake. Will remove the first three lines, so fb_size setting will
be required to get larger modes.
+if (qxl-fb_size_mb != -1
+qxl-fb_size_mb * 1024 * 1024 qxl-vga.vram_size) {
+qxl-fb_size = qxl-fb_size_mb * 1024 * 1024;
+} else {
+qxl-fb_size = VGA_RAM_SIZE;
+}
Reminds me that I have some pending work to make vga ram size
configurable which I should finish and repost ...
Current state pushed to http://www.kraxel.org/cgit/qemu/log/?h=vga.1
It probably makes sense to base this on top.
So I can rebase on top and send the patches, with the understanding you
will do any later changes and repost the whole thing.
+DEFINE_PROP_UINT32(fb_size_mb, PCIQXLDevice, fb_size_mb, -1),
Maybe also rename this to vgamem_mb for consistency with standard vga.
Will change.
cheers,
Gerd
Re: [Qemu-devel] [PATCH 1/3] qxl: add fb_size_mb and fb_size
Hi, Reminds me that I have some pending work to make vga ram size configurable which I should finish and repost ... Current state pushed to http://www.kraxel.org/cgit/qemu/log/?h=vga.1 It probably makes sense to base this on top. So I can rebase on top and send the patches, with the understanding you will do any later changes and repost the whole thing. Yes, makes sense to put them into one series I think. cheers, Gerd
Re: [Qemu-devel] [PATCH 1/3] qxl: add fb_size_mb and fb_size
On Mon, Jun 11, 2012 at 10:29:59AM +0200, Gerd Hoffmann wrote: Hi, Reminds me that I have some pending work to make vga ram size configurable which I should finish and repost ... Current state pushed to http://www.kraxel.org/cgit/qemu/log/?h=vga.1 It probably makes sense to base this on top. So I can rebase on top and send the patches, with the understanding you will do any later changes and repost the whole thing. Yes, makes sense to put them into one series I think. You dropped me from the to field, please don't. Hope you didn't miss the one liner async_complete reset patch. cheers, Gerd
Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
On Mon, Jun 11, 2012 at 08:28:57AM +0200, Paolo Bonzini wrote: Il 09/06/2012 05:04, Zhi Yong Wu ha scritto: This commit looks suspicious because it removes a user-visible qdev property but we're trying to preserve backward compatibility. This command-line will break: x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device virtio-net-pci,vlan=1 Instead of dropping the qdev_prop_vlan completely the hw/qdev-properties.c code needs to call net/hub.h external functions to implement equivalent functionality: 1. Setting the vlan=id property looks up the hub port and assigns the NICConf-peer field. 2. Getting the vlan property looks up the hub id (i.e. vlan id) given the peer. If the peer is not a hub port the result is -1. When I wrote this patch I missed the big picture and forgot about backwards compatibility :(. To be honest, i am concerned if anyone uses this syntax. Since the feature will finally be discarded, i suggest that we don't support this now. If someone complains this later, we can fix it. If nobody complains, that is what we hope. I think you're missing the big picture of this series, which is exactly _not_ to discard the VLAN feature, but just to rewrite it in a better way. That said, I agree that this is a somewhat fringe usage; most people will use -net nic,model=virtio,vlan=1 rather than -device. We may get by with dropping it. I have no strong opinion either way. Either we keep backwards compatibility or we don't. Taking a middle path where we preserve only some of the VLAN syntax is confusing and inconsistent. Like Paolo said, the point here is not to drop VLAN support. We're simply moving this feature into a regular net client (the hub) so that the special case VLAN code in net.c can be removed. Stefan
Re: [Qemu-devel] [PATCH v5 2/2] net: add the support for -netdev socket, listen
On Sat, Jun 09, 2012 at 10:09:44AM +0800, Zhi Yong Wu wrote: On Fri, Jun 8, 2012 at 11:59 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Jun 8, 2012 at 3:54 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Jun 8, 2012 at 6:31 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Jun 7, 2012 at 3:54 PM, zwu.ker...@gmail.com wrote: @@ -86,7 +82,16 @@ static void net_socket_send(void *opaque) /* end of connection */ eoc: qemu_set_fd_handler(s-fd, NULL, NULL, NULL); + qemu_set_fd_handler(s-listen_fd, net_socket_accept, NULL, s); What happens when this is not a listen socket? I suggest setting listen_fd to -1 during creation and not calling qemu_set_fd_handler() when listen_fd is -1 here. If listen_fd is 0 then we'll register net_socket_accept when standard input becomes ready! closesocket(s-fd); + + s-fd = 0; -1 should be used since 0 is a valid file descriptor (standard input). I think that s-fd = 0 doesn't cause every issue. When it is zero, this fd hasn't been registered with every handler. You can see that qemu_set_fd_handler(s-fd, NULL, NULL, NULL); before s-fd = 0. If s-fd = 0 because we are still listening and net_socket_cleanup() OK, done. any other issue? I haven't seen your new code yet so I'm not sure. Basically if you have introduced -1 states for s-fd and s-listen_fd as well as checks before calling qemu_set_fd_handler() or close(), then the code is fine. Stefan
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
Am 11.06.2012 09:59, schrieb Paolo Bonzini:
Il 11/06/2012 09:56, Andreas Färber ha scritto:
I thought that was just a convenience choice, not a necessity. The
children objects could just as well be heap-allocated.
In that case we'd need to change the instance_init signature. As far as
I've understood from our discussions with Anthony, realize must not
allocate new objects because that may collide with the recursive realize
model, and instance_init is not supposed to fail.
But qemu_malloc is also not supposed to fail. It will exit QEMU if it
fails.
(s/qemu_malloc/g_malloc/g)
...which is not always desired.
void *objp = g_try_malloc(sizeof(MyState)); /* may fail without abort */
if (objp != NULL) {
object_initialize(objp, TYPE_MY); /* may not fail */
} else {
/* report error to caller */
}
This becomes more important the more objects we allocate at runtime in
response to users' QMP commands.
When we talk about QEMU startup then we are in violent agreement that it
can abort. When influenced by user-tunable options like -m then it
starts to become less clear, there seemed agreement that it shouldn't
abort but fail with a nice error message (seems not followed up with a
patch though?).
But as I've seen in v0.15.x bug reports and reported last fall for
v1.0-rcX, allocations can fail while the guest is running (even without
active user interaction: network? block? memory usage varied HIGHly
according to simpletrace analyzed) and also being far from the hard
physical limit depending on ulimit settings (e.g., 41G'ish on a 64 GB
RAM system with default soft virtual limit of 80%).
Examples I have in mind where user interaction shouldn't crash the guest
is hotplugging an x86 CPU with its APIC or hotplugging a ppc CPU with
its large'ish opcode table. About a 5-char g_strdup() I'm not as worried. ;)
So from my view, the solution is to have basic versions such as
qdev_create() abort and to also provide advanced versions like
qdev_try_create() to handle more sophisticated enterprise use cases. QOM
does not provide a double API in the same way qdev did, but the above
snippet shows that if proper QOM modelling is used - the topic of this
thread - it can be compensated with GLib. Either way it requires
knowledge about struct sizes so they need to be exposed somehow.
What I started playing with a few weeks ago is reporting OOM via Error;
that's a bit trickier since allocating a new object might fail as well,
so it needs to be preallocated and there was some reference-counting
iirc that didn't play nicely with a never-to-be-freed object. Use cases
might include adding properties - which is and must be done in
instance_init - and retrieving string properties.
Not the highest priority for me at the moment, but something we
shouldn't make impossible by Bad Design.
I have deriving a public BNC# for this on my TODO list, to preserve my
graphs and analysis tools...
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 v4 3/7] trace: Provide a detailed event control interface
On Tue, May 8, 2012 at 3:38 PM, Lluís Vilanova vilan...@ac.upc.edu wrote:
@@ -27,10 +96,19 @@ void trace_backend_init_events(const char *fname)
size_t len = strlen(line_buf);
if (len 1) { /* skip empty lines */
line_buf[len - 1] = '\0';
- if (!trace_event_set_state(line_buf, true)) {
- fprintf(stderr,
- error: trace event '%s' does not exist\n,
line_buf);
- exit(1);
+ if (trace_event_is_pattern(line_buf)) {
+ TraceEvent *ev;
+ while ((ev = trace_event_pattern(line_buf, ev)) != NULL) {
ev must be initialized to NULL.
Stefan
Re: [Qemu-devel] [PATCH 1/3] qxl: add fb_size_mb and fb_size
On Mon, Jun 11, 2012 at 10:29:59AM +0200, Gerd Hoffmann wrote: Hi, Reminds me that I have some pending work to make vga ram size configurable which I should finish and repost ... Current state pushed to http://www.kraxel.org/cgit/qemu/log/?h=vga.1 It probably makes sense to base this on top. So I can rebase on top and send the patches, with the understanding you will do any later changes and repost the whole thing. Yes, makes sense to put them into one series I think. git://people.freedesktop.org/~alon/qemu fb_async_fix.v2 cheers, Gerd
Re: [Qemu-devel] [PATCH v4 4/7] trace: [monitor] Use new event control interface
On Tue, May 8, 2012 at 3:38 PM, Lluís Vilanova vilan...@ac.upc.edu wrote:
Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu
---
monitor.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index 8946a10..86c2538 100644
--- a/monitor.c
+++ b/monitor.c
@@ -625,10 +625,19 @@ static void do_trace_event_set_state(Monitor *mon,
const QDict *qdict)
{
const char *tp_name = qdict_get_str(qdict, name);
bool new_state = qdict_get_bool(qdict, option);
- int ret = trace_event_set_state(tp_name, new_state);
- if (!ret) {
- monitor_printf(mon, unknown event name \%s\\n, tp_name);
+ if (trace_event_is_pattern(tp_name)) {
+ TraceEvent *ev = NULL;
+ while ((ev = trace_event_pattern(tp_name, ev)) != NULL) {
+ trace_event_set_state_dynamic(ev, new_state);
+ }
+ } else {
+ TraceEvent *ev = trace_event_name(tp_name);
+ if (ev == NULL) {
+ monitor_printf(mon, unknown event name \%s\\n, tp_name);
+ } else {
+ trace_event_set_state_dynamic(ev, new_state);
+ }
Why check for a pattern and split the code in two? How about just:
while ((ev = trace_event_pattern(tp_name, ev)) != NULL) {
...
}
That should cover both the single trace event name case and the wildcard case.
Stefan
Re: [Qemu-devel] [PATCH v4] vnc: disable VNC password authentication (security type 2) when in FIPS mode
On Fri, Jun 08, 2012 at 05:38:12PM -0400, Paul Moore wrote: FIPS 140-2 requires disabling certain ciphers, including DES, which is used by VNC to obscure passwords when they are sent over the network. The solution for FIPS users is to disable the use of VNC password auth when the host system is operating in FIPS mode. This patch causes QEMU to emit a message to stderr when the host system is running in FIPS mode and a VNC password was specified on the commend line. If the system is not running in FIPS mode, or is running in FIPS mode but VNC password authentication was not requested, QEMU operates normally. Signed-off-by: Paul Moore pmo...@redhat.com Reviewed-by: Daniel P. Berrange berra...@redhat.com Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH v4 4/7] trace: [monitor] Use new event control interface
Stefan Hajnoczi writes:
On Tue, May 8, 2012 at 3:38 PM, Lluís Vilanova vilan...@ac.upc.edu wrote:
Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu
---
monitor.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index 8946a10..86c2538 100644
--- a/monitor.c
+++ b/monitor.c
@@ -625,10 +625,19 @@ static void do_trace_event_set_state(Monitor *mon,
const QDict *qdict)
{
const char *tp_name = qdict_get_str(qdict, name);
bool new_state = qdict_get_bool(qdict, option);
- int ret = trace_event_set_state(tp_name, new_state);
- if (!ret) {
- monitor_printf(mon, unknown event name \%s\\n, tp_name);
+ if (trace_event_is_pattern(tp_name)) {
+ TraceEvent *ev = NULL;
+ while ((ev = trace_event_pattern(tp_name, ev)) != NULL) {
+ trace_event_set_state_dynamic(ev, new_state);
+ }
+ } else {
+ TraceEvent *ev = trace_event_name(tp_name);
+ if (ev == NULL) {
+ monitor_printf(mon, unknown event name \%s\\n, tp_name);
+ } else {
+ trace_event_set_state_dynamic(ev, new_state);
+ }
Why check for a pattern and split the code in two? How about just:
while ((ev = trace_event_pattern(tp_name, ev)) != NULL) {
...
}
That should cover both the single trace event name case and the wildcard case.
That's true... it's just that somehow I thought it was abusive to use pattern
matching on a string without patterns :)
Lluis
--
And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer.
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth
Re: [Qemu-devel] [PATCH v4 1/7] tracetool: Explicitly identify public backends
On Tue, May 8, 2012 at 3:38 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Public backends are those printed by --list-backends and thus considered valid by the configure script. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- scripts/tracetool.py | 4 ++-- scripts/tracetool/backend/__init__.py | 16 +++- scripts/tracetool/backend/dtrace.py | 3 +++ scripts/tracetool/backend/simple.py | 3 +++ scripts/tracetool/backend/stderr.py | 3 +++ scripts/tracetool/backend/ust.py | 3 +++ 6 files changed, 29 insertions(+), 3 deletions(-) Is there any use for PUBLIC in qemu.git/master at this time? If there is no real user in mainline yet then I'd rather not take this code. Stefan
Re: [Qemu-devel] [PATCH v4 0/7] trace: Generic event state description
On Tue, May 8, 2012 at 3:38 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Provides a generic event state description and a more detailed event control and query interface. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- Changes in v4: * Documentation fixes and (re)formatting. Changes in v3: * Add some assertions. * Remove debugging printf's. * Improve documentation. * Make 'trace_event_get_state_static' use run-time information, and leave TRACE_*_ENABLED for compile-time checks. Changes in v2: * Minor compilation fixes. Lluís Vilanova (7): tracetool: Explicitly identify public backends trace: Provide a generic tracing event descriptor trace: Provide a detailed event control interface trace: [monitor] Use new event control interface trace: [default] Use new event control interface trace: [simple] Port to generic event information and new control interface trace: [stderr] Port to generic event information and new control interface Makefile | 5 + Makefile.objs | 21 docs/tracing.txt | 42 +++ monitor.c | 15 ++- scripts/tracetool.py | 4 - scripts/tracetool/backend/__init__.py | 16 +++ scripts/tracetool/backend/dtrace.py | 3 + scripts/tracetool/backend/events.py | 23 scripts/tracetool/backend/simple.py | 15 +-- scripts/tracetool/backend/stderr.py | 28 ++--- scripts/tracetool/backend/ust.py | 3 + scripts/tracetool/format/events_c.py | 39 +++ scripts/tracetool/format/events_h.py | 50 + scripts/tracetool/format/h.py | 9 -- trace/control-internal.h | 60 +++ trace/control.c | 92 +++- trace/control.h | 185 ++--- trace/default.c | 6 + trace/event-internal.h | 33 ++ trace/simple.c | 37 ++- trace/simple.h | 6 - trace/stderr.c | 35 +- trace/stderr.h | 11 -- 23 files changed, 568 insertions(+), 170 deletions(-) create mode 100644 scripts/tracetool/backend/events.py create mode 100644 scripts/tracetool/format/events_c.py create mode 100644 scripts/tracetool/format/events_h.py create mode 100644 trace/control-internal.h create mode 100644 trace/event-internal.h delete mode 100644 trace/stderr.h What is the point of sstate vs dstate? It seems the dynamic state is what can be toggled and sstate is the disable keyword. Why have sstate since there is already a macro? Stefan
Re: [Qemu-devel] [PATCH 1.1?] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX
On Wed, 30 May 2012, Anthony Liguori wrote: Reviewed-by: Stefan Weils...@weilnetz.de This patch clearly improves the current code and fixes an abort on Darwin (reported by Andreas Färber) and maybe other hosts. Therefore I changed the subject and suggest to consider this patch for QEMU 1.1. Not for 1.1.0. I'm just a few hours away from pushing the 1.1.0-rc4 tag and I don't plan on doing any updates before GA unless something critical emerges. Anthony, are you going to pick this one up for 1.1.1? Do you need me to do anything?
Re: [Qemu-devel] [PATCH 1/2] kvm/apic: correct short memset
On 05/10/2012 07:19 PM, Jim Meyering wrote: From: Jim Meyering meyer...@redhat.com kvm_put_apic_state's attempt to clear *kapic before setting its bits cleared sizeof(void*) bytes (no more than 8) rather than the intended 1024 (KVM_APIC_REG_SIZE) bytes. Spotted by coverity. Thanks, applied to uq/master. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH uq/master] kvm: i8254: Fix conversion of in-kernel to userspace state
On 06/06/2012 05:28 PM, Jan Kiszka wrote: Due to a offset between the clock used to generate the in-kernel count_load_time (CLOCK_MONOTONIC) and the clock used for processing this in userspace (vm_clock), reading back the output of PIT channel 2 via port 0x61 was broken. One use cases that suffered from it was the CPU frequency calibration of SeaBIOS, which also affected IDE/AHCI timeouts. This fixes it by calibrating the offset between both clocks on kvm_pit_get and adjusting the kernel value before saving it in the userspace state. As the calibration only works while the vm_clock is running, we cache the in-kernel state across stopped phases. Applied, thanks. +clock_offset = LLONG_MAX; INT64_MAX would me more strictly correct, but in practice it makes no difference. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 1.1?] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX
Am 11.06.2012 11:55, schrieb Stefano Stabellini: On Wed, 30 May 2012, Anthony Liguori wrote: Reviewed-by: Stefan Weils...@weilnetz.de This patch clearly improves the current code and fixes an abort on Darwin (reported by Andreas Färber) and maybe other hosts. Therefore I changed the subject and suggest to consider this patch for QEMU 1.1. Not for 1.1.0. I'm just a few hours away from pushing the 1.1.0-rc4 tag and I don't plan on doing any updates before GA unless something critical emerges. Anthony, are you going to pick this one up for 1.1.1? Do you need me to do anything? I think I still need to test this one... thanks for the reminder. ;) Andreas
[Qemu-devel] [PULL] qemu/xendisk fix
Hi Anthony, please pull one fix for xen_disk from here: git://xenbits.xen.org/people/sstabellini/qemu-dm.git for_1.1.1 The fix should be applied to the 1.1.x stable tree too. Jan Beulich (1): qemu/xendisk: set maximum number of grants to be used hw/xen_disk.c | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) Cheers. Stefano
Re: [Qemu-devel] [Xen-devel] [PATCH, v3] qemu/xendisk: set maximum number of grants to be used
On Fri, 8 Jun 2012, Ian Jackson wrote: Stefano Stabellini writes (Re: [Xen-devel] [PATCH, v3] qemu/xendisk: set maximum number of grants to be used): On Thu, 31 May 2012, Jan Beulich wrote: It should be applied to qemu-xen-traditional too. And the other one (qemu/xendisk: properly update stats in ioreq_release()) probably too. Right. That patch is already in upstream QEMU and qemu-xen-upstream but it is missing in qemu-xen-traditional. Can you tell me the commit id in qemu-xen-upstream so I can put it in the commit message in qemu-xen-traditional ? I'll let you know when I have one.
[Qemu-devel] KVM call agenda for Thrusday, June 12th
Hi Please, send in any agenda items you are interested in covering. Later, Juan.
Re: [Qemu-devel] [PATCH 1/3] qxl: add fb_size_mb and fb_size
On 06/11/12 11:33, Alon Levy wrote: On Mon, Jun 11, 2012 at 10:29:59AM +0200, Gerd Hoffmann wrote: Hi, Reminds me that I have some pending work to make vga ram size configurable which I should finish and repost ... Current state pushed to http://www.kraxel.org/cgit/qemu/log/?h=vga.1 It probably makes sense to base this on top. So I can rebase on top and send the patches, with the understanding you will do any later changes and repost the whole thing. Yes, makes sense to put them into one series I think. git://people.freedesktop.org/~alon/qemu fb_async_fix.v2 http://www.kraxel.org/cgit/qemu/log/?h=vga.2 Did some small fixups [no need for the -1 dance, the reason the other properties do that is that we have one accepting byte values and one accepting megabyte values]. looks ok to you? cheers, Gerd
Re: [Qemu-devel] [Xen-devel] [PATCH, v3] qemu/xendisk: set maximum number of grants to be used
On Mon, 11 Jun 2012, Stefano Stabellini wrote: On Fri, 8 Jun 2012, Ian Jackson wrote: Stefano Stabellini writes (Re: [Xen-devel] [PATCH, v3] qemu/xendisk: set maximum number of grants to be used): On Thu, 31 May 2012, Jan Beulich wrote: It should be applied to qemu-xen-traditional too. And the other one (qemu/xendisk: properly update stats in ioreq_release()) probably too. Right. That patch is already in upstream QEMU and qemu-xen-upstream but it is missing in qemu-xen-traditional. Can you tell me the commit id in qemu-xen-upstream so I can put it in the commit message in qemu-xen-traditional ? I'll let you know when I have one. Reading more carefully, you are actually talking about a different patch from the one in the subject line. Here is what you are looking for: commit ed5477664369c1e9de23b0e7e8f16a418573bd2a Author: Jan Beulich jbeul...@suse.com Date: Mon May 14 16:46:33 2012 + xen_disk: properly update stats in ioreq_release() While for the normal case (called from blk_send_response_all()) decrementing requests_finished is correct, doing so in the parse error case is wrong; requests_inflight needs to be decremented instead. Signed-off-by: Jan Beulich jbeul...@suse.com Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Reviewed-by: Kevin Wolf kw...@redhat.com
Re: [Qemu-devel] [PATCH 1/3] qxl: add fb_size_mb and fb_size
On Mon, Jun 11, 2012 at 12:18:14PM +0200, Gerd Hoffmann wrote: On 06/11/12 11:33, Alon Levy wrote: On Mon, Jun 11, 2012 at 10:29:59AM +0200, Gerd Hoffmann wrote: Hi, Reminds me that I have some pending work to make vga ram size configurable which I should finish and repost ... Current state pushed to http://www.kraxel.org/cgit/qemu/log/?h=vga.1 It probably makes sense to base this on top. So I can rebase on top and send the patches, with the understanding you will do any later changes and repost the whole thing. Yes, makes sense to put them into one series I think. git://people.freedesktop.org/~alon/qemu fb_async_fix.v2 http://www.kraxel.org/cgit/qemu/log/?h=vga.2 Did some small fixups [no need for the -1 dance, the reason the other properties do that is that we have one accepting byte values and one accepting megabyte values]. looks ok to you? Looks like you squashed and removed the -1 (you're right of course, it was just me doing a straight copy), other then that I didn't notice anything. Looks good. cheers, Gerd
[Qemu-devel] [PATCH] KVM: i8254: Clean up limit constant
On 2012-06-11 12:07, Avi Kivity wrote:
On 06/06/2012 05:28 PM, Jan Kiszka wrote:
Due to a offset between the clock used to generate the in-kernel
count_load_time (CLOCK_MONOTONIC) and the clock used for processing this
in userspace (vm_clock), reading back the output of PIT channel 2 via
port 0x61 was broken. One use cases that suffered from it was the CPU
frequency calibration of SeaBIOS, which also affected IDE/AHCI timeouts.
This fixes it by calibrating the offset between both clocks on
kvm_pit_get and adjusting the kernel value before saving it in the
userspace state. As the calibration only works while the vm_clock is
running, we cache the in-kernel state across stopped phases.
Applied, thanks.
+clock_offset = LLONG_MAX;
INT64_MAX would me more strictly correct, but in practice it makes no
difference.
Was looking for this, just not long enough. Need to print some cheat
sheet. However, let's clean this up immediately:
---8---
clock_offset is int64_t.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/kvm/i8254.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/kvm/i8254.c b/hw/kvm/i8254.c
index 04333d8..c5d3711 100644
--- a/hw/kvm/i8254.c
+++ b/hw/kvm/i8254.c
@@ -62,7 +62,7 @@ static void kvm_pit_get(PITCommonState *pit)
* kvm_pit_channel_state::count_load_time, and vm_clock. Take the
* minimum of several samples to filter out scheduling noise.
*/
-clock_offset = LLONG_MAX;
+clock_offset = INT64_MAX;
for (i = 0; i CALIBRATION_ROUNDS; i++) {
offset = qemu_get_clock_ns(vm_clock);
clock_gettime(CLOCK_MONOTONIC, ts);
--
1.7.3.4
Re: [Qemu-devel] [PATCH v4 1/7] tracetool: Explicitly identify public backends
Stefan Hajnoczi writes: On Tue, May 8, 2012 at 3:38 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Public backends are those printed by --list-backends and thus considered valid by the configure script. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- scripts/tracetool.py | 4 ++-- scripts/tracetool/backend/__init__.py | 16 +++- scripts/tracetool/backend/dtrace.py | 3 +++ scripts/tracetool/backend/simple.py | 3 +++ scripts/tracetool/backend/stderr.py | 3 +++ scripts/tracetool/backend/ust.py | 3 +++ 6 files changed, 29 insertions(+), 3 deletions(-) Is there any use for PUBLIC in qemu.git/master at this time? If there is no real user in mainline yet then I'd rather not take this code. Yes, next patch adds a new backend that should not be selectable by the user at configure time. Lluis -- And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer. -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: [Qemu-devel] [PATCH v4 0/7] trace: Generic event state description
Stefan Hajnoczi writes: On Tue, May 8, 2012 at 3:38 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Provides a generic event state description and a more detailed event control and query interface. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- [...] What is the point of sstate vs dstate? It seems the dynamic state is what can be toggled and sstate is the disable keyword. Why have sstate since there is already a macro? 'sstate' is there just in case you query the tracing state of an event through the 'TraceEvent' structure instead of through the corresponding macro. Lluis -- And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer. -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
[Qemu-devel] [Bug 1011142] Re: Arm emulation do a crash
Hello, I have succefull run debian raspberry pi under qemu. Then I try do like under my x86, mount -t proc none proc,..., chroot /mnt/gentoo /bin/bash, ... - illegal instruction. Then I try with boot directly from the gentoo's part - lot of illegal instruction, I have used like say on the web: stage3-armv6j_hardfp-20120603.tar.bz2 What's appends? Qemu not emulate hardfp? Or something like that's? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1011142 Title: Arm emulation do a crash Status in QEMU: New Bug description: Hello, I have try multiple image for the raspberry pi, with this cli: /usr/bin/qemu-system-arm -kernel kernel-rasptoo -M versatilepb -cpu arm1176 -hda hdd.img -m 256 -append root=/dev/sda2 loglevel=7 debug -serial stdio -no-kvm I don't know why, with kvm it say: KVM not supported for this target No accelerator found! I can't debug it with gdb, it crash after the kernel boot (the qemu application crash). I'm under gentoo: [ebuild R ~] app-emulation/qemu-kvm-1.0.1-r1 USE=aio alsa curl ncurses opengl sdl threads vhost-net -bluetooth -brltty -debug -fdt -pulseaudio -qemu-ifup (-rbd) -sasl -smartcard -spice -static -test -tls -usbredir -vde -xattr -xen QEMU_SOFTMMU_TARGETS=arm x86_64 -cris -i386 -m68k -microblaze -mips -mips64 -mips64el -mipsel -ppc -ppc64 -ppcemb -sh4 -sh4eb -sparc -sparc64 QEMU_USER_TARGETS=arm -alpha -armeb -cris -i386 -m68k -microblaze -mips -mipsel -ppc -ppc64 -ppc64abi32 -sh4 -sh4eb -sparc -sparc32plus -sparc64 -x86_64 0 kB Thanks to help me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1011142/+subscriptions
Re: [Qemu-devel] [PATCH] KVM: i8254: Clean up limit constant
On 06/11/2012 01:29 PM, Jan Kiszka wrote: On 2012-06-11 12:07, Avi Kivity wrote: On 06/06/2012 05:28 PM, Jan Kiszka wrote: Due to a offset between the clock used to generate the in-kernel count_load_time (CLOCK_MONOTONIC) and the clock used for processing this in userspace (vm_clock), reading back the output of PIT channel 2 via port 0x61 was broken. One use cases that suffered from it was the CPU frequency calibration of SeaBIOS, which also affected IDE/AHCI timeouts. This fixes it by calibrating the offset between both clocks on kvm_pit_get and adjusting the kernel value before saving it in the userspace state. As the calibration only works while the vm_clock is running, we cache the in-kernel state across stopped phases. Applied, thanks. +clock_offset = LLONG_MAX; INT64_MAX would me more strictly correct, but in practice it makes no difference. Was looking for this, just not long enough. Need to print some cheat sheet. However, let's clean this up immediately: ---8--- clock_offset is int64_t. Thanks, folded. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v4 0/7] trace: Generic event state description
On Mon, Jun 11, 2012 at 12:12 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Stefan Hajnoczi writes: On Tue, May 8, 2012 at 3:38 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Provides a generic event state description and a more detailed event control and query interface. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- [...] What is the point of sstate vs dstate? It seems the dynamic state is what can be toggled and sstate is the disable keyword. Why have sstate since there is already a macro? 'sstate' is there just in case you query the tracing state of an event through the 'TraceEvent' structure instead of through the corresponding macro. If this is not used by a tracer today we should hold off until it's needed. Stefan
Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support
On Fri, Jun 8, 2012 at 6:46 PM, Jeff Cody jc...@redhat.com wrote: On 06/08/2012 12:11 PM, Kevin Wolf wrote: Am 08.06.2012 16:32, schrieb Jeff Cody: On 06/08/2012 09:53 AM, Stefan Hajnoczi wrote: On Fri, Jun 8, 2012 at 2:19 PM, Jeff Cody jc...@redhat.com wrote: On 06/08/2012 08:42 AM, Stefan Hajnoczi wrote: Let's figure out how to specify block-commit so we're all happy, that way we can avoid duplicating work. Any comments on my notes above? I think we are almost completely on the same page - devil is in the details, of course (for instance, on how to convert the destination base from r/o to r/w). Great. The atomic r/o - r/w transition and the commit coroutine can be implemented on in parallel. Are you happy to implement the atomic r/o - r/w transition since you wrote bdrv_append()? Then Zhi Hui can assume that part already works and focus on implementing the commit coroutine in the meantime. I'm just suggesting a way to split up the work, please let me know if you think this is good. I am happy to do it that way. I'll shift my focus to the atomic image reopen in r/w mode. I'll go ahead and post my diagrams and other info for block-commit on the wiki, because I don't think it conflicts with we discussed above (although I will modify my diagrams to not show commit from the top-level image). Of course, feel free to change it as necessary. I may have mentioned it before, but just in case: I think Supriya's bdrv_reopen() patches are a good starting point. I don't know why they were never completed, but I think we all agreed on the general design, so it should be possible to pick that up. Though if you have already started with your own work on it, Jeff, I expect that it won't be much different because it's basically the same transactional approach that you know and that we already used for group snapshots. I will definitely use parts of Supriya's as it makes sense - what I started work on is similar to bdrv_append() and the current transaction approach, so there will be plenty in common to reuse, even with some differences. I have CCed Supriya who has been working on the reopen patch series. She is close to posting a new version. Stefan
Re: [Qemu-devel] [PATCH 1.1] monitor: Fix memory leak with readline completion
On Mon, May 14, 2012 at 8:47 PM, Stefan Weil s...@weilnetz.de wrote: Each string which is shown during readline completion in the QEMU monitor is allocated dynamically but currently never deallocated. Add the missing loop which calls g_free for the allocated strings. Signed-off-by: Stefan Weil s...@weilnetz.de --- readline.c | 3 +++ 1 file changed, 3 insertions(+) Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Re: [Qemu-devel] [PATCH for-1.1] libqtest: Fix socket_accept() to pass address_len
Am 28.05.2012 00:53, schrieb Andreas Färber:
accept() expects address_len to point to the length of the sockaddr on
input. Initialize it accordingly.
Resolves an assertion due to EFAULT on illumos.
Signed-off-by: Andreas Färber andreas.faer...@web.de
Ping? Verifiable by looking at the Linux man page.
/-F
---
tests/libqtest.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tests/libqtest.c b/tests/libqtest.c
index 6d333ef..1d73fd1 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -74,6 +74,7 @@ static int socket_accept(int sock)
socklen_t addrlen;
int ret;
+addrlen = sizeof(addr);
do {
ret = accept(sock, (struct sockaddr *)addr, addrlen);
} while (ret == -1 errno == EINTR);
Re: [Qemu-devel] [PATCH v2 2/3] Simpletrace v2: Add support for multiple args, strings.
On 06/07/2012 08:02 PM, Stefan Hajnoczi wrote:
On Thu, May 24, 2012 at 10:50 AM, Harsh Prateek Bora
ha...@linux.vnet.ibm.com wrote:
A newer tracelog format which gets rid of fixed size trace records and
therefore allows to trace multiple arguments as well as strings in trace
events.
Sample trace:
v9fs_version 0.000 tag=0x id=0x64 msize=0x2000 version=9P2000.L
v9fs_version_return 6.705 tag=0x id=0x64 msize=0x2000 version=9P2000.L
v9fs_attach 174.467 tag=0x1 id=0x68 fid=0x0 afid=0x
uname=nobody aname=
v9fs_attach_return 4720.454 tag=0x1 id=0x68 type=0xff80
version=0x4f2a4dd0 path=0x220ea6
Signed-off-by: Harsh Prateek Boraha...@linux.vnet.ibm.com
---
scripts/tracetool/backend/simple.py | 84 ++---
trace/simple.c | 229 ++-
trace/simple.h | 38 +-
3 files changed, 240 insertions(+), 111 deletions(-)
Sorry for the delay. Mostly easy to fix comments, some care still
needed to avoid race conditions and use memory barriers in the right
places.
Hi Stefan,
Thanks for reviewing, I have some questions below:
@@ -75,16 +96,22 @@ static char *trace_file_name = NULL;
*
* Returns false if the record is not valid.
*/
-static bool get_trace_record(unsigned int idx, TraceRecord *record)
+static bool get_trace_record(unsigned int idx, TraceRecord **recordptr)
{
-if (!(trace_buf[idx].event TRACE_RECORD_VALID)) {
+uint8_t temp_rec[ST_REC_HDR_LEN];
+TraceRecord *record = (TraceRecord *) temp_rec;
+read_from_buffer(idx, temp_rec, ST_REC_HDR_LEN);
+
+if (!(record-event TRACE_RECORD_VALID)) {
return false;
}
__sync_synchronize(); /* read memory barrier before accessing record */
The need for the memory barrier is no longer clear. Previously we
were directly accessing the trace ring buffer, and therefore needed to
ensure fields were settled before accessing them. Now we use
read_from_buffer() which copies the data into our temporary struct on
the stack.
I think the best way of doing it is to read the event field first in a
separate step, then do the read memory barrier, and then read the rest
of the record. This ensures that the event field is at least as old
as the other fields we read.
Currently, it does a two step read:
read header (which includes event field and length of record as well)
sync
read rest of record (using length from header)
Are you suggesting this:
read event field only
sync (if event valid)
read header (for length)
sync
read rest of record (using length)
or
read event field only
sync (if event valid)
read header (for length)
read rest of record
As we cant read the whole record in one step without knowing its length.
-*record = trace_buf[idx];
-record-event= ~TRACE_RECORD_VALID;
+*recordptr = g_malloc(record-length);
+/* make a copy of record to avoid being overwritten */
+read_from_buffer(idx, (uint8_t *)*recordptr, record-length);
+(*recordptr)-event= ~TRACE_RECORD_VALID;
return true;
}
[]
-void trace3(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3)
+int trace_alloc_record(TraceBufferRecord *rec, TraceEventID event, uint32_t
datasize)
{
-trace(event, x1, x2, x3, 0, 0, 0);
+unsigned int idx, rec_off;
+uint32_t rec_len = ST_REC_HDR_LEN + datasize;
+uint64_t timestamp_ns = get_clock();
+
+if ((rec_len + trace_idx - writeout_idx) TRACE_BUF_LEN) {
+/* Trace Buffer Full, Event dropped ! */
+dropped_events++;
+return 1;
-ENOSPC? A negative errno is clearer than 0 - success, 1 - failure.
+}
+idx = g_atomic_int_exchange_and_add((gint *)trace_idx, rec_len) %
TRACE_BUF_LEN;
How does this deal with the race condition of two or more threads
running trace_alloc_record() concurrently when the buffer reaches max
size? I think two or more threads could think they have enough space
because trace_idx hasn't been updated yet between the buffer length
check and the atomic update.
Are you suggesting to use locking here ? I couldnt find a test-and-set
alternative in glib2. Does qemu have access to any such interface ?
+
+/* To check later if threshold crossed */
+rec-next_tbuf_idx = trace_idx % TRACE_BUF_LEN;
+
+rec_off = idx;
+write_to_buffer(rec_off, (uint8_t*)event, sizeof(event));
+rec_off += sizeof(event);
+write_to_buffer(rec_off, (uint8_t*)timestamp_ns, sizeof(timestamp_ns));
+rec_off += sizeof(timestamp_ns);
+write_to_buffer(rec_off, (uint8_t*)rec_len, sizeof(rec_len));
+rec_off += sizeof(rec_len);
This suggests a pattern where write_to_buffer() returns the new index:
rec_off = write_to_buffer(rec_off, (uint8_t*)event, sizeof(event));
That way you don't need to do the separate sizeof() additions.
+
+rec-tbuf_idx = idx;
+rec-rec_off = (idx + ST_REC_HDR_LEN) % TRACE_BUF_LEN;
+return 0;
}
-void trace4(TraceEventID event, uint64_t x1,
Re: [Qemu-devel] [RFC] Proposal: PCI/PCIe: inbound BAR0 emulation for PCI controller (Root Complex)
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Friday, June 08, 2012 4:32 PM To: Bhushan Bharat-R65777 Cc: qemu-devel@nongnu.org; Wood Scott-B07421; Yoder Stuart-B08248 Subject: Re: [RFC] Proposal: PCI/PCIe: inbound BAR0 emulation for PCI controller (Root Complex) On Fri, 2012-06-08 at 09:03 +, Bhushan Bharat-R65777 wrote: Hi All, When Freescale PCI controller configured in Root Complex mode then, its configuration header (type 1) have one inbound BAR (BAR0, called as CCSRBAR). And rest of BARs (inbound and outbound) are supported by ATMU registers, which are outside the Type 1 configuration header. This BAR0 of Type 1 configuration header always translate to CCSR space and is of the size of CCSR. This BAR0 (inbound window) is required for MSI interrupts support. With this window, the pci devices can write to the MPIC MSI registers to generate MSI interrupt. So you should start with giving an overview, nobody here knows what ATMU or CCSR are, those are device specific acronyms ATMU - Address Translation and Mapping Unit :- This facilitate flexibility in defining the address maps for the external interfaces (PCI, Rapidio etc). This basically provides following features: 1. Translating the local address to an external address space 2. Translating external addresses to the local address space CCSR - Configuration, Control, and Status Register (CCSR) Space. This is memory mapped system register space. In PCI/PCIe context this can be visualized as: -|--| Local| |PCI controller (Root Complex)|| Address | | ___| Space|-| |ATMU | | Type 1||--PCI Address Space--- | | |__| | Config Header || | |||| -|--| As a matter of fact it looks like I misunderstood you on IRC :-) IE. I thought your problem was that BAR0 is 'special' as it represents the inbound memory window (as it does on some PPC 4xx for example and a whole other collection of embedded devices). You seem to indicate that it's in fact MMIO: In some SOCs, BAR0 always maps to CCSR (MMIO) while in some new SOCs, the BAR0 default maps to CCSR space while it can be programmed to map system memory in local address space. As far as I know, as of now no emulated PCI controller supports this BAR0 in type 1 configuration header. But probably (I think so) that supporting this is not of big concern, but the point is that this window (BAR0) translate to mmio-regs (CCSR) and not to DDR memory. So the 4xx case or the case where your BAR 0 actually represents system memory are something that is bothering me but not what you are trying to discuss here. IE. Normal BAR operations should work for an MMIO BAR, ie register it normally as a PCIe device and devices accessing those addresses will do the right thing. From there, AFAIK, the MSI code will simply do stl_le_phys, which I -believe- will hit a BAR that does MMIO decoding for those addresses, but I'll let people knowing qemu more in depth reply whether that's true or not. There's very few devices with MSI support in hw/* so it's hard to test with anything other than virtio. Probably testing with virtio should be ok as of now ( to put the framework in place). Thanks -Bharat So I have couple of concerns here: 1. Whenever PCI device does need DMA then these windows (inbound and outbound ATMUs registers) need to used to translate pci address to system physical address (Sometime we also call this as cpu address space). This will probably be done by : [Qemu-devel] [PATCH 00/12] IOMMU Infrastructure : patch-set ( I am trying to understand these patches :-)) Yes, that's basically it. The patches allow you to add a set of routines that will be used for translating DMA accesses to system memory along with map/unmap operations etc... Beware that this only works with drivers that use the proper accessors. The patch series fixes some of them but not everything. I don't know off hand (I don't have the code at hand right now) whether the MSI code goes through that or not, if it does, you may need to be careful to -not- hit the translation layer and pass the accesses on. 2. Hook up this inbound BAR0 in the above patch-set to translate to mmio-regs. As this would be controller specific, a callback will be registered for translation. Now it will be upto the controller specific code on how it translates. As this is needed only for MSI interrupt, maybe, initially we do not do anything initially, till we want MSI emulation in QEMU. Well, virtio can make good use of MSI emulation ... Cheers, Ben. Please provide your comment. Thanks -Bharat
Re: [Qemu-devel] [PATCH 3/4] atapi: implement READ DISC INFORMATION
Am 11.06.2012 07:24, schrieb Paolo Bonzini:
This command is not necessary for CD-ROM and DVD-ROM, but some versions of
udev trip on its absence.
Cc: Kevin Wolf kw...@redhat.com
Cc: Markus Armbruster arm...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
Kevin, ok to merge these ATAPI changes via the SCSI tree?
hw/ide/atapi.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 5919cf5..7510886 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -956,6 +956,36 @@ static void cmd_read_cdvd_capacity(IDEState *s, uint8_t*
buf)
ide_atapi_cmd_reply(s, 8, 8);
}
+static void cmd_read_disc_information(IDEState *s, uint8_t* buf)
+{
+uint8_t type = buf[1] 7;
+uint32_t max_len = ube16_to_cpu(buf + 7);
+
+/* Types 1/2 are only defined for Blu-Ray. */
+if (type != 0) {
+ide_atapi_cmd_error(s, ILLEGAL_REQUEST,
+ASC_INV_FIELD_IN_CMD_PACKET);
+return;
+}
+
+memset(buf, 0, 34);
+buf[1] = 32;
+buf[2] = 0xe; /* last session complete, disc finalized */
+buf[3] = 1; /* first track on disc */
+buf[4] = 1; /* # of sessions */
+buf[5] = 1; /* first track of last session */
+buf[6] = 1; /* last track of last session */
+buf[7] = 0x20; /* unrestricted use */
+buf[8] = 0x00; /* CD-ROM or DVD-ROM */
+/* 9-10-11: most significant byte corresponding bytes 4-5-6 */
+/* 12-23: not meaningful for CD-ROM or DVD-ROM */
+/* 24-31: disc bar code */
+/* 32: disc application code */
+/* 33: number of OPC tables */
+
+ide_atapi_cmd_reply(s, 34, max_len);
+}
Looks correct to me.
+
static void cmd_read_dvd_structure(IDEState *s, uint8_t* buf)
{
int max_len;
@@ -1048,6 +1078,7 @@ static const struct {
[ 0x5a ] = { cmd_mode_sense, /* (10) */ 0 },
[ 0xa8 ] = { cmd_read, /* (12) */ CHECK_READY },
[ 0xad ] = { cmd_read_dvd_structure,CHECK_READY },
+[ 0x51 ] = { cmd_read_disc_information, CHECK_READY },
[ 0xbb ] = { cmd_set_speed, 0 },
[ 0xbd ] = { cmd_mechanism_status, 0 },
[ 0xbe ] = { cmd_read_cd, CHECK_READY },
Please keep the table sorted.
Also, if I was the SCSI maintainer, I would require qtest cases for all
four patches. ;-)
Kevin
Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support
Am 11.06.2012 14:09, schrieb Stefan Hajnoczi: On Fri, Jun 8, 2012 at 6:46 PM, Jeff Cody jc...@redhat.com wrote: On 06/08/2012 12:11 PM, Kevin Wolf wrote: Am 08.06.2012 16:32, schrieb Jeff Cody: On 06/08/2012 09:53 AM, Stefan Hajnoczi wrote: On Fri, Jun 8, 2012 at 2:19 PM, Jeff Cody jc...@redhat.com wrote: On 06/08/2012 08:42 AM, Stefan Hajnoczi wrote: Let's figure out how to specify block-commit so we're all happy, that way we can avoid duplicating work. Any comments on my notes above? I think we are almost completely on the same page - devil is in the details, of course (for instance, on how to convert the destination base from r/o to r/w). Great. The atomic r/o - r/w transition and the commit coroutine can be implemented on in parallel. Are you happy to implement the atomic r/o - r/w transition since you wrote bdrv_append()? Then Zhi Hui can assume that part already works and focus on implementing the commit coroutine in the meantime. I'm just suggesting a way to split up the work, please let me know if you think this is good. I am happy to do it that way. I'll shift my focus to the atomic image reopen in r/w mode. I'll go ahead and post my diagrams and other info for block-commit on the wiki, because I don't think it conflicts with we discussed above (although I will modify my diagrams to not show commit from the top-level image). Of course, feel free to change it as necessary. I may have mentioned it before, but just in case: I think Supriya's bdrv_reopen() patches are a good starting point. I don't know why they were never completed, but I think we all agreed on the general design, so it should be possible to pick that up. Though if you have already started with your own work on it, Jeff, I expect that it won't be much different because it's basically the same transactional approach that you know and that we already used for group snapshots. I will definitely use parts of Supriya's as it makes sense - what I started work on is similar to bdrv_append() and the current transaction approach, so there will be plenty in common to reuse, even with some differences. I have CCed Supriya who has been working on the reopen patch series. She is close to posting a new version. It's just a bit disappointing that it takes several months between each two versions of the patch series. We'd like to have this in qemu 1.2, not only in qemu 1.14. I can understand if someone can't find the time, but then allow at least someone else to pick it up. Kevin
Re: [Qemu-devel] [PATCH 3/4] atapi: implement READ DISC INFORMATION
Il 11/06/2012 14:44, Kevin Wolf ha scritto:
@@ -1048,6 +1078,7 @@ static const struct {
[ 0x5a ] = { cmd_mode_sense, /* (10) */ 0 },
[ 0xa8 ] = { cmd_read, /* (12) */ CHECK_READY },
[ 0xad ] = { cmd_read_dvd_structure,CHECK_READY },
+[ 0x51 ] = { cmd_read_disc_information, CHECK_READY },
[ 0xbb ] = { cmd_set_speed, 0 },
[ 0xbd ] = { cmd_mechanism_status, 0 },
[ 0xbe ] = { cmd_read_cd, CHECK_READY },
Please keep the table sorted.
Also, if I was the SCSI maintainer, I would require qtest cases for all
four patches. ;-)
Me too. However, I'm waiting for Stefan to resubmit his virtio bindings
for qtest.
Paolo
Re: [Qemu-devel] [RFC] QOMification of AXI stream
On 11 June 2012 06:54, Paolo Bonzini pbonz...@redhat.com wrote: I think AXI counts as a point-to-point link, so no bus. Depends what you mean by AXI. In general an AXI bus fabric can have multiple masters and slaves connected via an interconnect, but we probably don't actually want to model the interconnect as a separate device... -- PMM
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 11 June 2012 08:13, Andreas Färber afaer...@suse.de wrote: Am 05.06.2012 12:00, schrieb Peter Maydell: I don't think this is a fantastic idea -- the device struct should be private to the device, and having it in a standalone header file is asking for users of the device to illicitly include it and access internals that they shouldn't. But that is exactly where realize is headed. PCIBus, a9mp_priv etc. structs will need to be made public so that they can be embedded. I think that's a bad thing -- our object model shouldn't require all that stuff to be publicly visible. Qdev/sysbus doesn't need it to be publicly visible at the moment, and we shouldn't go backwards. -- PMM
Re: [Qemu-devel] [PATCH 5/6] fdc: use LOG_UNIMP logging
Am 09.06.2012 14:12, schrieb Blue Swirl: Convert uses of FLOPPY_ERROR to either FLOPPY_DPRINTF (for implemented cases) or to use LOG_UNIMP (unimplemented). Signed-off-by: Blue Swirl blauwir...@gmail.com Acked-by: Kevin Wolf kw...@redhat.com
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/11/2012 02:20 AM, Paolo Bonzini wrote: Il 11/06/2012 09:13, Andreas Färber ha scritto: +The first step is to move your device struct definition to a header file. This +header file should only contain the struct definition and any preprocessor +declarations you need to define the structure. This header file will act as +the source for the QC IDL compiler. I don't think this is a fantastic idea -- the device struct should be private to the device, and having it in a standalone header file is asking for users of the device to illicitly include it and access internals that they shouldn't. But that is exactly where realize is headed. PCIBus, a9mp_priv etc. structs will need to be made public so that they can be embedded. I thought that was just a convenience choice, not a necessity. The children objects could just as well be heap-allocated. Objects need some sort of type signature publicly. The question is whether that's a forward reference, a structure using PIMPL, or the full blown structure. I really don't see the overwhelming need to keep structures private. Being able to directly reference public members is extremely handy. I'd rather we focus on modeling more devices in a proper fashion such that we better understand their interactions and then make a decision about whether devices ought to be fully private or not. Regards, Anthony Liguori Paolo
Re: [Qemu-devel] [RFC] QOMification of AXI stream
On 06/08/2012 08:24 PM, Peter Crosthwaite wrote:
On Sat, Jun 9, 2012 at 12:15 AM, Anthony Liguorianth...@codemonkey.ws wrote:
On 06/08/2012 12:23 PM, Peter Crosthwaite wrote:
Hi all,
Im looking to QOMifying and refactoring the AXI stream interfaces
between the AXI ethernet and AXI DMA modules. I could use some
guidance on how to do this as I can think of about 6 different
solutions. Sources are hw/xilinx_axienet.c and hw/xilinx_axidma.c.
First ill start off by describing the real hardware:
Each of the two core has three interfaces (+interrupt pins):
1: Sysbus attachment for device control
2: AXI stream TX link
3: AXI stream RX link
Ethernet packet data is transferred from the ethernet device to/from
memory via the AXI stream links and the DMA core. Basically the DMA
core can be summed up as simply taking data to/from memory and putting
to/from the axi stream links. Axi stream is a trival point to point
protocol that allows for pushing 32-bit data words at a time.
From an architecture point of view, the TX and RX links are completely
independent of each other. It doesnt make a lot of sense to have tx or
rx without the other for the ethernet with DMA case, but other
applications of the DMA could use only one of tx and rx. For this
reason I think its best we decouple the tx/rx pair. Currently it is
coupled in qemu (hw/xilinx_axdma.h):
So is this something that should be modeled as a DMAContext ala dwg/benh's
IOMMU patch series?
Wouldn't the DMA controller expose two or more DMAContextes and then the
Ethernet device expects a DMAContext for tx and rx.
Hi Anthony,
This doesn't sound right to me at all WRT to modelling the real
hardware. The ethernet controller on its own has no notion that it is
attached to a DMA controller. I can attached the device to any
AXI-stream tx/rx pair. The ethernet device should only has awareness
of the axi stream protocol and have no exposure to any DMA related
functionality.
What is the AXI stream protocol?
From what you said earlier, it's basically:
'write data to this address'
'read data from this address'
An interface that implements this is DMAContext. Forget about the fact that
'DMA' is in the name. It's really the symmetric version of a MemoryRegion.
Heres the (futuristic) example im worried about:
I have my ethernet controller attached to the DMA as usual over the
axi-stream pairs. I then come along and decide I want to model some
hardware packet filter device on the ethernet traffic inbetween the
memory and ethernet. My packet filter is implemented as a axi-stream
master and slave (basically a filtering fifo). I need to on the
machine model level, insert it on the rx path. Heres the architecture:
Ethernet - axistream - Random packet filter IP - axistream - DMA
Ethernet- axistream- DMA
In this case the ethernet is insulated from DMA. I think i can
summarize in saying that assuming that an axi-stream link is for DMA
is incorrect.
So first thing you need to do is figure out what the stream interface consists
of. You can model this as an Interface or use an existing Interface (like
DMAContext). You can then expose a pair of these interfaces from the controller
using a child object (as Paul likes to say, a proxy object). This is how
MemoryRegions and DMAContexts work.
Regards,
Anthony Liguori
Regards,
Peter
Of course, DMAContext could be made trivially into an Object and tx/rx could
be turned into link properties.
Regards,
Anthony Liguori
struct XilinxDMAConnection {
void *dma;
void *client;
DMAPushFn to_dma;
DMAPushFn to_client;
};
So what im proposing is AXI stream is implemented as a unidirectional
point to point bus. The xilinx ethernet system would consist of two of
these buses one for tx, one for rx.
Onto the QOM stuff:
Currently the DMA interconnect is handled as this struct I pasted
above and a QDEV_PROP_PTR (which i understand is evil). The
interconnect mechanism obviously needs to change. So lets assume that
AXI stream is turned into a proper QEMU bus and devices can create
sub-busses which they are the tx'ing master:
s-axi_stream_master = axi_stream_create_bus(dev-qdev, axi_stream);
Machine models can grab the bus to attach slaves:
foo = qdev_get_child_bus(dev, axi_stream);
Where my thinking goes pear shaped though is having proper QOMified
slaves. Each IP is a slave to both the sysbus and their respective
rx'ing AXI stream bus. This is something of a multiple inheritance
problem, I cant inherit from both SYSBUS and AXI_STREAM_SLAVE. So to
overcome this should I ...
A: Make AXI_STREAM_SLAVE an interface (not a sub-class of DEVICE). Its
kind of annoying though if someone in the future whats the create a
device thats only and axi stream slave, as they would have to
explicitly inherit from DEVICE as well.
or
B: Have the slave attachment be a device within a device. Hard part is
getting an accessor so machine models can retrieve the slave
attachment and hook it up.
Let me
Re: [Qemu-devel] [RFC] QOMification of AXI stream
On 06/11/2012 12:54 AM, Paolo Bonzini wrote: Ive had a brief look at the refactorings on qom-next, I notice that busses are now just children of the parent object TYPE_BUS. Essentially for point-to-point links this means that link itself has a QOM object. So for finer clarification, for new busses should or should I not have an object (whether it inherit TYPE_BUS or some other parent) for the link itself? Or should The master device interface directly with its slave? Im thinking the latter, no need for an object for a trivial point-to-point link. I think AXI counts as a point-to-point link, so no bus. In my prop-ptr branch you can find some code (untested beyond compilation) that tried to model AXI using interfaces (git://github.com/pbonzini/qemu.git). s/pbonzini/bonzini/g, right? And I don't see a prop-ptr branch. Did you forget to push? Regards, Anthony Liguori I don't know much about AXI, so I tried to reverse engineer a decent model from what was done without QOM. Paolo
Re: [Qemu-devel] [PATCH qom-next 1/7] qdev: Push state up to Object
On 06/11/2012 03:25 AM, Kevin Wolf wrote:
Am 10.06.2012 19:38, schrieb Andreas Färber:
Am 10.06.2012 17:49, schrieb Paolo Bonzini:
Il 08/06/2012 03:19, Anthony Liguori ha scritto:
+typedef enum ObjectState {
+OBJECT_STATE_INITIALIZED = 1,
+OBJECT_STATE_REALIZED,
+} ObjectState;
I think using a bool would be better since it reduces the temptation to
add additional states.
In fact someone already discussed having a third state for block
devices... :)
I would expect that file_opened state to remain internal to the block
layer. Thought we discussed that on IRC?
I think I still don't understand well enough what 'realized' is really
supposed to mean.
realized is essentially the Vcc pin for the device.
When realized = true, it means power has been applied to the device (and the
guest potentially is interacting with it).
When realized = false, it means that power is not applied to the device and the
guest is not running.
Does some magic happen when an object gets realised? From outside,
what's the difference between an INITIALIZED and a REALIZED object? Is
it more or less an implementation detail of the base class or is it
something that affects the object model itself?
On the rising edge of realized, you typically will validate any parameters and
do any actions necessary based on the parameters. As long as the guest isn't
running, we want the ability to make changes to the devices that we normally
couldn't change while the guest is running (like updating the CharDriverState
pointer).
I think the file_opened state should have more or less the same status
as the realisation of an object. They are quite similar, so they should
both be an implementation detail of their respective class, or they
should both be baked into the object model.
I think we need to think about what realized means to a non-Device. Does
file_opened have the same logical semantics as the above?
A comment in this patch says it means that an object is fully
constructed.
That's not really the best wording. See above.
Regards,
Anthony Liguori
So if we add a file_opened state in the block layer, in
order to keep this consistent, it would have to be a state that comes
between INITIALIZED and REALIZED.
Where would we have checks, for example whether the image that you
assign to a block device is really opened? Would QOM commands to create
a link only link to already realised objects? Would each single block
device have to check this during its own realisation phase? Would we
check object_is_realized() or rather bdrv_file_is_opened()? If the
latter, it can't be generic monitor code that checks it.
Let's start with this, I'm sure I'll have more questions...
Kevin
Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On Tue, Jun 05, 2012 at 03:46:31PM +0530, Amit Shah wrote:
On (Tue) 05 Jun 2012 [17:54:30], Anthony Liguori wrote:
On 06/05/2012 05:41 PM, Amit Shah wrote:
On (Mon) 04 Jun 2012 [19:04:41], Anthony Liguori wrote:
On 05/26/2012 04:20 AM, Amit Shah wrote:
On (Fri) 25 May 2012 [15:00:53], Anthony Liguori wrote:
On 05/25/2012 02:32 PM, Amit Shah wrote:
The Linux kernel already has a virtio-rng driver, this is the device
implementation.
When the guest asks for entropy from the virtio hwrng, it puts a buffer
in the vq. We then put entropy into that buffer, and push it back to
the guest.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo/dev/urandom
A QMP event is sent for interested apps to monitor activity and send
the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
I don't understand the point of this event. Can't a management app
just create a socket and then it can see all the requests the guest
makes?
How? With the chardev, it can only keep feeding data, and that data
will be consumed when chr_can_read() returns 0. And even then the
mgmt app has no idea how much data was asked for, and how much was
consumed.
Okay, then the right approach is to use a message protocol where
QEMU asks for a certain amount of data and then the daemon sends it
back.
Why is a message protocol necessary? And a daemon isn't necessary,
too.
I think this is pretty much why the egd protocol exists, no? Why
not just implement egd protocol support?
Perhaps I'm not getting what you're saying.
What we have here, via the event, is to tell the mgmt app that the
guest has need for entropy.
*out-of-band*
Why not just make that all in-band?
I understand you're trying to accomodate a use-case of feeding
/dev/random to QEMU. I don't think this is a necessary use-case
though because I don't think it's correct. You need to use an
entropy daemon of some sort to make sure entropy is being
distributed in a fair fashion.
In my view, qemu doesn't operate at a system-level where it can see
how system entropy is being used.
libvirt does operate at that level.
For casual development, I don't want to have egd on my system to feed
in entropy to the guest, and I don't need to know how to configure
egd and then provide its output to qemu.
libvirt can do that for me. But for development, I'd just want to be
able to do something like
qemu -chardev socket,path=/tmp/foo,id=foo,server,nowait \
-device virtio-rng,chardev=foo
and then just feed in some data to /tmp/foo.
I tend to agree, while the EGD wire protocol may be useful if you
are wanting to connect QEMU to EGD, for apps that are just directly
mnanaging QEMU it imposes a unnecessary burden on apps, to learn
a new protocol in addition to their existing knowledge of QMP.
In addition, I don't think implementing the EGD protocol is mutually
exclusive with raw QEMU chardevs. eg enablement of an EGD protocol on
the chardev could reasonably be done as an optional feature ontop of
the raw chardev, in the same way that chardevs can be made to optionally
run the telnet line discipline.
I'd like to see us have the raw chardev impl + QMP event as a first
step, and then add EGD protocol on top of that (if desired) as a
second step.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 11 June 2012 14:12, Anthony Liguori aligu...@us.ibm.com wrote: I really don't see the overwhelming need to keep structures private. Being able to directly reference public members is extremely handy. It keeps people honest. Last time I looked at your pin series it had some changes which were using private info they shouldn't be, IIRC. -- PMM
[Qemu-devel] [PULL] kvm updates
Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master to fix a bug in kvm PIT time synchronization and a bug in kvm apic reset. Jan Kiszka (1): kvm: i8254: Fix conversion of in-kernel to userspace state Jim Meyering (1): kvm/apic: correct short memset hw/kvm/apic.c |2 +- hw/kvm/i8254.c | 57 - -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [RFC] QOMification of AXI stream
On 11 June 2012 14:15, Anthony Liguori aligu...@us.ibm.com wrote: From what you said earlier, it's basically: 'write data to this address' 'read data from this address' An interface that implements this is DMAContext. Forget about the fact that 'DMA' is in the name. It's really the symmetric version of a MemoryRegion. ...so can we fix the name? Ideally the interface used by DMA controllers should be identical to the interface used by CPUs to talk to the rest of the system: it's exactly the same bus interface in hardware, after all. -- PMM
Re: [Qemu-devel] [RFC] QOMification of AXI stream
Il 11/06/2012 15:17, Anthony Liguori ha scritto: I think AXI counts as a point-to-point link, so no bus. In my prop-ptr branch you can find some code (untested beyond compilation) that tried to model AXI using interfaces (git://github.com/pbonzini/qemu.git). s/pbonzini/bonzini/g, right? Yes. And I don't see a prop-ptr branch. Did you forget to push? git push says Everything up-to-date, and github web interface agrees: https://github.com/bonzini/qemu/commits/prop-ptr Paolo
Re: [Qemu-devel] [PATCH v4 0/7] trace: Generic event state description
Stefan Hajnoczi writes: On Mon, Jun 11, 2012 at 12:12 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Stefan Hajnoczi writes: On Tue, May 8, 2012 at 3:38 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Provides a generic event state description and a more detailed event control and query interface. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- [...] What is the point of sstate vs dstate? It seems the dynamic state is what can be toggled and sstate is the disable keyword. Why have sstate since there is already a macro? 'sstate' is there just in case you query the tracing state of an event through the 'TraceEvent' structure instead of through the corresponding macro. If this is not used by a tracer today we should hold off until it's needed. I double-checked the code for uses of that and it appears to be there just for the sake of completeness. Still, I realized I should have added a check in 'trace_event_set_state_dynamic' and assert that the event is statically enabled (otherwise dynamically enabling an event that is statically disabled just does not make sense). Whatever you prefer, although the code is pretty simple. Lluis -- And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer. -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
[Qemu-devel] Live Migration of a large guest : guest frozen on the destination host
Hello, 'am having some issues trying to live migrate a large guest and would like to get some pointers on how to go about about debugging this. Here is some info. on the configuration _Hardware :_ Two DL980's each with 80 Westmere cores + 1 TB of RAM. Using a 10G NIC private link (back to back) between two DL980's _ Host software used:_ Host 3.4.1 kernel Qemu versions used : Case 1: upstream qemu (1.1.50) - from qemu.git Case 2 : 1.0.92 + Juan Quintela's huge_memory changes _ Guest : _40VCPUs + 512GB _Guest software used:_ RHEL6.3 RC1 (had some basic boot issues with 3.4.1 kernel and udevd..) Guest is booted off an FC LUN (visible to both the hosts). [Note: 'am not using virsh/virt-manager etc. but just the qemu to start the guest and also interact with the qemu monitor for live migration etc. Have set the migration speed to 10G but haven't changed the downtime (default : 30ms) ] Tried to live migrate this large guest..using either of the qemu's (i.e. Case 1 or Case2) and observed the following : When this guest was Idling 'was able to live migrate and have the guest come up fine on the other host. Was able to interact with the guest on the destination host. With workloads (e.g. AIM7-compute or SpecJBB or Google Stress App Test (SAT)) running in the guest if we tried to do live migration.. we observe that [after a while] the source host claims that the live migration is complete...but the guest on the destination host is often in a frozen/hung state.. can't really interact with it or ping it. Still trying to capture more information...but was also hoping to get some clues/tips from the experts on these mailing lists... [ BTW, is there a way to get a snap shot of the image of the guest on the source host just before the downtime (i.e. start of stage 3) on the source host and compare that with the image of the guest on the destination host just before its about to resume ? Is such a debugging feature already available ? ] Thanks Vinod
Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
On Mon, Jun 11, 2012 at 2:28 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 09/06/2012 05:04, Zhi Yong Wu ha scritto: This commit looks suspicious because it removes a user-visible qdev property but we're trying to preserve backward compatibility. This command-line will break: x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device virtio-net-pci,vlan=1 Instead of dropping the qdev_prop_vlan completely the hw/qdev-properties.c code needs to call net/hub.h external functions to implement equivalent functionality: 1. Setting the vlan=id property looks up the hub port and assigns the NICConf-peer field. 2. Getting the vlan property looks up the hub id (i.e. vlan id) given the peer. If the peer is not a hub port the result is -1. When I wrote this patch I missed the big picture and forgot about backwards compatibility :(. To be honest, i am concerned if anyone uses this syntax. Since the feature will finally be discarded, i suggest that we don't support this now. If someone complains this later, we can fix it. If nobody complains, that is what we hope. I think you're missing the big picture of this series, which is exactly _not_ to discard the VLAN feature, but just to rewrite it in a better way. Yeah, i know that this series are rewriting VLAN feature in one better way. What i mean was that luiz and other some guys think that the -net syntax should be completely removed. That said, I agree that this is a somewhat fringe usage; most people will use -net nic,model=virtio,vlan=1 rather than -device. We may get Yes. by with dropping it. I have no strong opinion either way. Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support
On Mon, Jun 11, 2012 at 1:50 PM, Kevin Wolf kw...@redhat.com wrote: Am 11.06.2012 14:09, schrieb Stefan Hajnoczi: On Fri, Jun 8, 2012 at 6:46 PM, Jeff Cody jc...@redhat.com wrote: On 06/08/2012 12:11 PM, Kevin Wolf wrote: Am 08.06.2012 16:32, schrieb Jeff Cody: On 06/08/2012 09:53 AM, Stefan Hajnoczi wrote: On Fri, Jun 8, 2012 at 2:19 PM, Jeff Cody jc...@redhat.com wrote: On 06/08/2012 08:42 AM, Stefan Hajnoczi wrote: Let's figure out how to specify block-commit so we're all happy, that way we can avoid duplicating work. Any comments on my notes above? I think we are almost completely on the same page - devil is in the details, of course (for instance, on how to convert the destination base from r/o to r/w). Great. The atomic r/o - r/w transition and the commit coroutine can be implemented on in parallel. Are you happy to implement the atomic r/o - r/w transition since you wrote bdrv_append()? Then Zhi Hui can assume that part already works and focus on implementing the commit coroutine in the meantime. I'm just suggesting a way to split up the work, please let me know if you think this is good. I am happy to do it that way. I'll shift my focus to the atomic image reopen in r/w mode. I'll go ahead and post my diagrams and other info for block-commit on the wiki, because I don't think it conflicts with we discussed above (although I will modify my diagrams to not show commit from the top-level image). Of course, feel free to change it as necessary. I may have mentioned it before, but just in case: I think Supriya's bdrv_reopen() patches are a good starting point. I don't know why they were never completed, but I think we all agreed on the general design, so it should be possible to pick that up. Though if you have already started with your own work on it, Jeff, I expect that it won't be much different because it's basically the same transactional approach that you know and that we already used for group snapshots. I will definitely use parts of Supriya's as it makes sense - what I started work on is similar to bdrv_append() and the current transaction approach, so there will be plenty in common to reuse, even with some differences. I have CCed Supriya who has been working on the reopen patch series. She is close to posting a new version. It's just a bit disappointing that it takes several months between each two versions of the patch series. We'd like to have this in qemu 1.2, not only in qemu 1.14. I can understand if someone can't find the time, but then allow at least someone else to pick it up. Hey, don't shoot the messenger :). I just wanted add Supriya to CC so she can join the discussion and see how much overlap there is with what she's doing. We all contribute to QEMU from different angles and with different priorities. If there is a time critical dependency on the reopen code then discuss it here and the result will be that someone officially drives the feature on. Stefan
Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
On Mon, Jun 11, 2012 at 4:57 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Mon, Jun 11, 2012 at 08:28:57AM +0200, Paolo Bonzini wrote: Il 09/06/2012 05:04, Zhi Yong Wu ha scritto: This commit looks suspicious because it removes a user-visible qdev property but we're trying to preserve backward compatibility. This command-line will break: x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device virtio-net-pci,vlan=1 Instead of dropping the qdev_prop_vlan completely the hw/qdev-properties.c code needs to call net/hub.h external functions to implement equivalent functionality: 1. Setting the vlan=id property looks up the hub port and assigns the NICConf-peer field. 2. Getting the vlan property looks up the hub id (i.e. vlan id) given the peer. If the peer is not a hub port the result is -1. When I wrote this patch I missed the big picture and forgot about backwards compatibility :(. To be honest, i am concerned if anyone uses this syntax. Since the feature will finally be discarded, i suggest that we don't support this now. If someone complains this later, we can fix it. If nobody complains, that is what we hope. I think you're missing the big picture of this series, which is exactly _not_ to discard the VLAN feature, but just to rewrite it in a better way. That said, I agree that this is a somewhat fringe usage; most people will use -net nic,model=virtio,vlan=1 rather than -device. We may get by with dropping it. I have no strong opinion either way. Either we keep backwards compatibility or we don't. Taking a middle path where we preserve only some of the VLAN syntax is confusing and inconsistent. in terms of technology, i fully agree with you, but in terms of usefulness and our business, it will waste our effort, time and is meaningless if nobody or no customers use this syntax. As i said, if someone complain this later, we can fix it. Like Paolo said, the point here is not to drop VLAN support. We're simply moving this feature into a regular net client (the hub) so that the special case VLAN code in net.c can be removed. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4 0/7] trace: Generic event state description
On Mon, Jun 11, 2012 at 2:52 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Stefan Hajnoczi writes: On Mon, Jun 11, 2012 at 12:12 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Stefan Hajnoczi writes: On Tue, May 8, 2012 at 3:38 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Provides a generic event state description and a more detailed event control and query interface. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- [...] What is the point of sstate vs dstate? It seems the dynamic state is what can be toggled and sstate is the disable keyword. Why have sstate since there is already a macro? 'sstate' is there just in case you query the tracing state of an event through the 'TraceEvent' structure instead of through the corresponding macro. If this is not used by a tracer today we should hold off until it's needed. I double-checked the code for uses of that and it appears to be there just for the sake of completeness. Still, I realized I should have added a check in 'trace_event_set_state_dynamic' and assert that the event is statically enabled (otherwise dynamically enabling an event that is statically disabled just does not make sense). Whatever you prefer, although the code is pretty simple. I'd like to avoid adding things that are unused - even if they are small. Stefan
Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode
I was beached, sorry for the late reply. On Thu, 7 Jun 2012, Alexander Graf wrote: On 07.06.2012, at 05:10, Anthony Liguori wrote: On 06/07/2012 06:56 AM, Paul Moore wrote: On Wednesday, June 06, 2012 01:56:52 AM Alexander Graf wrote: The other one (FIPS) is basically a list of encryption algorithms that are deemed OK and not crackable within seconds by anyone. Only one of the 2 doesn't help much. In combination they actually enhance security. This patch is only about FIPS though. I don't have much to add beyond what Alex already posted. FIPS 140-2 outlines a set of security requirements for systems implementing cryptography in a variety of forms; the full requirements are likely beyond the scope here but you can always read the full specification (Google knows where to find the document). The relevant portion appears to be annex A which lists the approved ciphers and their approved uses; DES is not listed as an approved cipher and that is the main problem we are trying to solve right now. But does FIPS mandate that it's impossible for a user to use an unapproved cipher? IOW, is just having this feature implemented at the libvirt level good enough to satisfy FIPS? Do we really need to do this in QEMU? What would implementing it in libvirt buy us? That only stacks using libvirt can be FIPS certified? That any time a management stack that does not use libvirt they need to duplicate that code to be FIPS certified? I would rather have the FIPS certified stamp on QEMU than on libvirt ;). The same way you would usually certify openssl and any user of it (usually) inherits the certification. So by having QEMU FIPS certified, we could reasonably assume libvirt to be FIPS certified. And Ganesi (or whatever it's called). And other stacks that don't go through libvirt hell. Just to add some small bits and pieces about FIPS-140-2 that may turn out to be useful, and clear up some misunderstandings. It is a crypto certification, which has not much to do with security, but rather with making sure that the algorythms used are implemented in such way that they produce testable results. FIPS defines a so-called module, which is a region of code in a program, library or whatever that contains the cryptographic routines. The software must make use of these cryptographic routines exclusively in order to be able to make a claim about FIPS compliance - or something similar. You'd want to minimize the code contained in the crypto boundary to be able to reduce the testing work for FIPS, but still have sufficient functionality. About such claims: There is a distinction between * The software makes use of a library that is FIPS-140-2 certified. * The software is FIPS-140-2 certified. There may be someone who is willing to pay for a FIPS-140-2 validation of qemu, but this is very unlikely. The weaker claim, makes use of FIPS-140-2 certified crypto is enough for most cases. About enforcement of algo use: FIPS-140-2 has four levels, of which 3 and 4 can only be achieved by hardware implementations (smartcards, crypto coprocessors, ...), 1 and 2 also by software. Level 1 says that the solution must only use approved algorythms, but there is no requirement about enforcing this. Level 2 requires enforcement. As a consequence, for qemu to be able to run with a crypto library that is FIPS-140-2 certified, it should be aware of the FIPS mode if there is any, and refrain from initializing cryptography that is not allowable (crypt(3) aka DES, but also MD5 (is a no-go)). In addition to that, qemu must not have any own algorythm implementations (convenient...). Alex Thanks, Roman.
[Qemu-devel] [RFC PATCH 1/3] qemu: Add a config option for GlusterFS as block backend
qemu: Add a config option for GlusterFS as block backend
From: Bharata B Rao bhar...@linux.vnet.ibm.com
Signed-off-by: Bharata B Rao bhar...@linux.vnet.ibm.com
---
configure | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index b55a792..dc89592 100755
--- a/configure
+++ b/configure
@@ -824,6 +824,10 @@ for opt do
;;
--disable-guest-agent) guest_agent=no
;;
+ --disable-glusterfs) glusterfs=no
+ ;;
+ --enable-glusterfs) glusterfs=yes
+ ;;
*) echo ERROR: unknown option $opt; show_help=yes
;;
esac
@@ -1110,6 +1114,8 @@ echo --disable-guest-agentdisable building of the
QEMU Guest Agent
echo --enable-guest-agent enable building of the QEMU Guest Agent
echo --with-coroutine=BACKEND coroutine backend. Supported options:
echogthread, ucontext, sigaltstack, windows
+echo --enable-glusterfs enable GlusterFS backend
+echo --disable-glusterfs disable GlusterFS backend
echo
echo NOTE: The object files are built at the place where configure is
launched
exit 1
@@ -2240,6 +2246,31 @@ EOF
fi
fi
+##
+# glusterfs probe
+if test $glusterfs != no ; then
+ cat $TMPC EOF
+#include stdio.h
+#include glusterfs/xlator.h
+int main(void) {
+xlator_t xlator;
+xlator_init(xlator);
+return 0;
+}
+EOF
+ glusterfs_libs=-lglusterfs
+ if compile_prog $glusterfs_libs ; then
+glusterfs=yes
+libs_tools=$glusterfs_libs $libs_tools
+libs_softmmu=$glusterfs_libs $libs_softmmu
+ else
+if test $glusterfs = yes ; then
+ feature_not_found GlusterFS backend support
+fi
+glusterfs=no
+ fi
+fi
+
#
# Check for xxxat() functions when we are building linux-user
# emulator. This is done because older glibc versions don't
@@ -3014,6 +3045,7 @@ echo OpenGL support$opengl
echo libiscsi support $libiscsi
echo build guest agent $guest_agent
echo coroutine backend $coroutine_backend
+echo GlusterFS support $glusterfs
if test $sdl_too_old = yes; then
echo - Your SDL version is too old - please upgrade to have SDL support
@@ -3342,6 +3374,10 @@ if test $linux_magic_h = yes ; then
echo CONFIG_LINUX_MAGIC_H=y $config_host_mak
fi
+if test $glusterfs = yes ; then
+ echo CONFIG_GLUSTERFS=y $config_host_mak
+fi
+
# USB host support
case $usb in
linux)
[Qemu-devel] [RFC PATCH 0/3] GlusterFS support in QEMU
Hi, This set of patches enables QEMU to boot VM images from gluster volumes. This is achieved by adding gluster as a new block backend driver in QEMU. Its already possible to boot from VM images on gluster volumes using Fuse mount, but this patchset provides the ability to boot VM images from gluster volumes by by-passing the FUSE layer in gluster. In case the image is present on the local system, it is possible to even bypass client and server translator and hence the RPC overhead. QEMU with gluster backend support will take the volume file on command line and then link to libglusterfs library to perform IO to image on gluster volume. block/gluster-helpers.c has bare minimum gluster code that is necessary for QEMU to boot and work with image on gluster volume. I have implemented routines like gluster_create, gluster_open, gluster_aio_readv etc which will eventually not be necessary when we have equivalent routines in libglusterfsclient working. While I have this implementation here, we are also working actively on resurrecting libglusterfsclient and using QEMU with it. In addition to posix routines, block/gluster-helpers.c has some elaborate lookup code which also will become redundant with libglusterfsclient. The patches are experimental in nature and I have only verified that I can boot an image from gluster volume using these patches in fuse-bypass and rpc-bypass modes. I haven't tested with full-blown version of volume file (that is generated by gluster CLI), but have always use only hand crafted volume files with just posix translator in it. How to use this patchset 1. Compiling GlusterFS - Get GlusterFS source from git://git.gluster.com/glusterfs.git - Compile and install # ./autogen.sh; ./configure; make; make install - Copy a few required header files and libraries # mkdir /usr/local/include/glusterfs/ # cp glusterfs/libglusterfs/src/*.h /usr/local/include/glusterfs/ # cp glusterfs/config.h /usr/local/include/glusterfs/ # cp glusterfs/contrib/uuid/uuid.h /usr/local/include/glusterfs/ 2. Compiling QEMU - Get QEMU sources - Apply the patches from this patchset. - Configure # ./configure --disable-werror --target-list=x86_64-softmmu --enable-glusterfs --enable-uuid - make; make install Note: I have to resort to --disable-werror to mainly tide over the warnings in block/gluster-helpers.c. I didn't spent too much effort in cleaning this up since this code will be gone once we have a working libglusterfsclient. 3. Starting GlusterFS server # glusterfsd -f s-qemu.vol # cat s-qemu.vol volume vm type storage/posix option directory /vm end-volume volume server type protocol/server subvolumes vm option transport-type tcp option auth.addr.vm.allow * end-volume Here /vm is the directory exported by the server. Ensure that this directory is present before GlusterFS server is started. 4. Creating VM image # qemu-img create -f gluster gluster:c-qemu.vol:/F16 5G # cat c-qemu.vol volume client type protocol/client option transport-type tcp option remote-host bharata option remote-subvolume vm end-volume 5. Install a distro (say Fedora16) on the VM image # qemu-system-x86_64 --enable-kvm -smp 4 -m 1024 -drive file=gluster:c-qemu.vol:/F16,format=gluster -cdrom Fedora-16-x86_64-DVD.iso After this follow the normal F16 installation. Next time onwards, the following QEMU command can be used to directly start the VM. 6. Start the VM (Fuse-bypass) # qemu-system-x86_64 --enable-kvm --nographic -smp 4 -m 1024 -drive file=gluster:c-qemu.vol:/F16,format=gluster 6a. Booting VM in RPC-bypass mode. # cat c-qemu-rpcbypass.vol volume vm type storage/posix option directory /vm end-volume # qemu-system-x86_64 --enable-kvm --nographic -smp 4 -m 1024 -drive file=gluster:c-qemu-rpcbypass.vol:/F16,format=gluster Note that in this case, its not necessary to run a gluster server. Tests = I have done some initial tests using fio. Here are the details: Environment --- Dual core x86_64 laptop QEMU (f8687bab919672ccd) GlusterFS (c40b73fc453caf12) Guest: Fedora 16 (kernel 3.1.0-7.fc16.x86_64) Host: Fedora 16 (kernel 3.4) fio-HEAD-47ea504 fio jobfile --- # cat aio-read-direct-seq ; Read 4 files with aio at different depths [global] ioengine=libaio direct=1 rw=read bs=128k size=512m directory=/data1 [file1] iodepth=4 [file2] iodepth=32 [file3] iodepth=8 [file4] iodepth=16 Base QEMU: qemu-system-x86_64 --enable-kvm --nographic -m 1024 -smp 4 -drive file=/vm/dir1/F16,cache=none Fuse mount -- Server: glusterfsd -f s-qemu.vol Client: glusterfs -f c-qemu.vol /mnt QEMU: qemu-system-x86_64 --enable-kvm --nographic -m 1024 -smp 4 -drive file=/mnt/dir1/F16,cache=none Fuse bypass --- Server: glusterfsd -f s-qemu.vol QEMU: qemu-system-x86_64 --enable-kvm --nographic -m 1024 -smp 4 -drive file=gluster:/c-qemu.vol:/dir1/F16,format=gluster,cache=none RPC bypass -- QEMU: qemu-system-x86_64 --enable-kvm
[Qemu-devel] [RFC PATCH 3/3] block: gluster as block backend
block: gluster as block backend
From: Bharata B Rao bhar...@linux.vnet.ibm.com
This patch adds gluster as the new block backend in QEMU. This gives QEMU
the ability to boot VM images from gluster volumes.
Signed-off-by: Bharata B Rao bhar...@linux.vnet.ibm.com
---
Makefile.objs |2
block/gluster.c | 435 +++
2 files changed, 436 insertions(+), 1 deletions(-)
create mode 100644 block/gluster.c
diff --git a/Makefile.objs b/Makefile.objs
index 25190ba..859b88a 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -59,7 +59,7 @@ block-nested-$(CONFIG_POSIX) += raw-posix.o
block-nested-$(CONFIG_LIBISCSI) += iscsi.o
block-nested-$(CONFIG_CURL) += curl.o
block-nested-$(CONFIG_RBD) += rbd.o
-block-nested-$(CONFIG_GLUSTERFS) += gluster-helpers.o
+block-nested-$(CONFIG_GLUSTERFS) += gluster-helpers.o gluster.o
block-obj-y += $(addprefix block/, $(block-nested-y))
diff --git a/block/gluster.c b/block/gluster.c
new file mode 100644
index 000..1566cb7
--- /dev/null
+++ b/block/gluster.c
@@ -0,0 +1,435 @@
+/*
+ * GlusterFS backend for QEMU
+ *
+ * (AIO implementation is derived from block/rbd.c)
+ *
+ * Copyright (C) 2012 Bharata B Rao bhar...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * (at your option) any later version. See the COPYING file in the top-level
+ * directory.
+ */
+#include block_int.h
+#include gluster-helpers.h
+
+typedef void *gluster_file_t;
+
+typedef struct glusterConf {
+char volfile[PATH_MAX];
+char image[PATH_MAX];
+} glusterConf;
+
+typedef struct BDRVGlusterState {
+int fds[2];
+int open_flags;
+gluster_file_t fd;
+glusterfs_ctx_t *ctx;
+int qemu_aio_count;
+int event_reader_pos;
+gluster_aiocb_t *event_gaiocb;
+} BDRVGlusterState;
+
+typedef struct glusterAIOCB {
+BlockDriverAIOCB common;
+QEMUBH *bh;
+QEMUIOVector *qiov;
+int ret;
+int write;
+char *bounce;
+BDRVGlusterState *s;
+int cancelled;
+int error;
+} glusterAIOCB;
+
+#define GLUSTER_FD_READ 0
+#define GLUSTER_FD_WRITE 1
+
+/*
+ * file=protocol:volfile:image
+ */
+static int qemu_gluster_parsename(glusterConf *c, const char *filename)
+{
+char *file = g_strdup(filename);
+char *token, *next_token, *saveptr;
+int ret = 0;
+
+/* Discard the protocol */
+token = strtok_r(file, :, saveptr);
+if (!token) {
+ret = -EINVAL;
+goto out;
+}
+
+/* volfile */
+next_token = strtok_r(NULL, :, saveptr);
+if (!next_token) {
+ret = -EINVAL;
+goto out;
+}
+strncpy(c-volfile, next_token, PATH_MAX);
+
+/* image */
+next_token = strtok_r(NULL, :, saveptr);
+if (!next_token) {
+ret = -EINVAL;
+goto out;
+}
+strncpy(c-image, next_token, PATH_MAX);
+out:
+g_free(file);
+return ret;
+}
+
+static void gluster_aio_bh_cb(void *opaque)
+{
+glusterAIOCB *acb = opaque;
+
+if (!acb-write) {
+qemu_iovec_from_buffer(acb-qiov, acb-bounce, acb-qiov-size);
+}
+qemu_vfree(acb-bounce);
+acb-common.cb(acb-common.opaque, (acb-ret 0 ? 0 : acb-ret));
+qemu_bh_delete(acb-bh);
+acb-bh = NULL;
+
+qemu_aio_release(acb);
+}
+
+static void qemu_gluster_complete_aio(gluster_aiocb_t *gaiocb)
+{
+glusterAIOCB *acb = (glusterAIOCB *)gaiocb-opaque;
+int64_t r;
+
+if (acb-cancelled) {
+qemu_vfree(acb-bounce);
+qemu_aio_release(acb);
+goto done;
+}
+
+r = gaiocb-ret;
+
+if (acb-write) {
+if (r 0) {
+acb-ret = r;
+acb-error = 1;
+} else if (!acb-error) {
+acb-ret = gaiocb-size;
+}
+} else {
+if (r 0) {
+memset(gaiocb-buf, 0, gaiocb-size);
+acb-ret = r;
+acb-error = 1;
+} else if (r gaiocb-size) {
+memset(gaiocb-buf + r, 0, gaiocb-size - r);
+if (!acb-error) {
+acb-ret = gaiocb-size;
+}
+} else if (!acb-error) {
+acb-ret = r;
+}
+}
+acb-bh = qemu_bh_new(gluster_aio_bh_cb, acb);
+qemu_bh_schedule(acb-bh);
+done:
+g_free(gaiocb);
+}
+
+static void qemu_gluster_aio_event_reader(void *opaque)
+{
+BDRVGlusterState *s = opaque;
+ssize_t ret;
+
+do {
+char *p = (char *)s-event_gaiocb;
+
+ret = read(s-fds[GLUSTER_FD_READ], p + s-event_reader_pos,
+ sizeof(s-event_gaiocb) - s-event_reader_pos);
+if (ret 0) {
+s-event_reader_pos += ret;
+if (s-event_reader_pos == sizeof(s-event_gaiocb)) {
+s-event_reader_pos = 0;
+qemu_gluster_complete_aio(s-event_gaiocb);
+s-qemu_aio_count--;
+}
+}
+} while (ret 0 errno == EINTR);
+}
+
+static int qemu_gluster_aio_flush_cb(void *opaque)
+{
+BDRVGlusterState *s = opaque;
+
+return
Re: [Qemu-devel] [RFC] QOMification of AXI stream
On Mon, Jun 11, 2012 at 02:39:56PM +0100, Peter Maydell wrote: On 11 June 2012 14:15, Anthony Liguori aligu...@us.ibm.com wrote: From what you said earlier, it's basically: 'write data to this address' 'read data from this address' An interface that implements this is DMAContext. Forget about the fact that 'DMA' is in the name. It's really the symmetric version of a MemoryRegion. ...so can we fix the name? Ideally the interface used by DMA controllers should be identical to the interface used by CPUs to talk to the rest of the system: it's exactly the same bus interface in hardware, after all. I thought we were talking about the interface between the DMA ctrl and the I/O (devices). Not between the DMA and the memory bus system. Cheers
Re: [Qemu-devel] [PATCH qom-next 1/7] qdev: Push state up to Object
Am 11.06.2012 15:21, schrieb Anthony Liguori:
On 06/11/2012 03:25 AM, Kevin Wolf wrote:
Am 10.06.2012 19:38, schrieb Andreas Färber:
Am 10.06.2012 17:49, schrieb Paolo Bonzini:
Il 08/06/2012 03:19, Anthony Liguori ha scritto:
+typedef enum ObjectState {
+OBJECT_STATE_INITIALIZED = 1,
+OBJECT_STATE_REALIZED,
+} ObjectState;
I think using a bool would be better since it reduces the temptation to
add additional states.
In fact someone already discussed having a third state for block
devices... :)
I would expect that file_opened state to remain internal to the block
layer. Thought we discussed that on IRC?
I think I still don't understand well enough what 'realized' is really
supposed to mean.
realized is essentially the Vcc pin for the device.
My BlockDriverState doesn't have a Vcc pin, and neither has my Error
object. I thought realize() did exist in Object and not only in Device?
If so, it must have a more generic meaning.
Does some magic happen when an object gets realised? From outside,
what's the difference between an INITIALIZED and a REALIZED object? Is
it more or less an implementation detail of the base class or is it
something that affects the object model itself?
On the rising edge of realized, you typically will validate any parameters
and
do any actions necessary based on the parameters. As long as the guest isn't
running, we want the ability to make changes to the devices that we normally
couldn't change while the guest is running (like updating the CharDriverState
pointer).
Okay, that matches my understanding.
Are all of the checks and the status change of properties (modifiable -
const) done by the specific subclass or is it done by QOM to some degree?
I think the file_opened state should have more or less the same status
as the realisation of an object. They are quite similar, so they should
both be an implementation detail of their respective class, or they
should both be baked into the object model.
I think we need to think about what realized means to a non-Device. Does
file_opened have the same logical semantics as the above?
Yes, I think it's quite similar, just at an intermediate stage of the
object creation. As I imagine it, you would:
1. Create a BlockDriveState
2. Modify the filename property (you can really modify any property if
you want for some reason)
3. Call file_open, which opens the image file and may derive some
default property values from the image file (flags in the header or
whatever). Typical example: The backing file path. I think this would
roughly correspond to an extended .bdrv_probe.
4. Modify more properties, overriding any defaults of the image.
file_open has made some properties read-only (like the filename),
which cannot be modified any more.
5. Call realize. This is the actual .bdrv_open call that makes the
BlockDriverState ready to be used. This makes some more properties
read-only, like the backing file and format.
A comment in this patch says it means that an object is fully
constructed.
That's not really the best wording. See above.
For non-Devices it's still the best explanation I have found.
Kevin
Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
On Mon, Jun 11, 2012 at 3:24 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Jun 11, 2012 at 4:57 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Mon, Jun 11, 2012 at 08:28:57AM +0200, Paolo Bonzini wrote: Il 09/06/2012 05:04, Zhi Yong Wu ha scritto: This commit looks suspicious because it removes a user-visible qdev property but we're trying to preserve backward compatibility. This command-line will break: x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device virtio-net-pci,vlan=1 Instead of dropping the qdev_prop_vlan completely the hw/qdev-properties.c code needs to call net/hub.h external functions to implement equivalent functionality: 1. Setting the vlan=id property looks up the hub port and assigns the NICConf-peer field. 2. Getting the vlan property looks up the hub id (i.e. vlan id) given the peer. If the peer is not a hub port the result is -1. When I wrote this patch I missed the big picture and forgot about backwards compatibility :(. To be honest, i am concerned if anyone uses this syntax. Since the feature will finally be discarded, i suggest that we don't support this now. If someone complains this later, we can fix it. If nobody complains, that is what we hope. I think you're missing the big picture of this series, which is exactly _not_ to discard the VLAN feature, but just to rewrite it in a better way. That said, I agree that this is a somewhat fringe usage; most people will use -net nic,model=virtio,vlan=1 rather than -device. We may get by with dropping it. I have no strong opinion either way. Either we keep backwards compatibility or we don't. Taking a middle path where we preserve only some of the VLAN syntax is confusing and inconsistent. in terms of technology, i fully agree with you, but in terms of usefulness and our business, it will waste our effort, time and is meaningless if nobody or no customers use this syntax. As i said, if someone complain this later, we can fix it. When users upgrade QEMU versions and find their setup is now broken QEMU's reputation will be damaged. You can't build critical systems on top of software which keeps changing and breaking. Fixing it after a user hits the problem is not okay, users won't trust us if we do that. We need to be disciplined when it comes to backwards compatibility. Either we support the VLAN feature or we drop it. We already had this discussion in another thread, here's what Anthony had to say: Dropping features is only something that should be approached lightly and certainly not something that should be done just because you don't like a particular bit of code. http://permalink.gmane.org/gmane.comp.emulators.qemu/153600 Stefan
Re: [Qemu-devel] [RFC] QOMification of AXI stream
On 11 June 2012 15:38, Edgar E. Iglesias edgar.igles...@gmail.com wrote: On Mon, Jun 11, 2012 at 02:39:56PM +0100, Peter Maydell wrote: Ideally the interface used by DMA controllers should be identical to the interface used by CPUs to talk to the rest of the system: it's exactly the same bus interface in hardware, after all. I thought we were talking about the interface between the DMA ctrl and the I/O (devices). Not between the DMA and the memory bus system. In hardware (at least for AXI) they're the same thing. A DMA controller is a bus master, just like a CPU. They don't care whether the slave is RAM or a device, they're just issuing memory transactions to addresses. -- PMM
Re: [Qemu-devel] [PATCH v2 2/3] Simpletrace v2: Add support for multiple args, strings.
On Mon, Jun 11, 2012 at 1:31 PM, Harsh Bora ha...@linux.vnet.ibm.com wrote:
On 06/07/2012 08:02 PM, Stefan Hajnoczi wrote:
On Thu, May 24, 2012 at 10:50 AM, Harsh Prateek Bora
ha...@linux.vnet.ibm.com wrote:
@@ -75,16 +96,22 @@ static char *trace_file_name = NULL;
*
* Returns false if the record is not valid.
*/
-static bool get_trace_record(unsigned int idx, TraceRecord *record)
+static bool get_trace_record(unsigned int idx, TraceRecord **recordptr)
{
- if (!(trace_buf[idx].event TRACE_RECORD_VALID)) {
+ uint8_t temp_rec[ST_REC_HDR_LEN];
+ TraceRecord *record = (TraceRecord *) temp_rec;
+ read_from_buffer(idx, temp_rec, ST_REC_HDR_LEN);
+
+ if (!(record-event TRACE_RECORD_VALID)) {
return false;
}
__sync_synchronize(); /* read memory barrier before accessing record
*/
The need for the memory barrier is no longer clear. Previously we
were directly accessing the trace ring buffer, and therefore needed to
ensure fields were settled before accessing them. Now we use
read_from_buffer() which copies the data into our temporary struct on
the stack.
I think the best way of doing it is to read the event field first in a
separate step, then do the read memory barrier, and then read the rest
of the record. This ensures that the event field is at least as old
as the other fields we read.
Currently, it does a two step read:
read header (which includes event field and length of record as well)
sync
read rest of record (using length from header)
Are you suggesting this:
read event field only
sync (if event valid)
read header (for length)
sync
read rest of record (using length)
or
read event field only
sync (if event valid)
read header (for length)
read rest of record
header, sync, rest of header + payload
The reason for the read barrier is to ensure that we don't read stale
header fields (e.g. length) together with an up-to-date valid event
field.
- *record = trace_buf[idx];
- record-event= ~TRACE_RECORD_VALID;
+ *recordptr = g_malloc(record-length);
+ /* make a copy of record to avoid being overwritten */
+ read_from_buffer(idx, (uint8_t *)*recordptr, record-length);
+ (*recordptr)-event= ~TRACE_RECORD_VALID;
return true;
}
[]
-void trace3(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3)
+int trace_alloc_record(TraceBufferRecord *rec, TraceEventID event,
uint32_t datasize)
{
- trace(event, x1, x2, x3, 0, 0, 0);
+ unsigned int idx, rec_off;
+ uint32_t rec_len = ST_REC_HDR_LEN + datasize;
+ uint64_t timestamp_ns = get_clock();
+
+ if ((rec_len + trace_idx - writeout_idx) TRACE_BUF_LEN) {
+ /* Trace Buffer Full, Event dropped ! */
+ dropped_events++;
+ return 1;
-ENOSPC? A negative errno is clearer than 0 - success, 1 - failure.
+ }
+ idx = g_atomic_int_exchange_and_add((gint *)trace_idx, rec_len) %
TRACE_BUF_LEN;
How does this deal with the race condition of two or more threads
running trace_alloc_record() concurrently when the buffer reaches max
size? I think two or more threads could think they have enough space
because trace_idx hasn't been updated yet between the buffer length
check and the atomic update.
Are you suggesting to use locking here ? I couldnt find a test-and-set
alternative in glib2. Does qemu have access to any such interface ?
How about:
http://developer.gnome.org/glib/2.32/glib-Atomic-Operations.html#g-atomic-int-compare-and-exchange
I think this becomes:
while True:
old_idx = trace_idx
rmb()
new_idx = old_idx + rec_len
if new_idx - write_idx TRACE_BUF_LEN:
dropped_events++
return
if g_atomic_int_compare_and_exchange((gint *)trace_idx, old_idx, new_idx):
break
Now we've reserved [new_idx, new_idx + rec_len).
+void trace_record_finish(TraceBufferRecord *rec);
+uint32_t safe_strlen(const char* str);
Given that safe_strlen() is only used once and a generic utility (not
specific to the simple trace backend), I suggest dropping it an just
open coding the tristate operator: s ? strlen(s) : 0.
safe_strlen is used multiple times in auto-generated code by tracetool in
expression for calculating the sum of size of trace arguments which as of
now looks like:
8 + 8 + 4 + safe_strlen(str1) + 8 + 4 + safe_strlen(str2) ...
for tracing events with string arguments. For trace events with multiple
strings, this expression is more readable as compared to having an
expression with tristate operator like this:
8 + 8 + 4 + (str1 ? strlen(str1) : 0) + 8 + 4 + (str2 ? strlen(str2) : 0)
...
I agree that its a generic function and need not be placed in tracing code,
let me know the right place where to put it if you think its worth keeping
it.
The generic place to put it is cutils.c. It's up to you if you want to keep it.
Stefan
Re: [Qemu-devel] [RFC] QOMification of AXI stream
On Mon, Jun 11, 2012 at 03:53:23PM +0100, Peter Maydell wrote: On 11 June 2012 15:38, Edgar E. Iglesias edgar.igles...@gmail.com wrote: On Mon, Jun 11, 2012 at 02:39:56PM +0100, Peter Maydell wrote: Ideally the interface used by DMA controllers should be identical to the interface used by CPUs to talk to the rest of the system: it's exactly the same bus interface in hardware, after all. I thought we were talking about the interface between the DMA ctrl and the I/O (devices). Not between the DMA and the memory bus system. In hardware (at least for AXI) they're the same thing. A DMA controller is a bus master, just like a CPU. They don't care whether the slave is RAM or a device, they're just issuing memory transactions to addresses. In many cases they are not the same thing. The DMA controller has an interface to the bus (the one you refer to) and in many cases dedicated channels connected to the various devices. These channels may or may not resemble the bus a CPU uses, typically they don't. There are of course systems of any kind, even ones that use the system bus to transfer data from the DMA to/from the devices.
