[Qemu-devel] [PATCH]booke: Use MMU API for creating initial mapping for secondary cpus
Initial Mapping creation for secondary CPU in SMP was missing new MMU API. Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com --- hw/ppce500_spin.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/ppce500_spin.c b/hw/ppce500_spin.c index 6b8a189..e8cf154 100644 --- a/hw/ppce500_spin.c +++ b/hw/ppce500_spin.c @@ -86,6 +86,7 @@ static void mmubooke_create_initial_mapping(CPUState *env, tlb-mas2 = (va TARGET_PAGE_MASK) | MAS2_M; tlb-mas7_3 = pa TARGET_PAGE_MASK; tlb-mas7_3 |= MAS3_UR | MAS3_UW | MAS3_UX | MAS3_SR | MAS3_SW | MAS3_SX; +env-tlb_dirty = true; } static void spin_kick(void *data) -- 1.7.0.4
[Qemu-devel] [PATCH] Replace bdrv_* to bdrv_aio_* functions in pio mode in fdc.c.
Replace bdrv_* to bdrv_aio_* functions in pio mode in fdc.c.
Signed-off-by: Li Zhi Hui zhihu...@linux.vnet.ibm.com
---
hw/fdc.c | 117 +++--
1 files changed, 90 insertions(+), 27 deletions(-)
diff --git a/hw/fdc.c b/hw/fdc.c
index a0236b7..5e855fd 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -1301,12 +1301,42 @@ static int fdctrl_transfer_handler (void *opaque, int
nchan,
return len;
}
+enum {
+FD_DATA_IDLE,
+FD_DATA_WORKING,
+FD_DATA_FIN,
+};
+
+int data_status[MAX_FD];
+
+static void fdctrl_read_pio_cb(void *opaque, int ret)
+{
+FDCtrl *fdctrl = opaque;
+FDrive *cur_drv;
+
+if (ret 0) {
+cur_drv = get_cur_drv(fdctrl);
+FLOPPY_DPRINTF(error getting sector %d\n,
+ fd_sector(cur_drv));
+/* Sure, image size is too small... */
+memset(fdctrl-fifo, 0, FD_SECTOR_LEN);
+data_status[fdctrl-cur_drv] = FD_DATA_IDLE;
+goto end;
+}
+data_status[fdctrl-cur_drv] = FD_DATA_FIN;
+
+end:
+return;
+}
+
/* Data register : 0x05 */
static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
{
FDrive *cur_drv;
uint32_t retval = 0;
int pos;
+QEMUIOVector qiov;
+struct iovec iov;
cur_drv = get_cur_drv(fdctrl);
fdctrl-dsr = ~FD_DSR_PWRDOWN;
@@ -1318,17 +1348,30 @@ static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
if (fdctrl-msr FD_MSR_NONDMA) {
pos %= FD_SECTOR_LEN;
if (pos == 0) {
-if (fdctrl-data_pos != 0)
-if (!fdctrl_seek_to_next_sect(fdctrl, cur_drv)) {
-FLOPPY_DPRINTF(error seeking to next sector %d\n,
- fd_sector(cur_drv));
-return 0;
+switch (data_status[fdctrl-cur_drv]) {
+case FD_DATA_IDLE:
+if (fdctrl-data_pos != 0) {
+if (!fdctrl_seek_to_next_sect(fdctrl, cur_drv)) {
+FLOPPY_DPRINTF(error seeking to next sector %d\n,
+ fd_sector(cur_drv));
+goto end;
+}
}
-if (bdrv_read(cur_drv-bs, fd_sector(cur_drv), fdctrl-fifo, 1)
0) {
-FLOPPY_DPRINTF(error getting sector %d\n,
- fd_sector(cur_drv));
-/* Sure, image size is too small... */
-memset(fdctrl-fifo, 0, FD_SECTOR_LEN);
+iov.iov_base = fdctrl-fifo;
+iov.iov_len = FD_SECTOR_LEN;
+qemu_iovec_init_external(qiov, iov, 1);
+bdrv_aio_readv(cur_drv-bs, fd_sector(cur_drv),
+qiov, 1, fdctrl_read_pio_cb, fdctrl);
+data_status[fdctrl-cur_drv] = FD_DATA_WORKING;
+goto end;
+case FD_DATA_WORKING:
+goto end;
+case FD_DATA_FIN:
+data_status[fdctrl-cur_drv] = FD_DATA_IDLE;
+break;
+default:
+data_status[fdctrl-cur_drv] = FD_DATA_IDLE;
+goto end;
}
}
}
@@ -1347,6 +1390,7 @@ static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
}
FLOPPY_DPRINTF(data register: 0x%02x\n, retval);
+end:
return retval;
}
@@ -1759,10 +1803,38 @@ static const struct {
/* Associate command to an index in the 'handlers' array */
static uint8_t command_to_handler[256];
+static void fdctrl_write_pio_cb(void *opaque, int ret)
+{
+FDCtrl *fdctrl = opaque;
+FDrive *cur_drv;
+
+cur_drv = get_cur_drv(fdctrl);
+if (ret 0) {
+FLOPPY_ERROR(writing sector %d\n, fd_sector(cur_drv));
+goto end;
+}
+if (!fdctrl_seek_to_next_sect(fdctrl, cur_drv)) {
+FLOPPY_DPRINTF(error seeking to next sector %d\n,
+ fd_sector(cur_drv));
+goto end;
+}
+/* Switch from transfer mode to status mode
+ * then from status mode to command mode
+ */
+if (fdctrl-data_pos == fdctrl-data_len) {
+fdctrl_stop_transfer(fdctrl, FD_SR0_SEEK, 0x00, 0x00);
+}
+
+end:
+return;
+}
+
static void fdctrl_write_data(FDCtrl *fdctrl, uint32_t value)
{
FDrive *cur_drv;
int pos;
+QEMUIOVector qiov;
+struct iovec iov;
/* Reset mode */
if (!(fdctrl-dor FD_DOR_nRESET)) {
@@ -1780,25 +1852,16 @@ static void fdctrl_write_data(FDCtrl *fdctrl, uint32_t
value)
pos = fdctrl-data_pos++;
pos %= FD_SECTOR_LEN;
fdctrl-fifo[pos] = value;
-if (pos == FD_SECTOR_LEN - 1 ||
-fdctrl-data_pos == fdctrl-data_len) {
+if ((pos == FD_SECTOR_LEN - 1) ||
+(fdctrl-data_pos == fdctrl-data_len)) {
cur_drv = get_cur_drv(fdctrl);
-if (bdrv_write(cur_drv-bs, fd_sector(cur_drv), fdctrl-fifo, 1)
0) {
-FLOPPY_ERROR(writing sector %d\n, fd_sector(cur_drv));
-return;
-
[Qemu-devel] [PATCH V3 0/7] Make QED with live migration safe
This is the third version of a patchset aiming at making the combined usage of QED and live migration safe. v3: -qed: Drop the flags qed structure member and use bs-open_flags to reopen (stefana) -qed: When opening honor flags parameter instead of bs-open_flags v2: -The block layer is not aware anymore of the migration state. (stefanha) -No bdrv_invalidate_cache renaming since the semantic do not change. (stefanha) -The qed bdrv_invalidate_cache function does a reopening of the image to flush metadata and to do the image integrity check. (stefanha) Benoît Canet (7): block: Add new BDRV_O_INCOMING flag to notice incoming live migration block: add a function to clear incoming live migration flags blockdev: open images with BDRV_O_INCOMING on incoming live migration qed: add bdrv_invalidate_cache to be called after incoming live migration migration: clear BDRV_O_INCOMING flags on end of incoming live migration qed: honor BDRV_O_INCOMING for incoming live migration qed: remove incoming live migration blocker block.c |9 + block.h |3 +++ block/qed.c | 24 +--- block/qed.h |2 -- blockdev.c |4 migration.c |1 + 6 files changed, 30 insertions(+), 13 deletions(-) -- 1.7.7.6
[Qemu-devel] [PATCH V3 6/7] qed: honor BDRV_O_INCOMING for incoming live migration
From original commit with Patchwork-id: 31108 by
Stefan Hajnoczi stefa...@linux.vnet.ibm.com
The QED image format includes a file header bit to mark images dirty.
QED normally checks dirty images on open and fixes inconsistent
metadata. This is undesirable during live migration since the dirty bit
may be set if the source host is modifying the image file. The check
should be postponed until migration completes.
Skip operations that modify the image file if the BDRV_O_INCOMING flag
is set.
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
block/qed.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index e32f598..4a53db6 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -450,7 +450,7 @@ static int bdrv_qed_open(BlockDriverState *bs, int flags)
* feature is no longer valid.
*/
if ((s-header.autoclear_features ~QED_AUTOCLEAR_FEATURE_MASK) != 0
-!bdrv_is_read_only(bs-file)) {
+!bdrv_is_read_only(bs-file) !(flags BDRV_O_INCOMING)) {
s-header.autoclear_features = QED_AUTOCLEAR_FEATURE_MASK;
ret = qed_write_header_sync(s);
@@ -477,7 +477,8 @@ static int bdrv_qed_open(BlockDriverState *bs, int flags)
* potentially inconsistent images to be opened read-only. This can
* aid data recovery from an otherwise inconsistent image.
*/
-if (!bdrv_is_read_only(bs-file)) {
+if (!bdrv_is_read_only(bs-file)
+!(flags BDRV_O_INCOMING)) {
BdrvCheckResult result = {0};
ret = qed_check(s, result, true);
--
1.7.7.6
[Qemu-devel] [PATCH V3 5/7] migration: clear BDRV_O_INCOMING flags on end of incoming live migration
Signed-off-by: Benoît Canet benoit.ca...@gmail.com --- migration.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/migration.c b/migration.c index 8c119ba..94f7839 100644 --- a/migration.c +++ b/migration.c @@ -91,6 +91,7 @@ void process_incoming_migration(QEMUFile *f) qemu_announce_self(); DPRINTF(successfully loaded vm state\n); +bdrv_clear_incoming_migration_all(); /* Make sure all file formats flush their mutable metadata */ bdrv_invalidate_cache_all(); -- 1.7.7.6
Re: [Qemu-devel] [PATCH 11/11 v10] introduce a new monitor command 'dump-guest-memory' to dump guest's memory
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 11/11 v10] introduce a new monitor command 'dump-guest-memory'
to dump guest's memory
Date: Tue, 20 Mar 2012 11:57:43 +0800
cut
+typedef struct DumpState {
+ArchDumpInfo dump_info;
+MemoryMappingList list;
+uint16_t phdr_num;
+uint32_t sh_info;
+bool have_section;
+bool resume;
+target_phys_addr_t memory_offset;
+write_core_dump_function f;
f() is so general. Type information is meaningless enough, but there's
no explicit occurence of the function call of f(). Could you consider
renaming?
+void (*cleanup)(void *opaque);
+void *opaque;
+
+RAMBlock *block;
+ram_addr_t start;
+bool has_filter;
+int64_t begin;
+int64_t length;
+} DumpState;
+
cut
+
+static int write_elf64_load(DumpState *s, MemoryMapping *memory_mapping,
+int phdr_index, target_phys_addr_t offset)
+{
+Elf64_Phdr phdr;
+off_t phdr_offset;
+int ret;
+int endian = s-dump_info.d_endian;
+
+memset(phdr, 0, sizeof(Elf64_Phdr));
+phdr.p_type = cpu_convert_to_target32(PT_LOAD, endian);
+phdr.p_offset = cpu_convert_to_target64(offset, endian);
+phdr.p_paddr = cpu_convert_to_target64(memory_mapping-phys_addr,
endian);
+if (offset == -1) {
Question: In what situations does offset become -1?
cut
+static int write_elf_section(DumpState *s, target_phys_addr_t *offset, int
type)
+{
+Elf32_Shdr shdr32;
+Elf64_Shdr shdr64;
+int endian = s-dump_info.d_endian;
+int shdr_size;
+void *shdr;
+int ret;
+
+if (type == 0) {
In other places, you checks s-dump_info.d_class == ELFCLASS64, and
variable ``type'' here has the same meaning. It's better to fit this
to the others.
Also, the ``s-dump_info.d_class == ELFCLASS64'' occurs so many times
in source code. Why not add method to DumpState type to avoid this
check? For example,
typedef struct DumpState {
...
int write_elf_header(DumpState *s)
...
} DumpState;
and then, register appropreate function to the member in
cpu_get_dump_info().
+ *
+ * the type of ehdr-e_phnum is uint16_t, so we should avoid overflow
+ */
+s-phdr_num = 1; /* PT_NOTE */
+if (s-list.num UINT16_MAX - 2) {
Is s-list.num UINT16_MAX - 1 correct?
+s-phdr_num += s-list.num;
+s-have_section = false;
+} else {
+s-have_section = true;
+s-phdr_num = PN_XNUM;
+s-sh_info = 1; /* PT_NOTE */
It's confusing to use member names, phdr_num and sh_info, from
differnet views. I first think phdr_num is used for an actual number
of program headers, but in reality, this is used as e_phum member in
ELF header. It's better to use e_phnum just as sh_info to avoid
confusion.
Also, this logic is comform to ELF specification, so it's better to
move this to write_elfNN_header() and write_elf_section().
Thanks.
HATAYAMA, Daisuke
[Qemu-devel] Spice bug with qemu_name
Hi, I think I've found a bug with the way that spice uses qemu_name. qemu_name is a char *, that's only set to if -name is given (and then the arg is strdup'd), otherwise it's not set properly. In ui/spice_core.c spice_server_set_name() is called with qemu_name, which if not set causes a core dump. - lwp# 1 / thread# 1 fd7fff168090 strlen () + 30 fd7ffa6b5d7e spice_server_set_name () + 2b 0068fab1 qemu_spice_init () + 753 0062a58f main () + 2a31 00519c5c _start () + 6c - lwp# 2 / thread# 2 fd7fff1f9b2a __sigtimedwait () + a fd7fff1e626d sigwait () + d fd7fff1d1b31 __posix_sigwait () + 31 0057572c sigwait_compat () + 68 fd7fff1f39a3 _thrp_setup () + 83 fd7fff1f3ca0 _lwp_start () There's a similar situation with qemu_uuid, however because it's not a pointer I'm assuming you end up with all zero's, which is probably ok behaviour. I haven't provided a patch since I don't really know which way you want to fix this ... either provide a sensible default if it's not set, or default to NULL and check it in the spice code. Regards, Lee.
[Qemu-devel] [PATCH V3 2/7] block: add a function to clear incoming live migration flags
This function will clear all BDRV_O_INCOMING flags.
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
block.c |9 +
block.h |2 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index b88ee90..45085e7 100644
--- a/block.c
+++ b/block.c
@@ -3584,6 +3584,15 @@ void bdrv_invalidate_cache_all(void)
}
}
+void bdrv_clear_incoming_migration_all(void)
+{
+BlockDriverState *bs;
+
+QTAILQ_FOREACH(bs, bdrv_states, list) {
+bs-open_flags = bs-open_flags ~(BDRV_O_INCOMING);
+}
+}
+
int bdrv_flush(BlockDriverState *bs)
{
Coroutine *co;
diff --git a/block.h b/block.h
index b3b18d6..951b476 100644
--- a/block.h
+++ b/block.h
@@ -223,6 +223,8 @@ BlockDriverAIOCB *bdrv_aio_ioctl(BlockDriverState *bs,
void bdrv_invalidate_cache(BlockDriverState *bs);
void bdrv_invalidate_cache_all(void);
+void bdrv_clear_incoming_migration_all(void);
+
/* Ensure contents are flushed to disk. */
int bdrv_flush(BlockDriverState *bs);
int coroutine_fn bdrv_co_flush(BlockDriverState *bs);
--
1.7.7.6
[Qemu-devel] [PATCH 0/2] QEMU kvm: Adding paravirtual spinlock support for x86.
The patch, extends KVM-hypervisor and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks. PV ticket spinlock helps to solve Lock Holder Preemption problem discussed in http://www.amd64.org/fileadmin/user_upload/pub/LHP-commented_slides.pdf. When spinlock is contended,a guest vcpu relinqueshes cpu by halt(). Correspondingly, One hypercall is introduced in KVM hypervisor,that allows a vcpu to kick the halted vcpu to continue with execution. Note: Below patch should be applied only after corresponding linux-header changes taken into qemu via scripts/update-linux-headers.sh script. --- Changes in V3: rename PVLOCK_KICK -- PV_UNHALT add MSR related changes to aid migration Changes in V2: Drop the syncing kernel header changes. (Alex) rename KICK_VCPU -- PVLOCK_KICK. Raghavendra K T(2): add PV_UNHALT feature support. add support to get/set vcpu unhalt msr to aid migration target-i386/cpu.h |1 + target-i386/kvm.c | 14 +- 2 files changed, 14 insertions(+), 1 deletions(-) V5 Kernel changes: https://lkml.org/lkml/2012/3/23/50 V4 kernel changes: https://lkml.org/lkml/2012/1/14/66 Qemu changes for V4: http://www.mail-archive.com/kvm@vger.kernel.org/msg66450.html V3 kernel Changes: https://lkml.org/lkml/2011/11/30/62 V2 kernel changes : https://lkml.org/lkml/2011/10/23/207 Previous discussions : (posted by Srivatsa V). https://lkml.org/lkml/2010/7/26/24 https://lkml.org/lkml/2011/1/19/212 Qemu patch for V3: http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00397.html
[Qemu-devel] [PATCH 1/2] QEMU kvm: Add PV_UNHALT feature support
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Extend the KVM Hypervisor to enable PVLOCK_KICK feature that allows
a vcpu to kick the halted vcpu to continue with execution in PV ticket
spinlock.
Signed-off-by: Srivatsa Vaddagiri va...@linux.vnet.ibm.com
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index e74a9e4..dbebd3a 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -98,6 +98,7 @@ struct kvm_para_features {
{ KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
{ KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
{ KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
+{ KVM_CAP_PV_UNHALT, KVM_FEATURE_PV_UNHALT },
{ -1, -1 }
};
[Qemu-devel] [PATCH 2/2] QEMU kvm: Add support to get/set vcpu unhalt msr to aid migration
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
MSR_KVM_PV_UNHALT tells whether vcpu is unhalted, which needs to be
used during migration.
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index a1ed3e7..10286a5 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -697,6 +697,7 @@ typedef struct CPUX86State {
uint64_t system_time_msr;
uint64_t wall_clock_msr;
uint64_t async_pf_en_msr;
+uint64_t pv_unhalt_msr;
uint64_t tsc;
uint64_t tsc_deadline;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index dbebd3a..98b9088 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -62,6 +62,7 @@ static bool has_msr_star;
static bool has_msr_hsave_pa;
static bool has_msr_tsc_deadline;
static bool has_msr_async_pf_en;
+static bool has_msr_pv_unhalt;
static bool has_msr_misc_enable;
static int lm_capable_kernel;
@@ -444,7 +445,7 @@ int kvm_arch_init_vcpu(CPUX86State *env)
}
has_msr_async_pf_en = c-eax (1 KVM_FEATURE_ASYNC_PF);
-
+has_msr_pv_unhalt = c-eax (1 KVM_FEATURE_PV_UNHALT);
cpu_x86_cpuid(env, 0, 0, limit, unused, unused, unused);
for (i = 0; i = limit; i++) {
@@ -1012,6 +1013,10 @@ static int kvm_put_msrs(CPUX86State *env, int level)
if (hyperv_vapic_recommended()) {
kvm_msr_entry_set(msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
}
+if (has_msr_pv_unhalt) {
+kvm_msr_entry_set(msrs[n++], MSR_KVM_PV_UNHALT,
+ env-pv_unhalt_msr);
+}
}
if (env-mcg_cap) {
int i;
@@ -1247,6 +1252,9 @@ static int kvm_get_msrs(CPUX86State *env)
if (has_msr_async_pf_en) {
msrs[n++].index = MSR_KVM_ASYNC_PF_EN;
}
+if (has_msr_pv_unhalt) {
+msrs[n++].index = MSR_KVM_PV_UNHALT;
+}
if (env-mcg_cap) {
msrs[n++].index = MSR_MCG_STATUS;
@@ -1326,6 +1334,9 @@ static int kvm_get_msrs(CPUX86State *env)
case MSR_KVM_ASYNC_PF_EN:
env-async_pf_en_msr = msrs[i].data;
break;
+case MSR_KVM_PV_UNHALT:
+env-pv_unhalt_msr = msrs[i].data;
+break;
}
}
[Qemu-devel] [PATCH V3 4/7] qed: add bdrv_invalidate_cache to be called after incoming live migration
The QED image is reopened to flush metadata and check consistency.
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
block/qed.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index a041d31..e32f598 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -1516,6 +1516,15 @@ static int bdrv_qed_change_backing_file(BlockDriverState
*bs,
return ret;
}
+static void bdrv_qed_invalidate_cache(BlockDriverState *bs)
+{
+BDRVQEDState *s = bs-opaque;
+
+bdrv_qed_close(bs);
+memset(s, 0, sizeof(BDRVQEDState));
+bdrv_qed_open(bs, bs-open_flags);
+}
+
static int bdrv_qed_check(BlockDriverState *bs, BdrvCheckResult *result)
{
BDRVQEDState *s = bs-opaque;
@@ -1568,6 +1577,7 @@ static BlockDriver bdrv_qed = {
.bdrv_getlength = bdrv_qed_getlength,
.bdrv_get_info= bdrv_qed_get_info,
.bdrv_change_backing_file = bdrv_qed_change_backing_file,
+.bdrv_invalidate_cache= bdrv_qed_invalidate_cache,
.bdrv_check = bdrv_qed_check,
};
--
1.7.7.6
[Qemu-devel] [PATCH V3 3/7] blockdev: open images with BDRV_O_INCOMING on incoming live migration
Open images with BDRV_O_INCOMING in order to inform block drivers
that an incoming live migration is coming.
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
blockdev.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 1a500b8..9b57133 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -591,6 +591,10 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
bdrv_flags |= BDRV_O_COPY_ON_READ;
}
+if (runstate_check(RUN_STATE_INMIGRATE)) {
+bdrv_flags |= BDRV_O_INCOMING;
+}
+
if (media == MEDIA_CDROM) {
/* CDROM is fine for any interface, don't check. */
ro = 1;
--
1.7.7.6
[Qemu-devel] [PATCH V3 7/7] qed: remove incoming live migration blocker
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
block/qed.c |9 -
block/qed.h |2 --
2 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index 4a53db6..74ea278 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -498,12 +498,6 @@ static int bdrv_qed_open(BlockDriverState *bs, int flags)
s-need_check_timer = qemu_new_timer_ns(vm_clock,
qed_need_check_timer_cb, s);
-error_set(s-migration_blocker,
- QERR_BLOCK_FORMAT_FEATURE_NOT_SUPPORTED,
- qed, bs-device_name, live migration);
-migrate_add_blocker(s-migration_blocker);
-
-
out:
if (ret) {
qed_free_l2_cache(s-l2_cache);
@@ -516,9 +510,6 @@ static void bdrv_qed_close(BlockDriverState *bs)
{
BDRVQEDState *s = bs-opaque;
-migrate_del_blocker(s-migration_blocker);
-error_free(s-migration_blocker);
-
qed_cancel_need_check_timer(s);
qemu_free_timer(s-need_check_timer);
diff --git a/block/qed.h b/block/qed.h
index 62624a1..c716772 100644
--- a/block/qed.h
+++ b/block/qed.h
@@ -169,8 +169,6 @@ typedef struct {
/* Periodic flush and clear need check flag */
QEMUTimer *need_check_timer;
-
-Error *migration_blocker;
} BDRVQEDState;
enum {
--
1.7.7.6
Re: [Qemu-devel] [PATCH 2/2] QEMU kvm: Add support to get/set vcpu unhalt msr to aid migration
On 2012-03-23 09:23, Raghavendra K T wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
MSR_KVM_PV_UNHALT tells whether vcpu is unhalted, which needs to be
used during migration.
Err, and where is it actually saved to/restored from the vmstate? You
are lacking an extension of the CPU vmstate, preferably via a substate.
See e.g. cpu/async_pf_msr.
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index a1ed3e7..10286a5 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -697,6 +697,7 @@ typedef struct CPUX86State {
uint64_t system_time_msr;
uint64_t wall_clock_msr;
uint64_t async_pf_en_msr;
+uint64_t pv_unhalt_msr;
uint64_t tsc;
uint64_t tsc_deadline;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index dbebd3a..98b9088 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -62,6 +62,7 @@ static bool has_msr_star;
static bool has_msr_hsave_pa;
static bool has_msr_tsc_deadline;
static bool has_msr_async_pf_en;
+static bool has_msr_pv_unhalt;
static bool has_msr_misc_enable;
static int lm_capable_kernel;
@@ -444,7 +445,7 @@ int kvm_arch_init_vcpu(CPUX86State *env)
}
has_msr_async_pf_en = c-eax (1 KVM_FEATURE_ASYNC_PF);
-
+has_msr_pv_unhalt = c-eax (1 KVM_FEATURE_PV_UNHALT);
cpu_x86_cpuid(env, 0, 0, limit, unused, unused, unused);
for (i = 0; i = limit; i++) {
@@ -1012,6 +1013,10 @@ static int kvm_put_msrs(CPUX86State *env, int level)
if (hyperv_vapic_recommended()) {
kvm_msr_entry_set(msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
}
+if (has_msr_pv_unhalt) {
+kvm_msr_entry_set(msrs[n++], MSR_KVM_PV_UNHALT,
+ env-pv_unhalt_msr);
+}
}
if (env-mcg_cap) {
int i;
@@ -1247,6 +1252,9 @@ static int kvm_get_msrs(CPUX86State *env)
if (has_msr_async_pf_en) {
msrs[n++].index = MSR_KVM_ASYNC_PF_EN;
}
+if (has_msr_pv_unhalt) {
+msrs[n++].index = MSR_KVM_PV_UNHALT;
+}
if (env-mcg_cap) {
msrs[n++].index = MSR_MCG_STATUS;
@@ -1326,6 +1334,9 @@ static int kvm_get_msrs(CPUX86State *env)
case MSR_KVM_ASYNC_PF_EN:
env-async_pf_en_msr = msrs[i].data;
break;
+case MSR_KVM_PV_UNHALT:
+env-pv_unhalt_msr = msrs[i].data;
+break;
}
}
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 1/2] slirp: clean up conflicts with system headers
On 2012-03-22 20:24, Paolo Bonzini wrote:
Il 22/03/2012 15:35, Jan Kiszka ha scritto:
@@ -167,9 +164,6 @@ int inet_aton(const char *cp, struct in_addr *ia);
#include bootp.h
#include tftp.h
-/* osdep.c */
-int qemu_socket(int domain, int type, int protocol);
-
#define ETH_ALEN 6
#define ETH_HLEN 14
diff --git a/slirp/tcp.h b/slirp/tcp.h
index b3817cb..8299603 100644
--- a/slirp/tcp.h
+++ b/slirp/tcp.h
@@ -45,6 +45,7 @@ typedef uint32_t tcp_seq;
* TCP header.
* Per RFC 793, September, 1981.
*/
+#define tcphdr slirp_tcphdr
Nice :). What about s/tcphdr/bsd_tcphdr/ or so for all slirp files?
Well, we have a precedent here:
/* Avoid conflicting with the libc insque() and remque(), which
have different prototypes. */
#define insque slirp_insque
#define remque slirp_remque
I know...
Even better would be enabling slirp to use an existing declaration. But that
looks trickier in first sight.
Yep, especially with no Autoconf.
struct tcphdr {
uint16_t th_sport; /* source port */
uint16_t th_dport; /* destination port */
@@ -58,12 +59,6 @@ struct tcphdr {
th_off:4; /* data offset */
#endif
uint8_t th_flags;
-#defineTH_FIN 0x01
-#defineTH_SYN 0x02
-#defineTH_RST 0x04
-#defineTH_PUSH 0x08
-#defineTH_ACK 0x10
-#defineTH_URG 0x20
uint16_t th_win;/* window */
uint16_t th_sum;/* checksum */
uint16_t th_urp;/* urgent pointer */
@@ -71,6 +66,16 @@ struct tcphdr {
#include tcp_var.h
+#ifndef TH_FIN
+#defineTH_FIN 0x01
+#defineTH_SYN 0x02
+#defineTH_RST 0x04
+#defineTH_PUSH 0x08
+#defineTH_ACK 0x10
+#defineTH_URG 0x20
+#endif
+
+#ifndef TCPOPT_EOL
#defineTCPOPT_EOL 0
#defineTCPOPT_NOP 1
#defineTCPOPT_MAXSEG 2
@@ -86,6 +91,7 @@ struct tcphdr {
#define TCPOPT_TSTAMP_HDR \
(TCPOPT_NOP24|TCPOPT_NOP16|TCPOPT_TIMESTAMP8|TCPOLEN_TIMESTAMP)
+#endif
Is there no portable header that offers those defines for us?
That would be netinet/tcp.h, but the problem is that there are some
differences. For example TCP_MSS is usually 512.
BTW the same could happen for ip.h, it's only that we never include it.
We need to include netinet/tcp.h outside slirp for TCP_NODELAY.
/*
* Default maximum segment size for TCP.
@@ -95,10 +101,13 @@ struct tcphdr {
*
* We make this 1460 because we only care about Ethernet in the qemu
context.
*/
+#undef TCP_MSS
#defineTCP_MSS 1460
+#undef TCP_MAXWIN
#defineTCP_MAXWIN 65535 /* largest value for (unscaled) window
*/
+#undef TCP_MAX_WINSHIFT
#define TCP_MAX_WINSHIFT 14 /* maximum window shift */
/*
Same here.
The direction is appreciated a lot, but I'm measuring only a moderate
overall hack-level reduction. ;)
Agreed, but one step at a time... this patch sticks to what it
promises, clean up conflicts with system headers. :)
Yeah, given that there is no sufficiently simple alternative, I guess I
have to accept this as is. :)
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 11/11 v10] introduce a new monitor command 'dump-guest-memory' to dump guest's memory
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 11/11 v10] introduce a new monitor command 'dump-guest-memory'
to dump guest's memory
Date: Tue, 20 Mar 2012 11:57:43 +0800
+static int write_elf64_header(DumpState *s)
+{
+Elf64_Ehdr elf_header;
+int ret;
+int endian = s-dump_info.d_endian;
+
+memset(elf_header, 0, sizeof(Elf64_Ehdr));
+memcpy(elf_header, ELFMAG, 4);
Use SELFMAG instead of 4.
+elf_header.e_ident[EI_CLASS] = ELFCLASS64;
+elf_header.e_ident[EI_DATA] = s-dump_info.d_endian;
+elf_header.e_ident[EI_VERSION] = EV_CURRENT;
+elf_header.e_type = cpu_convert_to_target16(ET_CORE, endian);
+elf_header.e_machine = cpu_convert_to_target16(s-dump_info.d_machine,
+ endian);
+elf_header.e_version = cpu_convert_to_target32(EV_CURRENT, endian);
+elf_header.e_ehsize = cpu_convert_to_target16(sizeof(elf_header),
endian);
+elf_header.e_phoff = cpu_convert_to_target64(sizeof(Elf64_Ehdr), endian);
+elf_header.e_phentsize = cpu_convert_to_target16(sizeof(Elf64_Phdr),
+ endian);
+elf_header.e_phnum = cpu_convert_to_target16(s-phdr_num, endian);
+if (s-have_section) {
+uint64_t shoff = sizeof(Elf64_Ehdr) + sizeof(Elf64_Phdr) *
s-sh_info;
+
+elf_header.e_shoff = cpu_convert_to_target64(shoff, endian);
+elf_header.e_shentsize = cpu_convert_to_target16(sizeof(Elf64_Shdr),
+ endian);
+elf_header.e_shnum = cpu_convert_to_target16(1, endian);
+}
+
+ret = s-f(0, elf_header, sizeof(elf_header), s-opaque);
+if (ret 0) {
+dump_error(s, dump: failed to write elf header.\n);
+return -1;
+}
+
+return 0;
+}
+
+static int write_elf32_header(DumpState *s)
+{
+Elf32_Ehdr elf_header;
+int ret;
+int endian = s-dump_info.d_endian;
+
+memset(elf_header, 0, sizeof(Elf32_Ehdr));
+memcpy(elf_header, ELFMAG, 4);
Also.
+elf_header.e_ident[EI_CLASS] = ELFCLASS32;
+elf_header.e_ident[EI_DATA] = endian;
+elf_header.e_ident[EI_VERSION] = EV_CURRENT;
+elf_header.e_type = cpu_convert_to_target16(ET_CORE, endian);
+elf_header.e_machine = cpu_convert_to_target16(s-dump_info.d_machine,
+ endian);
+elf_header.e_version = cpu_convert_to_target32(EV_CURRENT, endian);
+elf_header.e_ehsize = cpu_convert_to_target16(sizeof(elf_header),
endian);
+elf_header.e_phoff = cpu_convert_to_target32(sizeof(Elf32_Ehdr), endian);
+elf_header.e_phentsize = cpu_convert_to_target16(sizeof(Elf32_Phdr),
+ endian);
+elf_header.e_phnum = cpu_convert_to_target16(s-phdr_num, endian);
+if (s-have_section) {
+uint32_t shoff = sizeof(Elf32_Ehdr) + sizeof(Elf32_Phdr) *
s-sh_info;
+
+elf_header.e_shoff = cpu_convert_to_target32(shoff, endian);
+elf_header.e_shentsize = cpu_convert_to_target16(sizeof(Elf32_Shdr),
+ endian);
+elf_header.e_shnum = cpu_convert_to_target16(1, endian);
+}
+
+ret = s-f(0, elf_header, sizeof(elf_header), s-opaque);
+if (ret 0) {
+dump_error(s, dump: failed to write elf header.\n);
+return -1;
+}
+
+return 0;
+}
Thanks.
HATAYAMA, Daisuke
Re: [Qemu-devel] [PATCH V2 0/4] MIPS ASE DSP Support for Qemu
It would be better to break it up as patches each of which adds support for a coherent bite-sized subset of these instructions (so each individual patch includes the helper function declaration, implementation and translate.c changes for a smaller number of instructions). I am reading MIPS ASE DSP manual [1]. I think you can group those instructions as Chapter 4. MIPS DSP ASE Instruction Summary does. So you might have following patches, [1/] MIPS ASE DSP Support - Arithmetic Sub-class (~50 ins) [2/] MIPS ASE DSP Support - GPR-Based Shift Sub-class (~22 ins) [3/] MIPS ASE DSP Support - Multiply Sub-class (~38 ins) [4/] MIPS ASE DSP Support - Bit/ Manipulation Sub-class (~6 ins) [5/] MIPS ASE DSP Support - Compare-Pick Sub-class (~18 ins) [6/] MIPS ASE DSP Support - Accumulator and DSPControl Access Sub-class (~21 ins) [7/] MIPS ASE DSP Support - Indexed-Load and Branch Sub-class (4 ins) [8/] MIPS ASE DSP Testcase You can combine smaller subsets into a bigger one to make each patch equally sized. Each patch adding MIPS ASE DSP support should be self-contained, which means you can apply (and compile) them one-by-one, no error occured. I think testcase for all ASE DSP instructions can be just one patch. Regards, chenwj [1] MIPS32® Architecture for Programmers VolumeIV-e: The MIPS® DSP Application-Specific Extension to the MIPS32®Architecture http://www.mips.com/products/product-materials/processor/mips-architecture/ -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 01/15] hvm: Modify interface to support multiple ioreq server
On 22.03.12 at 16:59, Julien Grall julien.gr...@citrix.com wrote:
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -24,6 +24,8 @@
#include ../xen.h
#include ../trace.h
+#include hvm_info_table.h /* HVM_MAX_VCPUS */
+
/* Get/set subcommands: extra argument == pointer to xen_hvm_param struct.
*/
#define HVMOP_set_param 0
#define HVMOP_get_param 1
@@ -227,6 +229,53 @@ struct xen_hvm_inject_trap {
typedef struct xen_hvm_inject_trap xen_hvm_inject_trap_t;
DEFINE_XEN_GUEST_HANDLE(xen_hvm_inject_trap_t);
+#define HVMOP_register_ioreq_server 20
+struct xen_hvm_register_ioreq_server {
+domid_t domid; /* IN - domain to be serviced */
+unsigned int id;/* OUT - handle for identifying this server */
+};
+typedef struct xen_hvm_register_ioreq_server
xen_hvm_register_ioreq_server_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_register_ioreq_server_t);
+
+#define HVMOP_get_ioreq_server_buf_channel 21
+struct xen_hvm_get_ioreq_server_buf_channel {
+domid_t domid; /* IN - domain to be serviced */
+servid_t id; /* IN - handle from HVMOP_register_ioreq_server */
+unsigned int channel; /* OUT - buf ioreq channel */
+};
+typedef struct xen_hvm_get_ioreq_server_buf_channel
xen_hvm_get_ioreq_server_buf_channel_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_get_ioreq_server_buf_channel_t);
+
+#define HVMOP_map_io_range_to_ioreq_server 22
+struct xen_hvm_map_io_range_to_ioreq_server {
+domid_t domid; /* IN - domain to be serviced */
+uint8_t is_mmio;/* IN - MMIO or port IO? */
+servid_t id;/* IN - handle from HVMOP_register_ioreq_server
*/
+uint64_aligned_t s, e; /* IN - inclusive start and end of range */
+};
+typedef struct xen_hvm_map_io_range_to_ioreq_server
xen_hvm_map_io_range_to_ioreq_server_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_map_io_range_to_ioreq_server_t);
+
+#define HVMOP_unmap_io_range_from_ioreq_server 23
+struct xen_hvm_unmap_io_range_from_ioreq_server {
+domid_t domid; /* IN - domain to be serviced */
+uint8_t is_mmio;/* IN - MMIO or port IO? */
+servid_t id;/* IN - handle from HVMOP_register_ioreq_server
*/
+uint64_aligned_t addr; /* IN - address inside the range to remove */
+};
+typedef struct xen_hvm_unmap_io_range_from_ioreq_server
xen_hvm_unmap_io_range_from_ioreq_server_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_unmap_io_range_from_ioreq_server_t);
+
+#define HVMOP_register_pcidev 24
+struct xen_hvm_register_pcidev {
+domid_t domid; /* IN - domain to be serviced */
+servid_t id;/* IN - handle from HVMOP_register_ioreq_server */
+uint16_t bdf; /* IN - pci */
Can we please avoid the mistake of again not surfacing the PCI
segment in interface definitions, even if it may be required to be
zero for the immediate needs?
Jan
+};
+typedef struct xen_hvm_register_pcidev xen_hvm_register_pcidev_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_register_pcidev_t);
+
+
#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
#define HVMOP_get_mem_type15
[Qemu-devel] Bug report for kvm-kmod-3.3!
Hi all, I've built a guest image. It works well on KVM with a AMD X240 processor but failed with a intel E5620 processor. I am using kvm-kmod-3.3 and qemu-kvm-0.14.0. Here comes the report: kvm_emulate_insn: 0: 11a6d0: ff (prot32) failed kvm_userspace_exit: reason KVM_EXIT_INTERNAL_ERROR (17) kvm_inj_exception:#UD(0x0) kvm_entry: vcpu 0 kvm_exit: reason EPT_MISCONFIG rip 0x11a6d0 info 0 0 It bothers me so much and I would be much appreciated if someone can provide help. Thanks, katrina
[Qemu-devel] [Bug 962880] [NEW] having a tr_TR.UTF-8 locale creates problems during compile
Public bug reported: Default locale; /opt/test/qemu-1.0.1# locale LANG=tr_TR.UTF-8 LC_CTYPE=tr_TR.UTF-8 ... LC_IDENTIFICATION=tr_TR.UTF-8 LC_ALL= -- ./configure make . . . /opt/test/qemu-1.0.1/vl.c: In function 'main': /opt/test/qemu-1.0.1/vl.c:2248: hata: 'CONFIG_QEMU_CONFDIR' bildirilmemiş (bu işlevde ilk kullanımı) /opt/test/qemu-1.0.1/vl.c:2248: hata: (Bildirilmemiş her betimleyici görüldüğü her işlev /opt/test/qemu-1.0.1/vl.c:2248: hata: için sadece bir kez raporlanır.) /opt/test/qemu-1.0.1/vl.c:2248: hata: expected ')' before string constant /opt/test/qemu-1.0.1/vl.c:3090: hata: 'CONFIG_QEMU_DATADIR' bildirilmemiş (bu işlevde ilk kullanımı) make[1]: *** [vl.o] Hata 1 make: *** [subdir-libhw64] Hata 2 -- if we examine the config-host.h (look at the i characters) #define CONFIG_QEMU_PREFiX /usr/local #define CONFIG_QEMU_BiNDiR /usr/local/bin #define CONFIG_QEMU_LiBDiR /usr/local/lib #define CONFIG_QEMU_iNCLUDEDiR /usr/local/include #define CONFIG_QEMU_MANDiR /usr/local/share/man #define CONFIG_QEMU_DATADiR /usr/local/share/qemu #define CONFIG_QEMU_SYSCONFDiR /usr/local/etc #define CONFIG_QEMU_DOCDiR /usr/local/share/doc/qemu #define CONFIG_QEMU_CONFDiR /usr/local/etc/qemu --- changing LC_ALL and LC_LANG to POSIX (C) solves the problem. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/962880 Title: having a tr_TR.UTF-8 locale creates problems during compile Status in QEMU: New Bug description: Default locale; /opt/test/qemu-1.0.1# locale LANG=tr_TR.UTF-8 LC_CTYPE=tr_TR.UTF-8 ... LC_IDENTIFICATION=tr_TR.UTF-8 LC_ALL= -- ./configure make . . . /opt/test/qemu-1.0.1/vl.c: In function 'main': /opt/test/qemu-1.0.1/vl.c:2248: hata: 'CONFIG_QEMU_CONFDIR' bildirilmemiş (bu işlevde ilk kullanımı) /opt/test/qemu-1.0.1/vl.c:2248: hata: (Bildirilmemiş her betimleyici görüldüğü her işlev /opt/test/qemu-1.0.1/vl.c:2248: hata: için sadece bir kez raporlanır.) /opt/test/qemu-1.0.1/vl.c:2248: hata: expected ')' before string constant /opt/test/qemu-1.0.1/vl.c:3090: hata: 'CONFIG_QEMU_DATADIR' bildirilmemiş (bu işlevde ilk kullanımı) make[1]: *** [vl.o] Hata 1 make: *** [subdir-libhw64] Hata 2 -- if we examine the config-host.h (look at the i characters) #define CONFIG_QEMU_PREFiX /usr/local #define CONFIG_QEMU_BiNDiR /usr/local/bin #define CONFIG_QEMU_LiBDiR /usr/local/lib #define CONFIG_QEMU_iNCLUDEDiR /usr/local/include #define CONFIG_QEMU_MANDiR /usr/local/share/man #define CONFIG_QEMU_DATADiR /usr/local/share/qemu #define CONFIG_QEMU_SYSCONFDiR /usr/local/etc #define CONFIG_QEMU_DOCDiR /usr/local/share/doc/qemu #define CONFIG_QEMU_CONFDiR /usr/local/etc/qemu --- changing LC_ALL and LC_LANG to POSIX (C) solves the problem. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/962880/+subscriptions
[Qemu-devel] Bug report: emulation failed for kvm-3.3!
Hi all, I've built a guest image. It works well on KVM with a AMD X240 processor but failed with a intel E5620 processor. I am using kvm-kmod-3.3 and qemu-kvm-0.14.0. Actually it failed for all existing kvm version. Here comes the report: kvm_emulate_insn: 0: 11a6d0: ff (prot32) failed kvm_userspace_exit: reason KVM_EXIT_INTERNAL_ERROR (17) kvm_inj_exception:#UD(0x0) kvm_entry: vcpu 0 kvm_exit: reason EPT_MISCONFIG rip 0x11a6d0 info 0 0 It bothers me so much and I would be much appreciated if someone can provide help. Thanks, katrina
[Qemu-devel] [Bug 918791] Re: qemu-kvm dies when using vmvga driver and unity in the guest
Hello Jamie, or anyone else affected, Accepted qemu-kvm into oneiric-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance! ** Changed in: qemu-kvm (Ubuntu Oneiric) Status: New = Fix Committed ** Tags added: verification-needed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/918791 Title: qemu-kvm dies when using vmvga driver and unity in the guest Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “xserver-xorg-video-vmware” package in Ubuntu: Invalid Status in “qemu-kvm” source package in Oneiric: Fix Committed Status in “xserver-xorg-video-vmware” source package in Oneiric: Invalid Status in “qemu-kvm” source package in Precise: Fix Released Status in “xserver-xorg-video-vmware” source package in Precise: Invalid Bug description: = SRU Justification: 1. impact: kvm crashes 2. Development fix: don't allow attempts to set_bit to negative offsets 3. Stable fix: same as development fix 4. Test case (see below) 5. Regression potential: if the patch is wrong, graphics for vmware vga over vnc could get messed up = 12.04's qemu-kvm has been unstable for me and Marc Deslauriers and I figured out it has something to do with the interaction of qemu-kvm, unity and the vmvga driver. This is a regression over qemu-kvm in 11.10. TEST CASE: 1. start a VM that uses unity (eg, 11.04, 11.10 or 12.04). My tests use unity-2d on an amd64 host and amd64 guests 2. on 11.04 and 11.10, open empathy via the messaging indicator and click 'Chat'. On 12.04, open empathy via the messaging indicator and click 'Chat', close the empathy wizard, move the empathy window over the unity luancher (so it autohides), then do 'ctrl+alt+t' to open a terminal When the launcher tries to auto(un)hide, qemu-kvm dies with this: [10574.958149] do_general_protection: 132 callbacks suppressed [10574.958154] kvm[13192] general protection ip:7fab9680ea0f sp:74440148 error:0 in qemu-system-x86_64[7fab966c4000+2c9000] Relevant libvirt xml: video model type='vmvga' vram='9216' heads='1'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video If I change to using 'cirrus', then qemu-kvm no longer crashes. Eg: video model type='cirrus' vram='9216' heads='1'/ alias name='video0'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video The workaround is therefore to use the cirrus driver instead of vmvga, however being able to kill qemu-kvm in this manner is not ideal. Also, unfortunately unity-2d does not run with with cirrus driver under 11.04, so the security and SRU teams are unable to properly test updates in GUI applications under unity when using the current 12.04 qemu-kvm. I tried to report this via apport, but apport complained about a CRC error, so I could not. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/918791/+subscriptions
Re: [Qemu-devel] [PATCH 2/2] QEMU kvm: Add support to get/set vcpu unhalt msr to aid migration
On 03/23/2012 02:27 PM, Jan Kiszka wrote: On 2012-03-23 09:23, Raghavendra K T wrote: From: Raghavendra K Traghavendra...@linux.vnet.ibm.com MSR_KVM_PV_UNHALT tells whether vcpu is unhalted, which needs to be used during migration. Err, and where is it actually saved to/restored from the vmstate? You are lacking an extension of the CPU vmstate, preferably via a substate. See e.g. cpu/async_pf_msr. Thanks Jan for review, I 'll check that.
Re: [Qemu-devel] [PATCH 11/11 v10] introduce a new monitor command 'dump-guest-memory' to dump guest's memory
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 11/11 v10] introduce a new monitor command 'dump-guest-memory'
to dump guest's memory
Date: Tue, 20 Mar 2012 11:57:43 +0800
+/* get the memory's offset in the vmcore */
+static target_phys_addr_t get_offset(target_phys_addr_t phys_addr,
+ DumpState *s)
+{
+RAMBlock *block;
+target_phys_addr_t offset = s-memory_offset;
+int64_t size_in_block, start;
+
+if (s-has_filter) {
+if (phys_addr s-begin || phys_addr = s-begin + s-length) {
+return -1;
+}
+}
+
+QLIST_FOREACH(block, ram_list.blocks, next) {
+if (s-has_filter) {
+if (block-offset = s-begin + s-length ||
+block-offset + block-length = s-begin) {
+/* This block is out of the range */
+continue;
+}
+
+if (s-begin = block-offset) {
+start = block-offset;
+} else {
+start = s-begin;
+}
+
+size_in_block = block-length - (start - block-offset);
+if (s-begin + s-length block-offset + block-length) {
+size_in_block -= block-offset + block-length -
+ (s-begin + s-length);
+}
+} else {
+start = block-offset;
+size_in_block = block-length;
+}
+
+if (phys_addr = start phys_addr start + size_in_block) {
+return phys_addr - start + offset;
+}
+
+offset += size_in_block;
+}
+
+return -1;
+}
OK. -1 is assigned to offset when the corresponding memory is filtered
and so not contained in dumpfile. But please give -1 a name. I want
the name to tell me the data is filterred.
Also, I couldn't imagine get_offset() does filtering processing. This
is important for the purspective of dump because there's data not
saved in dumpfile. Could you claify this in some way? By moving
filtering processing to the outside, or splitting it into anotehr
funciton.
Thanks.
HATAYAMA, Daisuke
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 03/15] hvm-pci: Handle PCI config space in Xen
On 22.03.12 at 16:59, Julien Grall julien.gr...@citrix.com wrote:
--- /dev/null
+++ b/xen/arch/x86/hvm/pci_emul.c
@@ -0,0 +1,147 @@
+#include asm/hvm/support.h
+#include xen/hvm/pci_emul.h
+#include xen/pci.h
+#include xen/sched.h
+#include xen/xmalloc.h
+
+#define PCI_DEBUGSTR %x:%x.%x
+#define PCI_DEBUG(bdf) ((bdf) 16) 0xff, ((bdf) 11) 0x1f, ((bdf)
8)
0x7
+
+static int handle_config_space(int dir, uint32_t port, uint32_t bytes,
+ uint32_t *val)
+{
+uint32_t pci_cf8;
+struct pci_device_emul *pci;
+ioreq_t *p = get_ioreq(current);
+int rc = X86EMUL_UNHANDLEABLE;
+struct vcpu *v = current;
+
+spin_lock(v-domain-arch.hvm_domain.pci_root.pci_lock);
+
+if (port == 0xcf8)
You need to be considerably more careful here: This code should
handle only 32-bit wide aligned accesses, and you need to make
sure that everything else still gets properly forwarded to qemu
(so that e.g. port CF9 could still be properly emulated if desired).
+{
+rc = X86EMUL_OKAY;
+v-arch.hvm_vcpu.pci_cf8 = *val;
+goto end_handle;
+}
+
+pci_cf8 = v-arch.hvm_vcpu.pci_cf8;
+
+/* Retrieve PCI */
+pci = v-domain-arch.hvm_domain.pci_root.pci;
+
+while (pci !PCI_CMP_BDF(pci, pci_cf8))
+pci = pci-next;
Is there a reasonably low enforced boundary on the number
of devices? Otherwise, a linear lookup would seem overly
simple to me.
Further, with how PCI_CMP_BDF() is defined, you're doing the
wrong thing here anyway - bit 31 is required to be set for the
port CFC access to be a config space one. Plus there's an AMD
extension to this interface, so I think other than shifting out
the low 8 bits and checking that the high bit is set, you shouldn't
do any other masking here.
Jan
+
+/* We just fill the ioreq, hvm_send_assist_req will send the request */
+if (unlikely(pci == NULL))
+{
+*val = ~0;
+rc = X86EMUL_OKAY;
+goto end_handle;
+}
+
+p-type = IOREQ_TYPE_PCI_CONFIG;
+p-addr = (pci_cf8 ~3) + (p-addr 3);
+
+set_ioreq(v, pci-server-ioreq, p);
+
+end_handle:
+spin_unlock(v-domain-arch.hvm_domain.pci_root.pci_lock);
+return rc;
+}
[Qemu-devel] [PATCH] spice: fix spice_server_set_name call.
spice_server_set_name can't handle the case of getting NULL passed in. Add a check and pass in an empty string instead. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- ui/spice-core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ui/spice-core.c b/ui/spice-core.c index a468524..50c2765 100644 --- a/ui/spice-core.c +++ b/ui/spice-core.c @@ -690,7 +690,7 @@ void qemu_spice_init(void) qemu_opt_foreach(opts, add_channel, tls_port, 0); #if SPICE_SERVER_VERSION = 0x000a02 /* 0.10.2 */ -spice_server_set_name(spice_server, qemu_name); +spice_server_set_name(spice_server, qemu_name ?: ); spice_server_set_uuid(spice_server, qemu_uuid); #endif -- 1.7.1
Re: [Qemu-devel] [PATCH 10/11 v10] make gdb_id() generally avialable
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 10/11 v10] make gdb_id() generally avialable
Date: Tue, 20 Mar 2012 11:56:38 +0800
The following patch also needs this API, so make it generally avialable
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
gdbstub.c |9 -
gdbstub.h |9 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/gdbstub.c b/gdbstub.c
index f4e97f7..7f8ac2f 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1939,15 +1939,6 @@ static void gdb_set_cpu_pc(GDBState *s, target_ulong
pc)
#endif
}
-static inline int gdb_id(CPUArchState *env)
-{
-#if defined(CONFIG_USER_ONLY) defined(CONFIG_USE_NPTL)
-return env-host_tid;
-#else
-return env-cpu_index + 1;
-#endif
-}
-
static CPUArchState *find_cpu(uint32_t thread_id)
{
CPUArchState *env;
diff --git a/gdbstub.h b/gdbstub.h
index b44e275..f82ec70 100644
--- a/gdbstub.h
+++ b/gdbstub.h
@@ -30,6 +30,15 @@ void gdb_register_coprocessor(CPUArchState *env,
gdb_reg_cb get_reg, gdb_reg_cb set_reg,
int num_regs, const char *xml, int g_pos);
+static inline int gdb_id(CPUArchState *env)
+{
+#if defined(CONFIG_USER_ONLY) defined(CONFIG_USE_NPTL)
+return env-host_tid;
+#else
+return env-cpu_index + 1;
+#endif
+}
+
It seems to me more reasonable to newly introduce helper function
cpu_index(), then use it in gdb_id() and in qemu dump.
Thanks.
HATAYAMA, Daisuke
Re: [Qemu-devel] Spice bug with qemu_name
On Fri, Mar 23, 2012 at 08:10:36AM +, Lee Essen wrote: Hi, I think I've found a bug with the way that spice uses qemu_name. qemu_name is a char *, that's only set to if -name is given (and then the arg is strdup'd), otherwise it's not set properly. In ui/spice_core.c spice_server_set_name() is called with qemu_name, which if not set causes a core dump. - lwp# 1 / thread# 1 What's lwp? fd7fff168090 strlen () + 30 fd7ffa6b5d7e spice_server_set_name () + 2b 0068fab1 qemu_spice_init () + 753 0062a58f main () + 2a31 00519c5c _start () + 6c - lwp# 2 / thread# 2 fd7fff1f9b2a __sigtimedwait () + a fd7fff1e626d sigwait () + d fd7fff1d1b31 __posix_sigwait () + 31 0057572c sigwait_compat () + 68 fd7fff1f39a3 _thrp_setup () + 83 fd7fff1f3ca0 _lwp_start () There's a similar situation with qemu_uuid, however because it's not a pointer I'm assuming you end up with all zero's, which is probably ok behaviour. I haven't provided a patch since I don't really know which way you want to fix this ... either provide a sensible default if it's not set, or default to NULL and check it in the spice code. Regards, Lee.
Re: [Qemu-devel] Bug report for kvm-kmod-3.3!
On 2012-03-23 09:19, Katrina Austin wrote: Hi all, I've built a guest image. It works well on KVM with a AMD X240 processor but failed with a intel E5620 processor. I am using kvm-kmod-3.3 and qemu-kvm-0.14.0. Here comes the report: kvm_emulate_insn: 0: 11a6d0: ff (prot32) failed kvm_userspace_exit: reason KVM_EXIT_INTERNAL_ERROR (17) kvm_inj_exception:#UD(0x0) kvm_entry: vcpu 0 kvm_exit: reason EPT_MISCONFIG rip 0x11a6d0 info 0 0 It bothers me so much and I would be much appreciated if someone can provide help. Could it be that your guest image uses instructions that are only available on AMD processors? Or is this a regression from previous KVM versions. If yes, which one worked? Further questions in that case: - Could you retest with KVM over a 3.3 kernel, i.e. without kvm-kmod? Does that also faile? - What is your host kernel version? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] Thoughts around dtrace linking...
On Thu, Mar 22, 2012 at 05:00:53PM +, Lee Essen wrote: On 22/03/2012 16:28, Stefan Hajnoczi wrote: On Wed, Mar 21, 2012 at 1:01 PM, Andreas Färberafaer...@suse.de wrote: Hi, Am 21.03.2012 11:45, schrieb Lee Essen: I've been trying to find a sensible way to solve the Solaris/Illumos dtrace requirement to pass all the objs to the dtrace command so that the resultant object file contains all the symbols needed to properly link the relevant binary. The easiest way to do this is just prior to linking the binary, so something like this (in rules.mak): LINK = $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $(sort $(1)) $(LIBS), LINK $(TARGET_DIR)$@) DTRACE = $(call quiet-command,dtrace $(CONFIG_DTRACE_FLAGS) -o $(1)-dtrace.o -G -s $(2) $(3), GEN $(TARGET_DIR)$(1)-dtrace.o) %$(EXESUF): %.o $(call DTRACE,$*,trace-dtrace.dtrace,$^) $(call LINK,$^ $*-dtrace.o) What I find slightly surprising is that you're putting the -dtrace.o generation step as a command in the executable's target. I would expect the -dtrace.o to be a target itself, which also allows make to use it's timestamping on dependencies to ensure we only rebuild when necessary. i.e. specifying dependencies is the make way of doing things, and I think we should try where possible. Yes, that's the way I had it the first time around, but it means quite a bit more complexity in the makefiles and having to touch each executable section, I had thought the rules.mak approach was cleaner. For example: qemu-ga-all-objs=qemu-ga.o $(qga-obj-y) $(tools-obj-y) $(qapi-obj-y) $(qobject-obj-y) $(version-obj-y) $(QGALIB_OBJ) #ifdef USE_SOLARIS_DTRACE_APPROACH qemu-ga.dtrace.o: $(qemu-ga-all-objs) [assuming rule in rules.mak] qemu-ga-all-objs+=qemu-ga.dtrace.o #endif qemu-ga$(EXESUF): qemu-ga-all-objs There's also a complication with the creation of the .dtrace.o in Makefile.target because of it being one level down in the directory structure and needing access to trace-dtrace.dtrace. None of it is unsurmountable, but it gets a bit untidy. TBH, I can do this either way, just let me know which approach you prefer and I'll put a patch together. Obviously with the relevant tests around it to check the trace backend, and also an adjustment in Makefile.target to cause the right thing to happen for each target. Or, is there a better way? The two issues I see (as info for Stefan et al.) are a) compiling DTrace probes into .o files requires linking those objects with that additional .o file to avoid linker errors (even for tools where using DTrace probes does not seem to make much sense), qemu-tool binaries are built with tracing enabled. But this is a good point, we need to check that all binaries buildable from the QEMU source tree continue to work with this change. Actually this is a good point ... if you are thinking of removing tracing from some of the binaries then the rules.mak approach doesn't really make sense. Let me know how you want to proceed. If you're able to try out the dependency-based approach that would be a good starting point. You may hit a point where it turns out to be too ugly or complicated - in that case, please post your progress and maybe someone can help find a way to structure it. I'm not a make guru but I can try to give feedback on your patches. Stefan
Re: [Qemu-devel] [PATCH] block: add the support to drain throttled requests
On Thu, Mar 22, 2012 at 07:07:52PM +, Chris Webb wrote: Stefan Hajnoczi stefa...@linux.vnet.ibm.com writes: Yesterday I only posted an analysis of the bug but here are some thoughts on how to move forward. Throttling itself is not the problem. We've known that synchronous operations in the vcpu thread are a problem long before throttling. This is just another reason to convert device emulation to use asynchronous interfaces. Here is the list of device models that perform synchronous block I/O: hw/fdc.c hw/ide/atapi.c hw/ide/core.c hw/nand.c hw/onenand.c hw/pflash_cfi01.c hw/pflash_cfi02.c hw/sd.c Zhi Hui Li is working on hw/fdc.c and recently sent a patch. I think it's too close to QEMU 1.1 to convert all the remaining devices and test them properly before the soft-freeze. But it's probably possible to convert IDE before the soft-freeze. IDE is the only of these that would affect us as a typical user of throttling. The others aren't really the kind of devices which you'd be using in a hosting setting in any case. Can you check whether your Windows guest has DMA or PIO mode enabled? http://msdn.microsoft.com/en-us/windows/hardware/gg463526 Stefan
Re: [Qemu-devel] [PATCH] Replace bdrv_* to bdrv_aio_* functions in pio mode in fdc.c.
On Fri, Mar 23, 2012 at 03:07:20PM +0800, Li Zhi Hui wrote:
Replace bdrv_* to bdrv_aio_* functions in pio mode in fdc.c.
Signed-off-by: Li Zhi Hui zhihu...@linux.vnet.ibm.com
---
hw/fdc.c | 117 +++--
1 files changed, 90 insertions(+), 27 deletions(-)
I have posted detailed comments below. The high-level point is to look
back at the datasheet because the information needed to implement
asynchronous I/O is only available there. Since hw/fdc.c is synchronous
today it omits steps in the request lifecycle that are necessary for
asynchronous I/O. It is impossible to do asynchronous I/O by
refactoring hw/fdc.c, it won't produce the semantics from the datasheet.
You need to study the request lifecycle in the datasheet and use that
information to implement asynchronous I/O in hw/fdc.c.
diff --git a/hw/fdc.c b/hw/fdc.c
index a0236b7..5e855fd 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -1301,12 +1301,42 @@ static int fdctrl_transfer_handler (void *opaque, int
nchan,
return len;
}
+enum {
+FD_DATA_IDLE,
+FD_DATA_WORKING,
+FD_DATA_FIN,
+};
+
+int data_status[MAX_FD];
This would need to be a FDCtrl field so that each FDrive on each fdc
instance has it's own data_status. If you leave it global then it's not
possible to use multiple fdc devices at the same time.
+
+static void fdctrl_read_pio_cb(void *opaque, int ret)
+{
+FDCtrl *fdctrl = opaque;
+FDrive *cur_drv;
+
+if (ret 0) {
+cur_drv = get_cur_drv(fdctrl);
+FLOPPY_DPRINTF(error getting sector %d\n,
+ fd_sector(cur_drv));
+/* Sure, image size is too small... */
+memset(fdctrl-fifo, 0, FD_SECTOR_LEN);
+data_status[fdctrl-cur_drv] = FD_DATA_IDLE;
+goto end;
+}
+data_status[fdctrl-cur_drv] = FD_DATA_FIN;
+
+end:
+return;
+}
+
/* Data register : 0x05 */
static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
{
FDrive *cur_drv;
uint32_t retval = 0;
int pos;
+QEMUIOVector qiov;
+struct iovec iov;
cur_drv = get_cur_drv(fdctrl);
fdctrl-dsr = ~FD_DSR_PWRDOWN;
@@ -1318,17 +1348,30 @@ static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
if (fdctrl-msr FD_MSR_NONDMA) {
pos %= FD_SECTOR_LEN;
if (pos == 0) {
-if (fdctrl-data_pos != 0)
-if (!fdctrl_seek_to_next_sect(fdctrl, cur_drv)) {
-FLOPPY_DPRINTF(error seeking to next sector %d\n,
- fd_sector(cur_drv));
-return 0;
+switch (data_status[fdctrl-cur_drv]) {
+case FD_DATA_IDLE:
+if (fdctrl-data_pos != 0) {
+if (!fdctrl_seek_to_next_sect(fdctrl, cur_drv)) {
+FLOPPY_DPRINTF(error seeking to next sector %d\n,
+ fd_sector(cur_drv));
+goto end;
+}
}
-if (bdrv_read(cur_drv-bs, fd_sector(cur_drv), fdctrl-fifo, 1)
0) {
-FLOPPY_DPRINTF(error getting sector %d\n,
- fd_sector(cur_drv));
-/* Sure, image size is too small... */
-memset(fdctrl-fifo, 0, FD_SECTOR_LEN);
+iov.iov_base = fdctrl-fifo;
+iov.iov_len = FD_SECTOR_LEN;
+qemu_iovec_init_external(qiov, iov, 1);
+bdrv_aio_readv(cur_drv-bs, fd_sector(cur_drv),
+qiov, 1, fdctrl_read_pio_cb, fdctrl);
+data_status[fdctrl-cur_drv] = FD_DATA_WORKING;
+goto end;
+case FD_DATA_WORKING:
+goto end;
+case FD_DATA_FIN:
+data_status[fdctrl-cur_drv] = FD_DATA_IDLE;
+break;
+default:
+data_status[fdctrl-cur_drv] = FD_DATA_IDLE;
+goto end;
}
Does this approach follow the datasheet? You are returning 0 on each
goto end so the guest will think it is reading zeroes from the floppy.
When fdctrl_read_data() gets called we *must* have valid data in the
fifo - or be able to tell the guest to wait using status register bits.
}
}
@@ -1347,6 +1390,7 @@ static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
}
FLOPPY_DPRINTF(data register: 0x%02x\n, retval);
+end:
return retval;
}
@@ -1759,10 +1803,38 @@ static const struct {
/* Associate command to an index in the 'handlers' array */
static uint8_t command_to_handler[256];
+static void fdctrl_write_pio_cb(void *opaque, int ret)
+{
+FDCtrl *fdctrl = opaque;
+FDrive *cur_drv;
+
+cur_drv = get_cur_drv(fdctrl);
+if (ret 0) {
+FLOPPY_ERROR(writing sector %d\n, fd_sector(cur_drv));
+goto end;
+}
+if (!fdctrl_seek_to_next_sect(fdctrl, cur_drv)) {
Re: [Qemu-devel] [QEMU][RFC PATCH 1/6] option: Add -xen-dmid
On Thu, 22 Mar 2012, Jan Kiszka wrote: On 2012-03-22 17:01, Julien Grall wrote: With this option, QEMU knows it's ID and can retrieve it's configuration from XenStore. Isn't this better modeled as a (Xen) machine option? I'd like to avoid more special command line switch proliferation. I agree.
Re: [Qemu-devel] [PATCH] block: add the support to drain throttled requests
Stefan Hajnoczi stefa...@linux.vnet.ibm.com writes: On Thu, Mar 22, 2012 at 07:07:52PM +, Chris Webb wrote: Stefan Hajnoczi stefa...@linux.vnet.ibm.com writes: Yesterday I only posted an analysis of the bug but here are some thoughts on how to move forward. Throttling itself is not the problem. We've known that synchronous operations in the vcpu thread are a problem long before throttling. This is just another reason to convert device emulation to use asynchronous interfaces. Here is the list of device models that perform synchronous block I/O: hw/fdc.c hw/ide/atapi.c hw/ide/core.c hw/nand.c hw/onenand.c hw/pflash_cfi01.c hw/pflash_cfi02.c hw/sd.c Zhi Hui Li is working on hw/fdc.c and recently sent a patch. I think it's too close to QEMU 1.1 to convert all the remaining devices and test them properly before the soft-freeze. But it's probably possible to convert IDE before the soft-freeze. IDE is the only of these that would affect us as a typical user of throttling. The others aren't really the kind of devices which you'd be using in a hosting setting in any case. Can you check whether your Windows guest has DMA or PIO mode enabled? http://msdn.microsoft.com/en-us/windows/hardware/gg463526 Hi. We were producing the IDE assert()s and deadlocks with linux kernels. Although I believe the same symptoms exist on windows, I haven't actually tested it myself. Typically they would show up in the 16-bit bootloader code, even before the 32-bit OS has started. Cheers, Chris.
Re: [Qemu-devel] [QEMU][RFC PATCH 2/6] xen: Add functions to register PCI and IO in Xen
On Thu, 22 Mar 2012, Julien Grall wrote: Add interface for the new xen hypercalls Signed-off-by: Julien Grall julien.gr...@citrix.com --- hw/xen.h |3 +++ xen-all.c |2 ++ xen-stub.c | 13 + 3 files changed, 18 insertions(+), 0 deletions(-) diff --git a/hw/xen.h b/hw/xen.h index b056b13..a76616f 100644 --- a/hw/xen.h +++ b/hw/xen.h @@ -35,6 +35,9 @@ static inline int xen_enabled(void) int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num); void xen_piix3_set_irq(void *opaque, int irq_num, int level); void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len); +int xen_register_pcidev(PCIDevice *pci_dev); +void xen_map_iorange(uint64_t addr, uint64_t size, int is_mmio); +void xen_unmap_iorange(uint64_t addr, uint64_t size, int is_mmio); void xen_cmos_set_s3_resume(void *opaque, int irq, int level); qemu_irq *xen_interrupt_controller_init(void); you should add to this patch the Xen version of these functions too, otherwise it will break Xen builds.
Re: [Qemu-devel] [PATCH] block: add the support to drain throttled requests
On Fri, Mar 23, 2012 at 10:43 AM, Chris Webb ch...@arachsys.com wrote: Stefan Hajnoczi stefa...@linux.vnet.ibm.com writes: On Thu, Mar 22, 2012 at 07:07:52PM +, Chris Webb wrote: Stefan Hajnoczi stefa...@linux.vnet.ibm.com writes: Yesterday I only posted an analysis of the bug but here are some thoughts on how to move forward. Throttling itself is not the problem. We've known that synchronous operations in the vcpu thread are a problem long before throttling. This is just another reason to convert device emulation to use asynchronous interfaces. Here is the list of device models that perform synchronous block I/O: hw/fdc.c hw/ide/atapi.c hw/ide/core.c hw/nand.c hw/onenand.c hw/pflash_cfi01.c hw/pflash_cfi02.c hw/sd.c Zhi Hui Li is working on hw/fdc.c and recently sent a patch. I think it's too close to QEMU 1.1 to convert all the remaining devices and test them properly before the soft-freeze. But it's probably possible to convert IDE before the soft-freeze. IDE is the only of these that would affect us as a typical user of throttling. The others aren't really the kind of devices which you'd be using in a hosting setting in any case. Can you check whether your Windows guest has DMA or PIO mode enabled? http://msdn.microsoft.com/en-us/windows/hardware/gg463526 Hi. We were producing the IDE assert()s and deadlocks with linux kernels. Although I believe the same symptoms exist on windows, I haven't actually tested it myself. Typically they would show up in the 16-bit bootloader code, even before the 32-bit OS has started. Okay, that makes sense. Bootloaders and the BIOS may use the simplest driver interface - which may be PIO in the case. I asked because the IDE DMA code path should work with I/O throttling and Windows is known for sometimes falling back to the PIO code path when some heuristics trigger. Stefan
Re: [Qemu-devel] [QEMU][RFC PATCH 4/6] xen-pci: Register PCI in Xen
On Thu, 22 Mar 2012, Anthony Liguori wrote:
On 03/22/2012 11:01 AM, Julien Grall wrote:
QEMU will now register PCI in Xen. It will usefull to forward
IO config space to the right QEMU.
Before to register a PCI device, QEMU will check with XenStore if it is
autorized to register the PCI associate to a given BDF.
Signed-off-by: Julien Gralljulien.gr...@citrix.com
As a general rule, any time you call to XenStore from QEMU, you're doing
something wrong.
You should explicitly launch QEMU with the PCI devices that you want it to
have.
If there are platform devices you don't want it to have, then you need to
construct a machine that lacks those devices.
Random hooks in non-Xen code that call into XenStore are always wrong.
Maybe the best thing to do is to have a set of machine specific options
to select what devices need to be built in the machine.
Most devices already can be dynamically selected: NICs, usb, acpi,
cirrus, etc.
We already have a Xen machine (xenfv_machine) that uses pc_init1 to
initialize it.
We could have a simple bitmask to determine what devices need to be
enabled, then in pc_init1 we could have something like:
if (devices VGA_ENABLE) {
pc_vga_init();
}
Given the number of enable variable already present in the code
(pci_enabled, acpi_enabled, usb_enabled, xen_enabled,
cirrus_vga_enabled, ...), it might end up actually making the code more
readable. The flexibility could end up being useful in the generic case
as well, for testing if nothing else.
We would still need to call xc_hvm_register_pcidev to register PCI
devices in Xen, but we wouldn't expect to fail unless there was a
misconfiguration somewhere. In that case we could just exit.
Now the problem is: there isn't a simple way to specify the BDF where
you want to create the device; pci_create_simple takes a devfn but most
of the higher level functions (pc_vga_init, pci_nic_init_nofail, ...)
don't export the parameter at the moment.
We would need to be able to tell pc_vga_init where to create the card,
so we would have to export the devfn as a parameter.
Re: [Qemu-devel] [QEMU][RFC PATCH 6/6] xen: handle qemu disaggregation
On Thu, 22 Mar 2012, Julien Grall wrote:
* Register QEMU in Xen as server
* Retrieve it's own shared pages
* Check if the page is already mapping before to populate
Signed-off-by: Julien Grall julien.gr...@citrix.com
---
xen-all.c | 62 ++--
1 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index 2d001b8..6b7acd7 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -61,6 +61,45 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t
*shared_page, int vcpu)
}
# define FMT_ioreq_size u
#endif
+#if __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
At this point, given that we are close to Xen 4.2 I would make this
if __XEN_LATEST_INTERFACE_VERSION__ 0x00040300
+static inline unsigned long xen_buffered_iopage()
+{
+unsigned long pfn;
+
+xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_PFN, pfn);
+
+return pfn;
+}
+
+static inline unsigned long xen_iopage(void)
+{
+unsigned long pfn;
+
+xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_PFN, pfn);
+
+return pfn;
+}
+#else
+static inline unsigned long xen_buffered_iopage(void)
+{
+unsigned long pfn;
+
+xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IO_PFN_FIRST, pfn);
+pfn += (serverid - 1) * 2 + 2;
+return pfn;
+}
+
+static inline unsigned long xen_iopage(void)
+{
+unsigned long pfn;
+
+xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IO_PFN_FIRST, pfn);
+pfn += (serverid - 1) * 2 + 1;
+
+return pfn;
Shouldn't these be
pfn += serverid * 2;
and
pfn += serverid * 2 + 1;
Are you numbering serverid starting from 1?
+#endif
#define BUFFER_IO_MAX_DELAY 100
@@ -349,6 +388,10 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
MemoryRegion *mr)
return;
}
+if (xen_map_cache(ram_addr, size, 0)) {
+return;
+}
why?
trace_xen_ram_alloc(ram_addr, size);
nr_pfn = size TARGET_PAGE_BITS;
@@ -1046,7 +1089,14 @@ static void xenstore_record_dm_state(struct xs_handle
*xs, const char *state)
exit(1);
}
-snprintf(path, sizeof (path), /local/domain/0/device-model/%u/state,
xen_domid);
+if (!xen_dmid) {
+snprintf(path, sizeof (path),
/local/domain/0/device-model/%u/state, xen_domid);
+}
+else {
+snprintf(path, sizeof (path), /local/domain/0/dms/%u/%u/state,
+ xen_domid, xen_dmid);
+}
+
if (!xs_write(xs, XBT_NULL, path, state, strlen(state))) {
fprintf(stderr, error recording dm state\n);
exit(1);
@@ -1077,6 +1127,7 @@ static void xen_change_state_handler(void *opaque, int
running,
RunState state)
{
if (running) {
+is_running = 1;
/* record state running */
xenstore_record_dm_state(xenstore, running);
}
@@ -1137,7 +1188,12 @@ int xen_hvm_init(void)
state-suspend.notify = xen_suspend_notifier;
qemu_register_suspend_notifier(state-suspend);
-xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN, ioreq_pfn);
+rc = xc_hvm_register_ioreq_server(xen_xc, xen_domid, serverid);
+
+if (rc)
+hw_error(registered server returned error %d, rc);
+
+ioreq_pfn = xen_iopage();
DPRINTF(shared page at pfn %lx\n, ioreq_pfn);
state-shared_page = xc_map_foreign_range(xen_xc, xen_domid,
XC_PAGE_SIZE,
PROT_READ|PROT_WRITE,
ioreq_pfn);
@@ -1146,7 +1202,7 @@ int xen_hvm_init(void)
errno, xen_xc);
}
-xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_PFN, ioreq_pfn);
+ioreq_pfn = xen_buffered_iopage();
DPRINTF(buffered io page at pfn %lx\n, ioreq_pfn);
state-buffered_io_page = xc_map_foreign_range(xen_xc, xen_domid,
XC_PAGE_SIZE,
PROT_READ|PROT_WRITE,
ioreq_pfn);
--
Julien Grall
Re: [Qemu-devel] [PATCH V3 0/7] Make QED with live migration safe
On Fri, Mar 23, 2012 at 7:36 AM, Benoît Canet benoit.ca...@gmail.com wrote: This is the third version of a patchset aiming at making the combined usage of QED and live migration safe. v3: -qed: Drop the flags qed structure member and use bs-open_flags to reopen (stefana) -qed: When opening honor flags parameter instead of bs-open_flags v2: -The block layer is not aware anymore of the migration state. (stefanha) -No bdrv_invalidate_cache renaming since the semantic do not change. (stefanha) -The qed bdrv_invalidate_cache function does a reopening of the image to flush metadata and to do the image integrity check. (stefanha) Benoît Canet (7): block: Add new BDRV_O_INCOMING flag to notice incoming live migration block: add a function to clear incoming live migration flags blockdev: open images with BDRV_O_INCOMING on incoming live migration qed: add bdrv_invalidate_cache to be called after incoming live migration migration: clear BDRV_O_INCOMING flags on end of incoming live migration qed: honor BDRV_O_INCOMING for incoming live migration qed: remove incoming live migration blocker block.c | 9 + block.h | 3 +++ block/qed.c | 24 +--- block/qed.h | 2 -- blockdev.c | 4 migration.c | 1 + 6 files changed, 30 insertions(+), 13 deletions(-) I tested qed live migration as well as confirming that bs-open_flags BDRV_O_INCOMING works correctly in gdb. Reviewed-by: Stefan Hajnoczi stefa...@gmail.com
Re: [Qemu-devel] [PATCH] block: add the support to drain throttled requests
On Fri, Mar 23, 2012 at 11:02 AM, Richard Davies rich...@arachsys.com wrote: Stefan Hajnoczi wrote: Hi. We were producing the IDE assert()s and deadlocks with linux kernels. Although I believe the same symptoms exist on windows, I haven't actually tested it myself. Typically they would show up in the 16-bit bootloader code, even before the 32-bit OS has started. Okay, that makes sense. Bootloaders and the BIOS may use the simplest driver interface - which may be PIO in the case. I asked because the IDE DMA code path should work with I/O throttling and Windows is known for sometimes falling back to the PIO code path when some heuristics trigger. Whilst the bootloader was the easiest place for us to replicate this deadlock, we have also seen it with running Linux VMs. Older Linux kernels (e.g. CentOS 5) will fall back to PIO mode on IDE devices if they experience storage timeouts (e.g. due to heavy contention of underlying storage from other VMs). Hence, the IO limits deadlock can lead to running Linux VMs locking up as well as just Windows and Linux bootloaders. Thanks for pointing out that Linux falls back too. Stefan
Re: [Qemu-devel] Bug report for kvm-kmod-3.3!
Hi Jan, The host version is: linux-2.6.33.3. I removed the kvm incorporated in the linux kernel and rebuilt the kvm-kmod-3.3.tar.bz2. I have tried from kvm-kmod-2.6.33.3 to kvm-kmod.3.3. Unfortunately, no one worked. The tested guest image is vxworks downloaded from http://people.freebsd.org/~wpaul/qemu/. You can download the vxworks.img and run the commandline: kvm -fda vxworks.img. The qemu will report: KVM internel error: suberror:1. However, it works well if 'no-kvm' is set, namely kvm -fda vxworks.img -no-kvm. Could you please explain what the error means? It seems to be related with 32-bit protected mode. Thanks, katrina On Fri, Mar 23, 2012 at 6:28 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-03-23 09:19, Katrina Austin wrote: Hi all, I've built a guest image. It works well on KVM with a AMD X240 processor but failed with a intel E5620 processor. I am using kvm-kmod-3.3 and qemu-kvm-0.14.0. Here comes the report: kvm_emulate_insn: 0: 11a6d0: ff (prot32) failed kvm_userspace_exit: reason KVM_EXIT_INTERNAL_ERROR (17) kvm_inj_exception:#UD(0x0) kvm_entry: vcpu 0 kvm_exit: reason EPT_MISCONFIG rip 0x11a6d0 info 0 0 It bothers me so much and I would be much appreciated if someone can provide help. Could it be that your guest image uses instructions that are only available on AMD processors? Or is this a regression from previous KVM versions. If yes, which one worked? Further questions in that case: - Could you retest with KVM over a 3.3 kernel, i.e. without kvm-kmod? Does that also faile? - What is your host kernel version? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] gdbserver: Don't send a GDB syscall until the system CPU is stopped
Ping^3...
-- PMM
On 15 March 2012 17:49, Peter Maydell peter.mayd...@linaro.org wrote:
From: Meador Inge mead...@codesourcery.com
Fix an issue where the GDB server implementation was sending GDB syscall
requests while the system CPU was still running. Syscall requests must
be sent while the CPU is stopped otherwise replies from the GDB client
might get dropped and the GDB server might be incorrectly transitioned
into a 'RUN_STATE_PAUSED' state.
Signed-off-by: Meador Inge mead...@codesourcery.com
[PMM: trivial rebase, reinstated comma after last item in RSState enum]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
This patch got (trivially) busted by Andreas' commits changing
CPUState to CPUArchState so I've rebased and resent it. I've also
made the trivial style nit fix of not deleting the final comma in
the RSState enum, based on conversation with Andreas in IRC.
This patch has sitting on the list for about a month reviewed but
unapplied (http://patchwork.ozlabs.org/patch/141867/) -- can
somebody with commit rights apply it please?
gdbstub.c | 42 +++---
1 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/gdbstub.c b/gdbstub.c
index f4e97f7..6a7e2c4 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -284,7 +284,6 @@ enum RSState {
RS_GETLINE,
RS_CHKSUM1,
RS_CHKSUM2,
- RS_SYSCALL,
};
typedef struct GDBState {
CPUArchState *c_cpu; /* current CPU for step/continue ops */
@@ -304,6 +303,8 @@ typedef struct GDBState {
CharDriverState *chr;
CharDriverState *mon_chr;
#endif
+ char syscall_buf[256];
+ gdb_syscall_complete_cb current_syscall_cb;
} GDBState;
/* By default use no IRQs and no timers while single stepping so as to
@@ -346,8 +347,6 @@ static int get_char(GDBState *s)
}
#endif
-static gdb_syscall_complete_cb gdb_current_syscall_cb;
-
static enum {
GDB_SYS_UNKNOWN,
GDB_SYS_ENABLED,
@@ -2097,8 +2096,10 @@ static int gdb_handle_packet(GDBState *s, const char
*line_buf)
if (*p == ',')
p++;
type = *p;
- if (gdb_current_syscall_cb)
- gdb_current_syscall_cb(s-c_cpu, ret, err);
+ if (s-current_syscall_cb) {
+ s-current_syscall_cb(s-c_cpu, ret, err);
+ s-current_syscall_cb = NULL;
+ }
if (type == 'C') {
put_packet(s, T02);
} else {
@@ -2398,7 +2399,12 @@ static void gdb_vm_state_change(void *opaque, int
running, RunState state)
const char *type;
int ret;
- if (running || s-state == RS_INACTIVE || s-state == RS_SYSCALL) {
+ if (running || s-state == RS_INACTIVE) {
+ return;
+ }
+ /* Is there a GDB syscall waiting to be sent? */
+ if (s-current_syscall_cb) {
+ put_packet(s, s-syscall_buf);
return;
}
switch (state) {
@@ -2468,8 +2474,8 @@ send_packet:
void gdb_do_syscall(gdb_syscall_complete_cb cb, const char *fmt, ...)
{
va_list va;
- char buf[256];
char *p;
+ char *p_end;
target_ulong addr;
uint64_t i64;
GDBState *s;
@@ -2477,14 +2483,13 @@ void gdb_do_syscall(gdb_syscall_complete_cb cb, const
char *fmt, ...)
s = gdbserver_state;
if (!s)
return;
- gdb_current_syscall_cb = cb;
- s-state = RS_SYSCALL;
+ s-current_syscall_cb = cb;
#ifndef CONFIG_USER_ONLY
vm_stop(RUN_STATE_DEBUG);
#endif
- s-state = RS_IDLE;
va_start(va, fmt);
- p = buf;
+ p = s-syscall_buf;
+ p_end = s-syscall_buf[sizeof(s-syscall_buf)];
*(p++) = 'F';
while (*fmt) {
if (*fmt == '%') {
@@ -2492,17 +2497,17 @@ void gdb_do_syscall(gdb_syscall_complete_cb cb, const
char *fmt, ...)
switch (*fmt++) {
case 'x':
addr = va_arg(va, target_ulong);
- p += snprintf(p, buf[sizeof(buf)] - p, TARGET_FMT_lx, addr);
+ p += snprintf(p, p_end - p, TARGET_FMT_lx, addr);
break;
case 'l':
if (*(fmt++) != 'x')
goto bad_format;
i64 = va_arg(va, uint64_t);
- p += snprintf(p, buf[sizeof(buf)] - p, % PRIx64, i64);
+ p += snprintf(p, p_end - p, % PRIx64, i64);
break;
case 's':
addr = va_arg(va, target_ulong);
- p += snprintf(p, buf[sizeof(buf)] - p, TARGET_FMT_lx /%x,
+ p += snprintf(p, p_end - p, TARGET_FMT_lx /%x,
addr, va_arg(va, int));
break;
default:
@@ -2517,10 +2522,16 @@ void gdb_do_syscall(gdb_syscall_complete_cb cb, const
char *fmt, ...)
}
*p = 0;
va_end(va);
- put_packet(s, buf);
#ifdef CONFIG_USER_ONLY
+ put_packet(s, s-syscall_buf);
gdb_handlesig(s-c_cpu, 0);
#else
+ /* In this case
Re: [Qemu-devel] [PATCH 05/11 v10] Add API to get memory mapping
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 05/11 v10] Add API to get memory mapping
Date: Tue, 20 Mar 2012 11:51:18 +0800
Add API to get all virtual address and physical address mapping.
If the guest doesn't use paging, the virtual address is equal to the phyical
address. The virtual address and physical address mapping is for gdb's user,
and
it does not include the memory that is not referenced by the page table. So if
you want to use crash to anaylze the vmcore, please do not specify -p option.
the reason why the -p option is not default explicitly: guest machine in a
catastrophic state can have corrupted memory, which we cannot trust.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
memory_mapping.c | 34 ++
memory_mapping.h | 15 +++
2 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/memory_mapping.c b/memory_mapping.c
index 718f271..b92e2f6 100644
--- a/memory_mapping.c
+++ b/memory_mapping.c
@@ -164,3 +164,37 @@ void memory_mapping_list_init(MemoryMappingList *list)
list-last_mapping = NULL;
QTAILQ_INIT(list-head);
}
+
+#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
+int qemu_get_guest_memory_mapping(MemoryMappingList *list)
+{
+CPUArchState *env;
+RAMBlock *block;
+ram_addr_t offset, length;
+int ret;
+bool paging_mode;
+
+paging_mode = cpu_paging_enabled(first_cpu);
+if (paging_mode) {
On SMP with (n)-CPUs, we can do this check at most (n)-times.
On Linux, user-mode tasks have differnet page tables. If refering to
one page table, we can get one user-mode task memory only. Considering
as much memory as possible, it's best to reference all CPUs with
paging enabled and walk all the page tables.
A problem is that linear addresses for user-mode tasks can inherently
conflicts. Different user-mode tasks can have the same linear
address. So, tools need to distinguish each PT_LOAD entry based on a
pair of linear address and physical address, not linear address
only. I don't know whether gdb does this.
+for (env = first_cpu; env != NULL; env = env-next_cpu) {
+ret = cpu_get_memory_mapping(list, env);
+if (ret 0) {
+return -1;
+}
+}
+return 0;
+}
+
+/*
+ * If the guest doesn't use paging, the virtual address is equal to
physical
+ * address.
+ */
IIRC, ACPI sleep state goes in real-mode. There might be another that
can go in real-mode. If execution enters this path in such situation,
linear addresses are meaningless. But this is really rare case.
+QLIST_FOREACH(block, ram_list.blocks, next) {
+offset = block-offset;
+length = block-length;
+create_new_memory_mapping(list, offset, offset, length);
+}
+
+return 0;
+}
Thanks.
HATAYAMA, Daisuke
Re: [Qemu-devel] Bug report for kvm-kmod-3.3!
On 2012-03-23 12:45, Katrina Austin wrote: Hi Jan, The host version is: linux-2.6.33.3. I removed the kvm incorporated in the linux kernel and rebuilt the kvm-kmod-3.3.tar.bz2. I have tried from kvm-kmod-2.6.33.3 to kvm-kmod.3.3. Unfortunately, no one worked. The tested guest image is vxworks downloaded from http://people.freebsd.org/~wpaul/qemu/. You can download the vxworks.img and run the commandline: kvm -fda vxworks.img. The qemu will report: KVM internel error: suberror:1. However, it works well if 'no-kvm' is set, namely kvm -fda vxworks.img -no-kvm. QEMU uses an AMD-derived CPU type by default. Does the image work when you specify, e.g., -cpu Nehalem? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] Spice bug with qemu_name
On Fri, Mar 23, 2012 at 9:10 AM, Lee Essen lee.es...@nowonline.co.uk wrote: In ui/spice_core.c spice_server_set_name() is called with qemu_name, which if not set causes a core dump. I forgot strdup didn't like NULL values, and I forgot to push the patches fixing this in spice. I've now pushed it. Since it's not officially release, I don't think we should work around it in qemu. cheers -- Marc-André Lureau
Re: [Qemu-devel] Bug report for kvm-kmod-3.3!
The microa-architecture of Intel Xeon E5620 is westmere-EP. So, how to specify, e.g., -cpu westmere? p.s. I cannot test it until tomorrow as I am out of office now. Thanks, katrina On Fri, Mar 23, 2012 at 8:13 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-03-23 12:45, Katrina Austin wrote: Hi Jan, The host version is: linux-2.6.33.3. I removed the kvm incorporated in the linux kernel and rebuilt the kvm-kmod-3.3.tar.bz2. I have tried from kvm-kmod-2.6.33.3 to kvm-kmod.3.3. Unfortunately, no one worked. The tested guest image is vxworks downloaded from http://people.freebsd.org/~wpaul/qemu/. You can download the vxworks.img and run the commandline: kvm -fda vxworks.img. The qemu will report: KVM internel error: suberror:1. However, it works well if 'no-kvm' is set, namely kvm -fda vxworks.img -no-kvm. QEMU uses an AMD-derived CPU type by default. Does the image work when you specify, e.g., -cpu Nehalem? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [Qemu-ppc] [PATCH 0/2] PPC: interrupt handler bugfixes
Hi Mark, Am 22.03.2012 19:57, schrieb Mark Cave-Ayland: This small patch series resolves https://bugs.launchpad.net/qemu/+bug/942299 and enables HelenOS to boot once again under PPC32. Please always post patches to qemu-devel, too. Andreas Mark Cave-Ayland (2): PPC: Fix interrupt MSR value within the PPC interrupt handler. PPC: Fix TLB invalidation bug within the PPC interrupt handler. target-ppc/helper.c | 12 1 files changed, 8 insertions(+), 4 deletions(-) -- 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] Remove PCI class code from virtio balloon device
On 03/22/2012 08:52 PM, David Gibson wrote: There is no fragment of code quite like the one you quote, only the check for valid class values, which will accomplish the same thing. It seemed clearer to have the default class value in the property definition be, well, the default class value, rather than setting it to 0 and having it overwritten. Agreed. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v3 1/2] Force timedrift=none on previous machines
On 03/22/2012 05:37 AM, Stefano Stabellini wrote:
On Wed, 21 Mar 2012, Paolo Bonzini wrote:
Il 21/03/2012 17:06, Crístian Viana ha scritto:
@@ -740,6 +772,13 @@ static QEMUMachine xenfv_machine = {
.init = pc_xen_hvm_init,
.max_cpus = HVM_MAX_VCPUS,
.default_machine_opts = accel=xen,
+.compat_props = (GlobalProperty[]) {
+{
+.driver = mc146818rtc,
+.property = lost_tick_policy,
+.value= none,
+},
+{ /* end of list */ }
};
#endif
Stefano, what do you want for Xen? Anyhow,
I would like to keep the old policy for Xen, so the patch is fine by me.
Thanks for pinging me!
Xen emulates the RTC in the hypervisor, no? So it really wouldn't matter IIUC.
Regards,
Anthony Liguori
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 12/15] xl: Add interface to handle multiple device models
On 03/23/2012 11:47 AM, Ian Campbell wrote:
On Thu, 2012-03-22 at 15:59 +, Julien Grall wrote:
This patch add a structure with contain all informations about
a device model.
Signed-off-by: Julien Gralljulien.gr...@citrix.com
---
tools/libxl/libxl.h |4 ++--
tools/libxl/libxl_internal.h |1 +
tools/libxl/libxl_types.idl | 11 +++
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6b69030..a347a34 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -357,9 +357,9 @@ typedef struct {
typedef struct {
libxl_domain_create_info c_info;
libxl_domain_build_info b_info;
-
int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs;
-
+int num_dms;
+libxl_dm *dms;
libxl_device_disk *disks;
libxl_device_nic *vifs;
libxl_device_pci *pcidevs;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0a1070..247bdb9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -767,6 +767,7 @@ typedef struct {
char *dom_path; /* from libxl_malloc, only for libxl_spawner_record_pid */
const char *pid_path; /* only for libxl_spawner_record_pid */
int domid;
+uint32_t dmid;
libxl__spawn_starting *for_spawn;
} libxl__spawner_starting;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 413a1a6..7e48817 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -37,6 +37,7 @@ libxl_domain_type = Enumeration(domain_type, [
libxl_device_model_version = Enumeration(device_model_version, [
(1, QEMU_XEN_TRADITIONAL), # Historical qemu-xen device model (qemu-dm)
(2, QEMU_XEN), # Upstream based qemu-xen device model
+(3, MULTIPLE_QEMU_XEN),# Handle multiple dm
Isn't this implicit in the provision or otherwise of num_dms?
Sorry but I don't understand the question.
])
libxl_console_type = Enumeration(console_type, [
@@ -224,6 +225,15 @@ libxl_domain_create_info = Struct(domain_create_info,[
MemKB = UInt(64, init_val = LIBXL_MEMKB_DEFAULT)
+libxl_dm = Struct(dm, [
+(id, uint32),
+(name, string),
+(path, string),
+(pcis, libxl_string_list),
+(mmios,libxl_string_list),
+(pios, libxl_string_list),
+])
Why does the user of libxl need to know the id? can't that be internal
to the library?
Indeed, I will remove that.
What are name and path? I guess path is something to do with xenstore
but isn't that also internal to the libxl-dm interface not something
the caller of libxl need be aware of?
The path is the binary path and the name is just a string append
to the log filename.
I'm not sure what syntax pcis, mmios and pios are going to have
but I expect that this would be better represent as actual
datastructures rather than encoding it as a string.
How are toolstack supposed to know the values for e.g. pcis?
For the moment pcis are describe as bdf for instance: 00:01.1
and mmios/pios as range (0x10-0x20 or just 0x19).
All in all this seems like a very raw/low-level interface. Can libxl not
expose something a bit more meaningful to toolstack authors? For example
if we consider emulated disk controllers then perhaps the options are
* Handled by the primary dm
* Handled by a single disaggregated dm
* Handled by multiple disaggregated dm's (one per disk controller)
Similarly for other classes or emulated device. Or maybe this should be
a flag on those actual devices (e.g. in libxl_device_FOO)?
I have not really ideas about that. The first solution that comes
in my mind is to bind each device with the device model name.
But in this case, we need to modify QEMU to launch only a subset
of hardware and find a way to said which QEMU will emulate the
basic hardware (keyboard, mouse, piix, ...).
Moreover, who will allocate the bdf ? The toolstack ?
+
# Instances of libxl_file_reference contained in this struct which
# have been mapped (with libxl_file_reference_map) will be unmapped
# by libxl_domain_build/restore. If either of these are never called
@@ -289,6 +299,7 @@ libxl_domain_build_info = Struct(domain_build_info,[
(usbdevice,string),
(soundhw, string),
(xen_platform_pci, libxl_defbool),
+ (max_servers, integer),
As a toolstack author how do I decide what number to use here?
The max_servers variables is used to compute the additionnal special pages.
So the max_servers indicates the maximum servers that we want to spawn.
Re: [Qemu-devel] [PATCH 2/2] QEMU kvm: Add support to get/set vcpu unhalt msr to aid migration
On 03/23/2012 02:27 PM, Jan Kiszka wrote:
On 2012-03-23 09:23, Raghavendra K T wrote:
From: Raghavendra K Traghavendra...@linux.vnet.ibm.com
MSR_KVM_PV_UNHALT tells whether vcpu is unhalted, which needs to be
used during migration.
Err, and where is it actually saved to/restored from the vmstate? You
are lacking an extension of the CPU vmstate, preferably via a substate.
See e.g. cpu/async_pf_msr.
Please let me know whether adding below patch make it complete. Or did
I miss something else ?
---
diff --git a/target-i386/machine.c b/target-i386/machine.c
index a8be058..c51d8d1 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -279,6 +279,13 @@ static bool async_pf_msr_needed(void *opaque)
return cpu-async_pf_en_msr != 0;
}
+static bool pv_unhalt_msr_needed(void *opaque)
+{
+CPUX86State *cpu = opaque;
+
+return cpu-pv_unhalt_msr != 0;
+}
+
static const VMStateDescription vmstate_async_pf_msr = {
.name = cpu/async_pf_msr,
.version_id = 1,
@@ -290,6 +297,17 @@ static const VMStateDescription
vmstate_async_pf_msr = {
}
};
+static const VMStateDescription vmstate_pv_unhalt_msr = {
+.name = cpu/pv_unhalt_msr,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField []) {
+VMSTATE_UINT64(pv_unhalt_msr, CPUX86State),
+VMSTATE_END_OF_LIST()
+}
+};
+
static bool fpop_ip_dp_needed(void *opaque)
{
CPUX86State *env = opaque;
@@ -462,6 +480,9 @@ static const VMStateDescription vmstate_cpu = {
}, {
.vmsd = vmstate_msr_ia32_misc_enable,
.needed = misc_enable_needed,
+}, {
+.vmsd = vmstate_pv_unhalt_msr,
+.needed = pv_unhalt_msr_needed,
} , {
/* empty */
}
Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest
On Fri, Mar 23, 2012 at 03:49:27AM +, Liu, Jinsong wrote: Eduardo Habkost wrote: [1] From Documentation/virtual/kvm/api.txt: KVM_GET_SUPPORTED_CPUID [...] This ioctl returns x86 cpuid features which are supported by both the hardware and kvm. Userspace can use the information returned by this ioctl to construct cpuid information (for KVM_SET_CPUID2) that is consistent with hardware, kernel, and userspace capabilities, and with ^^ user requirements (for example, the user may wish to constrain cpuid to emulate older hardware, or for feature consistency across a cluster). The fixbug patch is implemented by Jan and Avi, I reply per my understanding. No problem. I hope Jan or Avi can clarify this. I think for tsc deadline timer feature, KVM_CAP_TSC_DEADLINE_TIMER is slightly better than KVM_GET_SUPPORTED_CPUID. If use KVM_GET_SUPPORTED_CPUID, it means tsc deadline features bind to host cpuid, while it fact it could be pure software emulated by kvm (though currently it implemented as bound to hareware). For the sake of extension, it choose KVM_CAP_TSC_DEADLINE_TIMER. There's no requirement for GET_SUPPORTED_CPUID to be a subset of the host CPU features. If KVM can completely emulate the feature by software, then it can return the feature on GET_SUPPORTED_CPUID even if the host CPU doesn't have the feature. That's the case for x2apic, for example (see commit 0d1de2d901f4ba0972a3886496a44fb1d3300dbd). -- Eduardo
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 00/15] QEMU disaggregation
On 03/22/2012 04:59 PM, Tim Deegan wrote: At 15:59 + on 22 Mar (1332431961), Julien Grall wrote: Julien Grall (15): xc: Add the hypercall for multiple servers xc: Add argument to allocate more special pages xc: Fix python build Shouldn't something here update xc_domain_save/xc_domain_restore? For the moment no, I will modify the both functions for the next version of the series.
Re: [Qemu-devel] [PATCH V9 3/8] Introduce HostPCIDevice to access a pci device on the host.
On Wed, Mar 21, 2012 at 20:30, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Mar 21, 2012 at 06:29:00PM +, Anthony PERARD wrote:
Signed-off-by: Anthony PERARD anthony.per...@citrix.com
Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
So this interface is really LinuxSysfsPCIDevice.
For example the assumption that you can just open
device by pci address is broken with vfio.
Domain number is also not something anyone
besides linux knows about.
If I were you I would just call it xen-
and if it comes in handy it can be later renamed.
Ok, I will rename that XenHostPCIDevice.
---
Makefile.target | 3 +
hw/host-pci-device.c | 278
++
hw/host-pci-device.h | 75 ++
3 files changed, 356 insertions(+), 0 deletions(-)
create mode 100644 hw/host-pci-device.c
create mode 100644 hw/host-pci-device.h
diff --git a/Makefile.target b/Makefile.target
index 63cf769..0ccfd5b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -232,6 +232,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
obj-i386-$(CONFIG_XEN) += xen_platform.o
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+
# Inter-VM PCI shared memory
CONFIG_IVSHMEM =
ifeq ($(CONFIG_KVM), y)
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 000..3dacb30
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (C) 2011 Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include qemu-common.h
+#include host-pci-device.h
+
+#define PCI_MAX_EXT_CAP \
+ ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF +
4))
namespace pollution.
name all things HOST_PCI_
in this case, open-coding will make things clearer.
+
+enum error_code {
seems unused. So why name the type?
+ ERROR_SYNTAX = 1,
We return -1 on error, just do that and you won't need ERROR_SYNTAX.
Ok, I'll remove this.
+};
+
+static int path_to(const HostPCIDevice *d,
+ const char *name, char *buf, ssize_t size)
+{
+ return snprintf(buf, size, /sys/bus/pci/devices/%04x:%02x:%02x.%x/%s,
+ d-domain, d-bus, d-dev, d-func, name);
+}
users ignore return value. Also, want to check no overflow
and assert?
I will check the return value in this function an then return 0 or -1.
+
+static int get_resource(HostPCIDevice *d)
+{
+ int i, rc = 0;
+ FILE *f;
+ char path[PATH_MAX];
+ unsigned long long start, end, flags, size;
+
+ path_to(d, resource, path, sizeof (path));
I think this might not fit, snprintf needs an extra byte for \0.
I just check snprintf write size byte including the \0, sw we should
just give the size of the buffer.
+ f = fopen(path, r);
+ if (!f) {
+ fprintf(stderr, Error: Can't open %s: %s\n, path,
strerror(errno));
+ return -errno;
+ }
+
+ for (i = 0; i PCI_NUM_REGIONS; i++) {
+ if (fscanf(f, %llx %llx %llx, start, end, flags) != 3) {
People mentioned that scanf is not a good way to parse input.
Applies here.
Ok, I'll do a manual parsing :(.
+ fprintf(stderr, Error: Syntax error in %s\n, path);
+ rc = ERROR_SYNTAX;
+ break;
+ }
+ if (start) {
+ size = end - start + 1;
+ } else {
+ size = 0;
+ }
+
+ if (i PCI_ROM_SLOT) {
+ d-io_regions[i].base_addr = start;
+ d-io_regions[i].size = size;
+ d-io_regions[i].flags = flags;
+ } else {
+ d-rom.base_addr = start;
+ d-rom.size = size;
+ d-rom.flags = flags;
+ }
+ }
+
+ fclose(f);
+ return rc;
+}
+
+static int get_hex_value(HostPCIDevice *d, const char *name,
+ unsigned long *pvalue)
why long?
Do be a bit generic I suppose, but I just use this function for
vendor_id and device_id, I probably just need an int.
+{
+ char path[PATH_MAX];
+ FILE *f;
+ unsigned long value;
+
+ path_to(d, name, path, sizeof (path));
+ f = fopen(path, r);
+ if (!f) {
+ fprintf(stderr, Error: Can't open %s: %s\n, path,
strerror(errno));
+ return -errno;
+ }
+ if (fscanf(f, %lx\n, value) != 1) {
+ fprintf(stderr, Error: Syntax error in %s\n, path);
+ fclose(f);
+ return ERROR_SYNTAX;
+ }
+ fclose(f);
+ *pvalue = value;
+ return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+ char path[PATH_MAX];
+ struct stat buf;
+
+ path_to(d, physfn, path, sizeof (path));
+ return !stat(path, buf);
+}
+
Don't start names with pci_.
It would also be better to avoid things like path_to IMO.
Do you mean avoiding the name or the purpose of
Re: [Qemu-devel] Thoughts around dtrace linking...
On 23 Mar 2012, at 08:08, Stefan Hajnoczi wrote: On Thu, Mar 22, 2012 at 05:00:53PM +, Lee Essen wrote: On 22/03/2012 16:28, Stefan Hajnoczi wrote: On Wed, Mar 21, 2012 at 1:01 PM, Andreas Färberafaer...@suse.de wrote: Hi, Am 21.03.2012 11:45, schrieb Lee Essen: I've been trying to find a sensible way to solve the Solaris/Illumos dtrace requirement to pass all the objs to the dtrace command so that the resultant object file contains all the symbols needed to properly link the relevant binary. If you're able to try out the dependency-based approach that would be a good starting point. You may hit a point where it turns out to be too ugly or complicated - in that case, please post your progress and maybe someone can help find a way to structure it. I'm not a make guru but I can try to give feedback on your patches. Stefan Ok, here's an attempt … it works for me, but I'm not sure how it would work on a different dtrace platform so it will probably need some different guarding … but it shows what it will look like. Lee. diff --git a/Makefile b/Makefile index 1bc3cb0..b300364 100644 --- a/Makefile +++ b/Makefile @@ -157,9 +157,28 @@ tools-obj-y = $(oslib-obj-y) $(trace-obj-y) qemu-tool.o qemu-timer.o \ qemu-timer-common.o main-loop.o notify.o iohandler.o cutils.o async.o tools-obj-$(CONFIG_POSIX) += compatfd.o -qemu-img$(EXESUF): qemu-img.o $(tools-obj-y) $(block-obj-y) -qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y) $(block-obj-y) -qemu-io$(EXESUF): qemu-io.o cmd.o $(tools-obj-y) $(block-obj-y) +qemu-img-trace-objs=qemu-img.o $(tools-obj-y) $(block-obj-y) +qemu-nbd-trace-objs=qemu-nbd.o $(tools-obj-y) $(block-obj-y) +qemu-io-trace-objs=qemu-io.o cmd.o $(tools-obj-y) $(block-obj-y) +qemu-img-all-objs=$(qemu-img-trace-objs) +qemu-nbd-all-objs=$(qemu-nbd-trace-objs) +qemu-io-all-objs=$(qemu-io-trace-objs) +ifdef CONFIG_TRACE_DTRACE +qemu-img-all-objs+=qemu-img.dtrace.o +qemu-nbd-all-objs+=qemu-nbd.dtrace.o +qemu-io-trace-objs+=qemu-img.dtrace.o +endif + +qemu-img.dtrace.o: trace-dtrace.dtrace $(qemu-img-trace-objs) + $(call DTRACE,$@,trace-dtrace.dtrace,$(qemu-img-trace-objs)) +qemu-nbd.dtrace.o: trace-dtrace.dtrace $(qemu-nbd-trace-objs) + $(call DTRACE,$@,trace-dtrace.dtrace,$(qemu-nbd-trace-objs)) +qemu-io.dtrace.o: trace-dtrace.dtrace $(qemu-io-trace-objs) + $(call DTRACE,$@,trace-dtrace.dtrace,$(qemu-io-trace-objs)) + +qemu-img$(EXESUF): $(qemu-img-all-objs) +qemu-nbd$(EXESUF): $(qemu-nbd-all-objs) +qemu-io$(EXESUF): $(qemu-io-all-objs) qemu-bridge-helper$(EXESUF): qemu-bridge-helper.o qemu-bridge-helper.o: $(GENERATED_HEADERS) @@ -205,7 +224,17 @@ QGALIB_GEN=$(addprefix $(qapi-dir)/, qga-qapi-types.h qga-qapi-visit.h qga-qmp-c $(QGALIB_OBJ): $(QGALIB_GEN) $(GENERATED_HEADERS) $(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) $(GENERATED_HEADERS) -qemu-ga$(EXESUF): qemu-ga.o $(qga-obj-y) $(tools-obj-y) $(qapi-obj-y) $(qobject-obj-y) $(version-obj-y) $(QGALIB_OBJ) +qemu-ga-trace-objs=qemu-ga.o $(qga-obj-y) $(tools-obj-y) $(qapi-obj-y) $(qobject-obj-y) $(version-obj-y) $(QGALIB_OBJ) +qemu-ga-all-objs=$(qemu-ga-trace-objs) +ifdef CONFIG_TRACE_DTRACE +qemu-ga-all-objs+=qemu-ga.dtrace.o +endif + +qemu-ga.dtrace.o: trace-dtrace.dtrace $(qemu-ga-trace-objs) + $(call DTRACE,$@,trace-dtrace.dtrace,$(qemu-ga-trace-objs)) + +qemu-ga$(EXESUF): $(qemu-ga-all-objs) + QEMULIBS=libhw32 libhw64 libuser libdis libdis-user diff --git a/Makefile.target b/Makefile.target index 63cf769..ed0d824 100644 --- a/Makefile.target +++ b/Makefile.target @@ -441,7 +441,17 @@ $(QEMU_PROGW): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) $(QEMU_PROG): $(QEMU_PROGW) $(call quiet-command,$(OBJCOPY) --subsystem console $(QEMU_PROGW) $(QEMU_PROG), GEN $(TARGET_DIR)$(QEMU_PROG)) else -$(QEMU_PROG): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) + +target-trace-objs=$(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) +target-all-objs=$(target-trace-objs) +ifdef CONFIG_TRACE_DTRACE +target-all-objs+=$(QEMU_PROG).dtrace.o +endif + +$(QEMU_PROG).dtrace.o: ../trace-dtrace.dtrace $(target-trace-objs) + $(call DTRACE,$@,../trace-dtrace.dtrace,$(target-trace-objs)) + +$(QEMU_PROG): $(target-all-objs) $(call LINK,$^) endif diff --git a/rules.mak b/rules.mak index 04a9198..31ad59c 100644 --- a/rules.mak +++ b/rules.mak @@ -33,6 +33,8 @@ endif LINK = $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $(sort $(1)) $(LIBS), LINK $(TARGET_DIR)$@) +DTRACE = $(call quiet-command,dtrace $(CONFIG_DTRACE_FLAGS) -o $(1) -G -s $(2) $(3), GEN $(TARGET_DIR)$(1)) + %$(EXESUF): %.o $(call LINK,$^)
Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest
Eduardo Habkost wrote: On Fri, Mar 23, 2012 at 03:49:27AM +, Liu, Jinsong wrote: Eduardo Habkost wrote: [1] From Documentation/virtual/kvm/api.txt: KVM_GET_SUPPORTED_CPUID [...] This ioctl returns x86 cpuid features which are supported by both the hardware and kvm. Userspace can use the information returned by this ioctl to construct cpuid information (for KVM_SET_CPUID2) that is consistent with hardware, kernel, and userspace capabilities, and with ^^ user requirements (for example, the user may wish to constrain cpuid to emulate older hardware, or for feature consistency across a cluster). The fixbug patch is implemented by Jan and Avi, I reply per my understanding. No problem. I hope Jan or Avi can clarify this. I think for tsc deadline timer feature, KVM_CAP_TSC_DEADLINE_TIMER is slightly better than KVM_GET_SUPPORTED_CPUID. If use KVM_GET_SUPPORTED_CPUID, it means tsc deadline features bind to host cpuid, while it fact it could be pure software emulated by kvm (though currently it implemented as bound to hareware). For the sake of extension, it choose KVM_CAP_TSC_DEADLINE_TIMER. There's no requirement for GET_SUPPORTED_CPUID to be a subset of the host CPU features. If KVM can completely emulate the feature by software, then it can return the feature on GET_SUPPORTED_CPUID even if the host CPU doesn't have the feature. That's the case for x2apic, for example (see commit 0d1de2d901f4ba0972a3886496a44fb1d3300dbd). Jan/Avi, Could you elaborate more your thought? Thanks, Jinsong
Re: [Qemu-devel] [PATCH v3 1/5] qerror: add error codes for fopen failure
On Sun, 18 Mar 2012 19:29:09 +0100
Alon Levy al...@redhat.com wrote:
Added:
QERR_EINTR
QERR_EACCES
QERR_EEXIST
QERR_OPEN_FILE_EMFILE
QERR_ENOSPC
QERR_EPERM
QERR_READ_ONLY
QERR_ENOTDIR
QERR_EFBIG
Signed-off-by: Alon Levy al...@redhat.com
---
qerror.c | 36
qerror.h | 27 +++
2 files changed, 63 insertions(+)
diff --git a/qerror.c b/qerror.c
index f55d435..4915939 100644
--- a/qerror.c
+++ b/qerror.c
@@ -213,6 +213,42 @@ static const QErrorStringTable qerror_table[] = {
.desc = Could not open '%(filename)',
},
{
+.error_fmt = QERR_EINTR,
+.desc = Interrupted open of '%(filename)',
+},
There are two problems here. First, the QERR_INTR macro doesn't have the
filename argument, so this will crash.
The second problem is that, I've talked to Anthony and EINTR should not
be returned to clients, it should be handled intead. So, please handle it
during write().
+{
+.error_fmt = QERR_EACCES,
+.desc = Cannot access file',
+},
We already have QERR_PERMISSION_DENIED.
+{
+.error_fmt = QERR_EEXIST,
+.desc = File already exists',
+},
Can you use the description provided by man 3 errno? This is valid for all
errors you're adding.
+{
+.error_fmt = QERR_OPEN_FILE_EMFILE,
+.desc = Max open files when opening file',
+},
+{
+.error_fmt = QERR_ENOSPC,
+.desc = No space left opening file',
+},
+{
+.error_fmt = QERR_EPERM,
+.desc = Permission denied (EPERM) opening file',
+},
+{
+.error_fmt = QERR_READ_ONLY,
+.desc = Read only filesystem opening file',
+},
+{
+.error_fmt = QERR_ENOTDIR,
+.desc = Directory related error opening file',
+},
+{
+.error_fmt = QERR_EFBIG,
+.desc = File too big opening',
+},
+{
.error_fmt = QERR_PERMISSION_DENIED,
.desc = Insufficient permission to perform this operation,
},
diff --git a/qerror.h b/qerror.h
index e26c635..ddc04e8 100644
--- a/qerror.h
+++ b/qerror.h
@@ -181,6 +181,33 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_OPEN_FILE_FAILED \
{ 'class': 'OpenFileFailed', 'data': { 'filename': %s } }
+#define QERR_OPEN_FILE_EMFILE \
+{ 'class': 'OpenFileEMFILE', 'data': {} }
+
+#define QERR_EINTR \
+{ 'class': 'EINTR', 'data': {} }
+
+#define QERR_EACCES \
+{ 'class': 'EACCES', 'data': {} }
+
+#define QERR_EEXIST \
+{ 'class': 'EEXIST', 'data': {} }
We use more descriptive names instead of using the errno name. Like
AlreadyExists.
Please fix it for errors you adding.
+
+#define QERR_ENOSPC \
+{ 'class': 'ENOSPC', 'data': {} }
+
+#define QERR_EPERM \
+{ 'class': 'EPERM', 'data': {} }
+
+#define QERR_READ_ONLY \
+{ 'class': 'ReadOnly', 'data': {} }
+
+#define QERR_ENOTDIR \
+{ 'class': 'ENOTDIR', 'data': {} }
+
+#define QERR_EFBIG \
+{ 'class': 'EFBIG', 'data': {} }
+
#define QERR_PERMISSION_DENIED \
{ 'class': 'PermissionDenied', 'data': {} }
Re: [Qemu-devel] [PATCH v3 2/5] add qemu_fopen_err
On Sun, 18 Mar 2012 19:29:10 +0100
Alon Levy al...@redhat.com wrote:
This adds a helper to conveniently set the correct error based on the
errno after a failed fopen.
The added function is placed in it's own c file to allow libcacard to
not develop dependencies on everything that qerror will bring in, which
includes monitor and half of qemu. I tried to make it as less ugly as I
could, by naming an osdep-no-qerror-obj-y and having that included in
osdep-obj-y, and using only the former for libcacard.
I'm not sure I like this, how will libcacard report errors then?
Signed-off-by: Alon Levy al...@redhat.com
---
Makefile.objs |8 +---
libcacard/Makefile |2 +-
osdep-qerror.c | 52
osdep-qerror.h |8
osdep.c|1 -
5 files changed, 66 insertions(+), 5 deletions(-)
create mode 100644 osdep-qerror.c
create mode 100644 osdep-qerror.h
diff --git a/Makefile.objs b/Makefile.objs
index 226b01d..fb5a73a 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -20,9 +20,11 @@ universal-obj-y += $(qom-obj-y)
###
# oslib-obj-y is code depending on the OS (win32 vs posix)
-oslib-obj-y = osdep.o
-oslib-obj-$(CONFIG_WIN32) += oslib-win32.o qemu-thread-win32.o
-oslib-obj-$(CONFIG_POSIX) += oslib-posix.o qemu-thread-posix.o
+oslib-no-qerror-obj-y = osdep.o
+oslib-no-qerror-obj-$(CONFIG_WIN32) += oslib-win32.o qemu-thread-win32.o
+oslib-no-qerror-obj-$(CONFIG_POSIX) += oslib-posix.o qemu-thread-posix.o
+oslib-obj-y = $(oslib-no-qerror-obj-y)
+oslib-obj-y += osdep-qerror.o
###
# coroutines
diff --git a/libcacard/Makefile b/libcacard/Makefile
index c6a896a..83f483f 100644
--- a/libcacard/Makefile
+++ b/libcacard/Makefile
@@ -8,7 +8,7 @@ libcacard_includedir=$(includedir)/cacard
$(call set-vpath, $(SRC_PATH):$(libcacard_srcpath))
# objects linked against normal qemu binaries, not compiled with libtool
-QEMU_OBJS=$(addprefix ../,$(oslib-obj-y) qemu-timer-common.o $(trace-obj-y))
+QEMU_OBJS=$(addprefix ../,$(oslib-no-qerror-obj-y) qemu-timer-common.o
$(trace-obj-y))
# objects linked into a shared library, built with libtool with -fPIC if
required
QEMU_OBJS_LIB=$(addsuffix .lo,$(basename $(QEMU_OBJS)))
diff --git a/osdep-qerror.c b/osdep-qerror.c
new file mode 100644
index 000..6dac984
--- /dev/null
+++ b/osdep-qerror.c
@@ -0,0 +1,52 @@
+#include qerror.h
+
+#include osdep-qerror.h
+
+/*
+ * Helper to set an Error after a failed fopen.
+ *
+ * Uses errno so it must not be changed by another intermediate call.
+ */
+void qemu_fopen_err(Error **errp, const char *file_name)
+{
+const char *fmt = NULL;
Where's the fopen() call and the mode argument?
+
+switch (errno) {
+case EACCES:
+fmt = QERR_EACCES;
+break;
+case EINTR:
+fmt = QERR_EINTR;
+break;
+case EEXIST:
+fmt = QERR_EEXIST;
+break;
+case EMFILE:
+fmt = QERR_OPEN_FILE_EMFILE;
+break;
+case ENOSPC:
+fmt = QERR_ENOSPC;
+break;
+case EPERM:
+fmt = QERR_EPERM;
+break;
+case EROFS:
+fmt = QERR_READ_ONLY;
+break;
+case ENOTDIR:
+fmt = QERR_ENOTDIR;
+break;
+case EFBIG:
+fmt = QERR_EFBIG;
+break;
+default:
+/*
+ * EINVAL and ENOTSUP will result in the default
+ *
+ * ENOENT too, it's used by (for instance) bdrv_create_file for
+ * a different purpose then open (2) so just give a generic error.
+ */
+fmt = QERR_OPEN_FILE_FAILED;
+}
+error_set(errp, fmt, file_name);
+}
diff --git a/osdep-qerror.h b/osdep-qerror.h
new file mode 100644
index 000..7320f4a
--- /dev/null
+++ b/osdep-qerror.h
@@ -0,0 +1,8 @@
+#ifndef OSDEP_QERROR_H
+#define OSDEP_QERROR_H
+
+#include error.h
+
+void qemu_fopen_err(Error **errp, const char *file_name);
+
+#endif
diff --git a/osdep.c b/osdep.c
index 3e6bada..efdd21c 100644
--- a/osdep.c
+++ b/osdep.c
@@ -241,4 +241,3 @@ ssize_t qemu_recv_full(int fd, void *buf, size_t count,
int flags)
return total;
}
-
Re: [Qemu-devel] [PATCH v3 4/5] qapi: convert screendump
On Sun, 18 Mar 2012 19:29:12 +0100
Alon Levy al...@redhat.com wrote:
The documenting comment contains the long list of possible errors from
qemu_fopen_err, this could probably be put somewhere else in the file
once more of the api uses those common error classes.
Signed-off-by: Alon Levy al...@redhat.com
---
hmp-commands.hx |3 +--
hmp.c|8
hmp.h|1 +
monitor.c|6 --
qapi-schema.json | 24
qmp-commands.hx |5 +
qmp.c|5 +
7 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 6980214..d26421a 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -194,8 +194,7 @@ ETEXI
.args_type = filename:F,
.params = filename,
.help = save screen into PPM image 'filename',
-.user_print = monitor_user_noop,
-.mhandler.cmd_new = do_screen_dump,
+.mhandler.cmd = hmp_screendump,
},
STEXI
diff --git a/hmp.c b/hmp.c
index 290c43d..42dc79a 100644
--- a/hmp.c
+++ b/hmp.c
@@ -860,3 +860,11 @@ void hmp_block_job_cancel(Monitor *mon, const QDict
*qdict)
hmp_handle_error(mon, error);
}
+
+void hmp_screendump(Monitor *mon, const QDict *qdict)
+{
+Error *err = NULL;
+
+qmp_screendump(qdict_get_str(qdict, filename), err);
+hmp_handle_error(mon, err);
+}
diff --git a/hmp.h b/hmp.h
index 5409464..25d123f 100644
--- a/hmp.h
+++ b/hmp.h
@@ -59,5 +59,6 @@ void hmp_block_set_io_throttle(Monitor *mon, const QDict
*qdict);
void hmp_block_stream(Monitor *mon, const QDict *qdict);
void hmp_block_job_set_speed(Monitor *mon, const QDict *qdict);
void hmp_block_job_cancel(Monitor *mon, const QDict *qdict);
+void hmp_screendump(Monitor *mon, const QDict *qdict);
#endif
diff --git a/monitor.c b/monitor.c
index 2156fcf..34d7617 100644
--- a/monitor.c
+++ b/monitor.c
@@ -893,12 +893,6 @@ static int client_migrate_info(Monitor *mon, const QDict
*qdict,
return -1;
}
-static int do_screen_dump(Monitor *mon, const QDict *qdict, QObject
**ret_data)
-{
-vga_hw_screen_dump(qdict_get_str(qdict, filename), NULL);
-return 0;
-}
-
static void do_logfile(Monitor *mon, const QDict *qdict)
{
cpu_set_log_filename(qdict_get_str(qdict, filename));
diff --git a/qapi-schema.json b/qapi-schema.json
index 04fa84f..b9baba9 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1663,3 +1663,27 @@
{ 'command': 'qom-list-types',
'data': { '*implements': 'str', '*abstract': 'bool' },
'returns': [ 'ObjectTypeInfo' ] }
+
+##
+# @screendump:
+#
+# Write a PPM of the VGA screen to a file.
+#
+# @filename: the name of a new PPM file to create to store the image
+#
+# Returns: Nothing on success
+# If @cpu is not a valid VCPU, InvalidParameterValue
+# If @filename cannot be opened, OpenFileFailed or one of the more
+# specific errors:
+#EINTR - Interruped during operation
+#EACCES - Cannot access file
+#OpenFileEMFILE - Maximum open file descriptors reached
+#ENOSPC - No space on device
+#EPERM - No permission
+#READ_ONLY - File system is read only
+#ENOTDIR - Path to file contains a non directory element
We write the errors a bit different, please take a look at other commands.
+#
+##
+# Since: 1.1
+##
+{ 'command': 'screendump', 'data': {'filename': 'str'} }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index dfe8a5b..5fe57fd 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -146,10 +146,7 @@ EQMP
{
.name = screendump,
.args_type = filename:F,
-.params = filename,
-.help = save screen into PPM image 'filename',
-.user_print = monitor_user_noop,
-.mhandler.cmd_new = do_screen_dump,
+.mhandler.cmd_new = qmp_marshal_input_screendump,
},
SQMP
diff --git a/qmp.c b/qmp.c
index a182b51..086cec8 100644
--- a/qmp.c
+++ b/qmp.c
@@ -415,3 +415,8 @@ ObjectTypeInfoList *qmp_qom_list_types(bool
has_implements,
return ret;
}
+
+void qmp_screendump(const char *filename, Error **errp)
+{
+vga_hw_screen_dump(filename, errp);
+}
Re: [Qemu-devel] [PATCH v3 5/5] vga: ppm_save(): Return error on failure
On Sun, 18 Mar 2012 19:29:13 +0100
Alon Levy al...@redhat.com wrote:
From: Luiz Capitulino lcapitul...@redhat.com
This makes all devices using ppm_save() return an error appropriately
when the screendump command fails.
Based on a code by Anthony Liguori.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Alon Levy al...@redhat.com
---
hw/blizzard.c |2 +-
hw/qxl.c|2 +-
hw/vga.c|8 +---
hw/vga_int.h|3 ++-
hw/vmware_vga.c |2 +-
5 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/hw/blizzard.c b/hw/blizzard.c
index 76df78c..29e5ae6 100644
--- a/hw/blizzard.c
+++ b/hw/blizzard.c
@@ -942,7 +942,7 @@ static void blizzard_screen_dump(void *opaque, const char
*filename,
blizzard_update_display(opaque);
}
if (s ds_get_data(s-state))
-ppm_save(filename, s-state-surface);
+ppm_save(filename, s-state-surface, errp);
}
#define DEPTH 8
diff --git a/hw/qxl.c b/hw/qxl.c
index 27f27f5..aa68612 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1503,7 +1503,7 @@ static void qxl_hw_screen_dump(void *opaque, const char
*filename, bool cswitch,
case QXL_MODE_COMPAT:
case QXL_MODE_NATIVE:
qxl_render_update(qxl);
-ppm_save(filename, qxl-ssd.ds-surface);
+ppm_save(filename, qxl-ssd.ds-surface, errp);
break;
case QXL_MODE_VGA:
vga-screen_dump(vga, filename, cswitch, errp);
diff --git a/hw/vga.c b/hw/vga.c
index 79c5c38..80e6dca 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -2365,7 +2365,7 @@ void vga_init_vbe(VGACommonState *s, MemoryRegion
*system_memory)
//
/* vga screen dump */
-int ppm_save(const char *filename, struct DisplaySurface *ds)
+int ppm_save(const char *filename, struct DisplaySurface *ds, Error **errp)
{
FILE *f;
uint8_t *d, *d1;
@@ -2377,8 +2377,10 @@ int ppm_save(const char *filename, struct
DisplaySurface *ds)
trace_ppm_save(filename, ds);
f = fopen(filename, wb);
What I suggested to you was calling qemu_fopen_err() instead of fopen().
-if (!f)
+if (!f) {
+error_set_file_open_failed(errp, filename, errno);
Does this even compile?
Also note that there are device models that don't use ppm_save(), they have to
be converted too.
return -1;
+}
fprintf(f, P6\n%d %d\n%d\n,
ds-width, ds-height, 255);
linebuf = g_malloc(ds-width * 3);
@@ -2420,5 +2422,5 @@ static void vga_screen_dump(void *opaque, const char
*filename, bool cswitch,
vga_invalidate_display(s);
vga_hw_update();
}
-ppm_save(filename, s-ds-surface);
+ppm_save(filename, s-ds-surface, errp);
}
diff --git a/hw/vga_int.h b/hw/vga_int.h
index 7685b2b..63078ba 100644
--- a/hw/vga_int.h
+++ b/hw/vga_int.h
@@ -24,6 +24,7 @@
#include hw/hw.h
#include memory.h
+#include error.h
#define ST01_V_RETRACE 0x08
#define ST01_DISP_ENABLE0x01
@@ -200,7 +201,7 @@ void vga_ioport_write(void *opaque, uint32_t addr,
uint32_t val);
uint32_t vga_mem_readb(VGACommonState *s, target_phys_addr_t addr);
void vga_mem_writeb(VGACommonState *s, target_phys_addr_t addr, uint32_t
val);
void vga_invalidate_scanlines(VGACommonState *s, int y1, int y2);
-int ppm_save(const char *filename, struct DisplaySurface *ds);
+int ppm_save(const char *filename, struct DisplaySurface *ds, Error **errp);
int vga_ioport_invalid(VGACommonState *s, uint32_t addr);
void vga_init_vbe(VGACommonState *s, MemoryRegion *address_space);
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index 6868778..0769652 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -1016,7 +1016,7 @@ static void vmsvga_screen_dump(void *opaque, const char
*filename, bool cswitch,
if (s-depth == 32) {
DisplaySurface *ds = qemu_create_displaysurface_from(s-width,
s-height, 32, ds_get_linesize(s-vga.ds), s-vga.vram_ptr);
-ppm_save(filename, ds);
+ppm_save(filename, ds, errp);
g_free(ds);
}
}
[Qemu-devel] [PATCH 0/2] xen_disk: use NATIVE_AIO and NOCACHE
Hi all, this small patch series allows xen_disk to be used correctly with NATIVE_AIO and O_DIRECT. This series should be backported to the stable branch too. Stefano Stabellini (2): xen_disk: open disk with BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO xen_disk: when using AIO flush after the operation is completed hw/xen_disk.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) git://xenbits.xen.org/people/sstabellini/qemu-dm.git disk_io Cheers, Stefano
[Qemu-devel] [PATCH 2/2] xen_disk: when using AIO flush after the operation is completed
If ioreq-postsync call bdrv_flush when the AIO operation is actually
completed.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
hw/xen_disk.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 0f265a4..9cb0253 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -330,6 +330,9 @@ static void qemu_aio_complete(void *opaque, int ret)
if (ioreq-aio_inflight 0) {
return;
}
+if (ioreq-postsync) {
+bdrv_flush(ioreq-blkdev-bs);
+}
ioreq-status = ioreq-aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
ioreq_unmap(ioreq);
@@ -376,9 +379,6 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
goto err;
}
-if (ioreq-postsync) {
-bdrv_flush(blkdev-bs); /* FIXME: aio_flush() ??? */
-}
qemu_aio_complete(ioreq, 0);
return 0;
--
1.7.2.5
[Qemu-devel] [PATCH 1/2] xen_disk: open disk with BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
hw/xen_disk.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 68fa36a..0f265a4 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -584,10 +584,10 @@ static int blk_init(struct XenDevice *xendev)
}
/* read-only ? */
+qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
if (strcmp(blkdev-mode, w) == 0) {
-qflags = BDRV_O_RDWR;
+qflags |= BDRV_O_RDWR;
} else {
-qflags = 0;
info |= VDISK_READONLY;
}
--
1.7.2.5
Re: [Qemu-devel] [QEMU][RFC PATCH 3/6] memory: Add xen memory hook
On 03/22/2012 05:44 PM, Jan Kiszka wrote:
static void core_region_nop(MemoryListener *listener,
diff --git a/ioport.c b/ioport.c
index 78a3b89..073ed75 100644
--- a/ioport.c
+++ b/ioport.c
@@ -28,6 +28,7 @@
#include ioport.h
#include trace.h
#include memory.h
+#include hw/xen.h
/***/
/* IO Port */
@@ -155,6 +156,11 @@ int register_ioport_read(pio_addr_t start, int length, int
size,
i);
ioport_opaque[i] = opaque;
}
+
+if (xen_enabled()) {
+xen_map_iorange(start, length, 0);
+}
+
return 0;
}
@@ -175,7 +181,13 @@ int register_ioport_write(pio_addr_t start, int length,
int size,
i);
ioport_opaque[i] = opaque;
}
+
+if (xen_enabled()) {
+xen_map_iorange(start, length, 0);
+}
+
return 0;
+
}
static uint32_t ioport_readb_thunk(void *opaque, uint32_t addr)
@@ -260,6 +272,11 @@ void isa_unassign_ioport(pio_addr_t start, int length)
ioport_destructor_table[start](ioport_opaque[start]);
ioport_destructor_table[start] = NULL;
}
+
+if (xen_enabled()) {
+xen_unmap_iorange(start, length, 0);
+}
+
for(i = start; i start + length; i++) {
ioport_read_table[0][i] = NULL;
ioport_read_table[1][i] = NULL;
memory_listener_register(xen_hooks, system_io)?
QEMU doesn't seem to call region_add/region_del for ioport.
Moreover, some of ioport are directly register without
using memory hook (for example cirrus vga).
What is the best way to do it ?
Even if that is not yet powerful enough, tuning the hooks is usually
better than open-coding.
Jan
[Qemu-devel] [PATCH 0/9] Alpha updates
Patch 1 has been seen before but not picked up. Patches 2-8 convert the target away from areg0. Patch 9 converts the target to make use of the new flush_inputs_to_zero flag provided by softfloat, rather than doing the same thing by hand. r~ Richard Henderson (9): alpha-linux-user: Initialize fpu to round-to-normal. target-alpha: Move integer helpers to int_helper.c. target-alpha: Move exception helpers to helper.c. target-alpha: Move floating-point helpers to fpu_helper.c. target-alpha: Move fpcr helpers from op_helper.c to helper.c. target-alpha: Move integer overflow helpers to int_helper.c. target-alpha: Move palcode support helpers to sys_helper.c. target-alpha: Move memory helpers to mem_helper.c. target-alpha: Make use of fp_status.flush_inputs_to_zero. Makefile.target |3 + configure |2 +- target-alpha/cpu.h|4 +- target-alpha/fpu_helper.c | 813 ++ target-alpha/helper.c | 61 ++- target-alpha/helper.h | 143 +++--- target-alpha/int_helper.c | 318 +++ target-alpha/mem_helper.c | 151 + target-alpha/op_helper.c | 1379 - target-alpha/sys_helper.c | 87 +++ target-alpha/translate.c | 221 +--- 11 files changed, 1631 insertions(+), 1551 deletions(-) create mode 100644 target-alpha/fpu_helper.c create mode 100644 target-alpha/int_helper.c create mode 100644 target-alpha/mem_helper.c delete mode 100644 target-alpha/op_helper.c create mode 100644 target-alpha/sys_helper.c -- 1.7.7.6
[Qemu-devel] [PATCH 3/9] target-alpha: Move exception helpers to helper.c.
Signed-off-by: Richard Henderson r...@twiddle.net
---
target-alpha/cpu.h |3 ++
target-alpha/helper.c| 39
target-alpha/helper.h|2 +-
target-alpha/op_helper.c | 73 --
target-alpha/translate.c |2 +-
5 files changed, 63 insertions(+), 56 deletions(-)
diff --git a/target-alpha/cpu.h b/target-alpha/cpu.h
index 48c0fdc..c7787f6 100644
--- a/target-alpha/cpu.h
+++ b/target-alpha/cpu.h
@@ -434,6 +434,9 @@ int cpu_alpha_handle_mmu_fault (CPUAlphaState *env,
uint64_t address, int rw,
int mmu_idx);
#define cpu_handle_mmu_fault cpu_alpha_handle_mmu_fault
void do_interrupt (CPUAlphaState *env);
+void do_restore_state(CPUAlphaState *, void *retaddr);
+void QEMU_NORETURN dynamic_excp(CPUAlphaState *, void *, int, int);
+void QEMU_NORETURN arith_excp(CPUAlphaState *, void *, int, uint64_t);
uint64_t cpu_alpha_load_fpcr (CPUAlphaState *env);
void cpu_alpha_store_fpcr (CPUAlphaState *env, uint64_t val);
diff --git a/target-alpha/helper.c b/target-alpha/helper.c
index 3f2e7c3..584457f 100644
--- a/target-alpha/helper.c
+++ b/target-alpha/helper.c
@@ -23,6 +23,7 @@
#include cpu.h
#include softfloat.h
+#include helper.h
uint64_t cpu_alpha_load_fpcr (CPUAlphaState *env)
{
@@ -484,3 +485,41 @@ void cpu_dump_state (CPUAlphaState *env, FILE *f,
fprintf_function cpu_fprintf,
}
cpu_fprintf(f, \n);
}
+
+void do_restore_state(CPUAlphaState *env, void *retaddr)
+{
+uintptr_t pc = (uintptr_t)retaddr;
+if (pc) {
+TranslationBlock *tb = tb_find_pc(pc);
+if (tb) {
+cpu_restore_state(tb, env, pc);
+}
+}
+}
+
+/* This should only be called from translate, via gen_excp.
+ We expect that ENV-PC has already been updated. */
+void QEMU_NORETURN helper_excp(CPUAlphaState *env, int excp, int error)
+{
+env-exception_index = excp;
+env-error_code = error;
+cpu_loop_exit(env);
+}
+
+/* This may be called from any of the helpers to set up EXCEPTION_INDEX. */
+void QEMU_NORETURN dynamic_excp(CPUAlphaState *env, void *retaddr,
+int excp, int error)
+{
+env-exception_index = excp;
+env-error_code = error;
+do_restore_state(env, retaddr);
+cpu_loop_exit(env);
+}
+
+void QEMU_NORETURN arith_excp(CPUAlphaState *env, void *retaddr,
+ int exc, uint64_t mask)
+{
+env-trap_arg0 = exc;
+env-trap_arg1 = mask;
+dynamic_excp(env, retaddr, EXCP_ARITH, 0);
+}
diff --git a/target-alpha/helper.h b/target-alpha/helper.h
index b693cee..91a9e39 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -1,6 +1,6 @@
#include def-helper.h
-DEF_HELPER_2(excp, void, int, int)
+DEF_HELPER_3(excp, void, env, int, int)
DEF_HELPER_FLAGS_0(load_pcc, TCG_CALL_CONST | TCG_CALL_PURE, i64)
DEF_HELPER_2(addqv, i64, i64, i64)
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index eab7a82..af5fa82 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -30,43 +30,6 @@
/*/
/* Exceptions processing helpers */
-/* This should only be called from translate, via gen_excp.
- We expect that ENV-PC has already been updated. */
-void QEMU_NORETURN helper_excp(int excp, int error)
-{
-env-exception_index = excp;
-env-error_code = error;
-cpu_loop_exit(env);
-}
-
-static void do_restore_state(void *retaddr)
-{
-unsigned long pc = (unsigned long)retaddr;
-
-if (pc) {
-TranslationBlock *tb = tb_find_pc(pc);
-if (tb) {
-cpu_restore_state(tb, env, pc);
-}
-}
-}
-
-/* This may be called from any of the helpers to set up EXCEPTION_INDEX. */
-static void QEMU_NORETURN dynamic_excp(int excp, int error)
-{
-env-exception_index = excp;
-env-error_code = error;
-do_restore_state(GETPC());
-cpu_loop_exit(env);
-}
-
-static void QEMU_NORETURN arith_excp(int exc, uint64_t mask)
-{
-env-trap_arg0 = exc;
-env-trap_arg1 = mask;
-dynamic_excp(EXCP_ARITH, 0);
-}
-
uint64_t helper_load_pcc (void)
{
#ifndef CONFIG_USER_ONLY
@@ -97,7 +60,7 @@ uint64_t helper_addqv (uint64_t op1, uint64_t op2)
uint64_t tmp = op1;
op1 += op2;
if (unlikely((tmp ^ op2 ^ (-1ULL)) (tmp ^ op1) (1ULL 63))) {
-arith_excp(EXC_M_IOV, 0);
+arith_excp(env, GETPC(), EXC_M_IOV, 0);
}
return op1;
}
@@ -107,7 +70,7 @@ uint64_t helper_addlv (uint64_t op1, uint64_t op2)
uint64_t tmp = op1;
op1 = (uint32_t)(op1 + op2);
if (unlikely((tmp ^ op2 ^ (-1UL)) (tmp ^ op1) (1UL 31))) {
-arith_excp(EXC_M_IOV, 0);
+arith_excp(env, GETPC(), EXC_M_IOV, 0);
}
return op1;
}
@@ -117,7 +80,7 @@ uint64_t helper_subqv (uint64_t op1, uint64_t op2)
uint64_t res;
res = op1 - op2;
if (unlikely((op1 ^ op2) (res ^ op1) (1ULL 63))) {
-
[Qemu-devel] [PATCH 1/9] alpha-linux-user: Initialize fpu to round-to-normal.
Signed-off-by: Richard Henderson r...@twiddle.net --- target-alpha/translate.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/target-alpha/translate.c b/target-alpha/translate.c index b51fe5c..2c24619 100644 --- a/target-alpha/translate.c +++ b/target-alpha/translate.c @@ -3513,7 +3513,8 @@ CPUAlphaState * cpu_alpha_init (const char *cpu_model) #if defined (CONFIG_USER_ONLY) env-ps = PS_USER_MODE; cpu_alpha_store_fpcr(env, (FPCR_INVD | FPCR_DZED | FPCR_OVFD - | FPCR_UNFD | FPCR_INED | FPCR_DNOD)); + | FPCR_UNFD | FPCR_INED | FPCR_DNOD + | FPCR_DYN_NORMAL)); #endif env-lock_addr = -1; env-fen = 1; -- 1.7.7.6
[Qemu-devel] [PATCH 7/9] target-alpha: Move palcode support helpers to sys_helper.c.
Signed-off-by: Richard Henderson r...@twiddle.net
---
Makefile.target |2 +-
target-alpha/helper.h | 10 +++---
target-alpha/op_helper.c | 65 -
target-alpha/sys_helper.c | 87 +
target-alpha/translate.c | 14
5 files changed, 100 insertions(+), 78 deletions(-)
create mode 100644 target-alpha/sys_helper.c
diff --git a/Makefile.target b/Makefile.target
index 256e7b5..254a9fa 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -96,7 +96,7 @@ libobj-y += cpu_init.o
endif
libobj-$(TARGET_SPARC) += int32_helper.o
libobj-$(TARGET_SPARC64) += int64_helper.o
-libobj-$(TARGET_ALPHA) += int_helper.o fpu_helper.o
+libobj-$(TARGET_ALPHA) += int_helper.o fpu_helper.o sys_helper.o
libobj-y += disas.o
libobj-$(CONFIG_TCI_DIS) += tci-dis.o
diff --git a/target-alpha/helper.h b/target-alpha/helper.h
index 45e187d..f057ecf 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -1,7 +1,7 @@
#include def-helper.h
DEF_HELPER_3(excp, void, env, int, int)
-DEF_HELPER_FLAGS_0(load_pcc, TCG_CALL_CONST | TCG_CALL_PURE, i64)
+DEF_HELPER_FLAGS_1(load_pcc, TCG_CALL_CONST | TCG_CALL_PURE, i64, env)
DEF_HELPER_3(addqv, i64, env, i64, i64)
DEF_HELPER_3(addlv, i64, env, i64, i64)
@@ -100,7 +100,7 @@ DEF_HELPER_2(ieee_input_cmp, i64, env, i64)
DEF_HELPER_2(ieee_input_s, i64, env, i64)
#if !defined (CONFIG_USER_ONLY)
-DEF_HELPER_1(hw_ret, void, i64)
+DEF_HELPER_2(hw_ret, void, env, i64)
DEF_HELPER_1(ldl_phys, i64, i64)
DEF_HELPER_1(ldq_phys, i64, i64)
@@ -111,13 +111,13 @@ DEF_HELPER_2(stq_phys, void, i64, i64)
DEF_HELPER_2(stl_c_phys, i64, i64, i64)
DEF_HELPER_2(stq_c_phys, i64, i64, i64)
-DEF_HELPER_FLAGS_0(tbia, TCG_CALL_CONST, void)
-DEF_HELPER_FLAGS_1(tbis, TCG_CALL_CONST, void, i64)
+DEF_HELPER_FLAGS_1(tbia, TCG_CALL_CONST, void, env)
+DEF_HELPER_FLAGS_2(tbis, TCG_CALL_CONST, void, env, i64)
DEF_HELPER_1(halt, void, i64);
DEF_HELPER_FLAGS_0(get_time, TCG_CALL_CONST, i64)
-DEF_HELPER_FLAGS_1(set_alarm, TCG_CALL_CONST, void, i64)
+DEF_HELPER_FLAGS_2(set_alarm, TCG_CALL_CONST, void, env, i64)
#endif
#include def-helper.h
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index c51b535..df1f01c 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -25,71 +25,6 @@
#include sysemu.h
#include qemu-timer.h
-/*/
-/* Exceptions processing helpers */
-
-uint64_t helper_load_pcc (void)
-{
-#ifndef CONFIG_USER_ONLY
-/* In system mode we have access to a decent high-resolution clock.
- In order to make OS-level time accounting work with the RPCC,
- present it with a well-timed clock fixed at 250MHz. */
-return (((uint64_t)env-pcc_ofs 32)
-| (uint32_t)(qemu_get_clock_ns(vm_clock) 2));
-#else
-/* In user-mode, vm_clock doesn't exist. Just pass through the host cpu
- clock ticks. Also, don't bother taking PCC_OFS into account. */
-return (uint32_t)cpu_get_real_ticks();
-#endif
-}
-
-/* PALcode support special instructions */
-#if !defined (CONFIG_USER_ONLY)
-void helper_hw_ret (uint64_t a)
-{
-env-pc = a ~3;
-env-intr_flag = 0;
-env-lock_addr = -1;
-if ((a 1) == 0) {
-env-pal_mode = 0;
-swap_shadow_regs(env);
-}
-}
-
-void helper_tbia(void)
-{
-tlb_flush(env, 1);
-}
-
-void helper_tbis(uint64_t p)
-{
-tlb_flush_page(env, p);
-}
-
-void helper_halt(uint64_t restart)
-{
-if (restart) {
-qemu_system_reset_request();
-} else {
-qemu_system_shutdown_request();
-}
-}
-
-uint64_t helper_get_time(void)
-{
-return qemu_get_clock_ns(rtc_clock);
-}
-
-void helper_set_alarm(uint64_t expire)
-{
-if (expire) {
-env-alarm_expire = expire;
-qemu_mod_timer(env-alarm_timer, expire);
-} else {
-qemu_del_timer(env-alarm_timer);
-}
-}
-#endif
/*/
/* Softmmu support */
diff --git a/target-alpha/sys_helper.c b/target-alpha/sys_helper.c
new file mode 100644
index 000..a26bb5c
--- /dev/null
+++ b/target-alpha/sys_helper.c
@@ -0,0 +1,87 @@
+/*
+ * Helpers for system instructions.
+ *
+ * Copyright (c) 2007 Jocelyn Mayer
+ *
+ * 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
Re: [Qemu-devel] [PATCH 6/6] arm: move load and store helpers, switch to AREG0 free mode
On 03/19/12 14:57, Blue Swirl wrote:
Add an explicit CPUARMState parameter instead of relying on AREG0
and move load and store helpers to helper.c. Remove AREG0 swapping in
tlb_fill(). Remove now empty op_helper.c.
Switch to AREG0 free mode. Use cpu_ld{l,uw}_code in translation
and interrupt handling.
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
Makefile.target|4 +-
configure |2 +-
target-arm/helper.c| 54 +---
target-arm/op_helper.c | 71
target-arm/translate.c |6 ++--
5 files changed, 56 insertions(+), 81 deletions(-)
delete mode 100644 target-arm/op_helper.c
Patches 2-6 (patch 1 mail lost?):
Reviewed-by: Richard Henderson r...@twiddle.net
r~
[Qemu-devel] [PATCH 5/9] target-alpha: Move fpcr helpers from op_helper.c to helper.c.
Signed-off-by: Richard Henderson r...@twiddle.net
---
target-alpha/helper.c| 14 --
target-alpha/helper.h|4 ++--
target-alpha/op_helper.c | 10 --
target-alpha/translate.c |6 +++---
4 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/target-alpha/helper.c b/target-alpha/helper.c
index 584457f..bfa 100644
--- a/target-alpha/helper.c
+++ b/target-alpha/helper.c
@@ -159,9 +159,19 @@ void cpu_alpha_store_fpcr (CPUAlphaState *env, uint64_t
val)
env-fpcr_undz = (val FPCR_UNDZ) != 0;
}
+uint64_t helper_load_fpcr(CPUAlphaState *env)
+{
+return cpu_alpha_load_fpcr(env);
+}
+
+void helper_store_fpcr(CPUAlphaState *env, uint64_t val)
+{
+cpu_alpha_store_fpcr(env, val);
+}
+
#if defined(CONFIG_USER_ONLY)
-int cpu_alpha_handle_mmu_fault (CPUAlphaState *env, target_ulong address, int
rw,
-int mmu_idx)
+int cpu_alpha_handle_mmu_fault(CPUAlphaState *env, target_ulong address,
+ int rw, int mmu_idx)
{
env-exception_index = EXCP_MMFAULT;
env-trap_arg0 = address;
diff --git a/target-alpha/helper.h b/target-alpha/helper.h
index d36df5f..e193c26 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -34,8 +34,8 @@ DEF_HELPER_FLAGS_1(pkwb, TCG_CALL_CONST | TCG_CALL_PURE, i64,
i64)
DEF_HELPER_FLAGS_1(unpkbl, TCG_CALL_CONST | TCG_CALL_PURE, i64, i64)
DEF_HELPER_FLAGS_1(unpkbw, TCG_CALL_CONST | TCG_CALL_PURE, i64, i64)
-DEF_HELPER_FLAGS_0(load_fpcr, TCG_CALL_CONST | TCG_CALL_PURE, i64)
-DEF_HELPER_FLAGS_1(store_fpcr, TCG_CALL_CONST, void, i64)
+DEF_HELPER_FLAGS_1(load_fpcr, TCG_CALL_CONST | TCG_CALL_PURE, i64, env)
+DEF_HELPER_FLAGS_2(store_fpcr, TCG_CALL_CONST, void, env, i64)
DEF_HELPER_FLAGS_1(f_to_memory, TCG_CALL_CONST | TCG_CALL_PURE, i32, i64)
DEF_HELPER_FLAGS_1(memory_to_f, TCG_CALL_CONST | TCG_CALL_PURE, i64, i32)
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index 6711d99..59ee31e 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -43,16 +43,6 @@ uint64_t helper_load_pcc (void)
#endif
}
-uint64_t helper_load_fpcr (void)
-{
-return cpu_alpha_load_fpcr (env);
-}
-
-void helper_store_fpcr (uint64_t val)
-{
-cpu_alpha_store_fpcr (env, val);
-}
-
uint64_t helper_addqv (uint64_t op1, uint64_t op2)
{
uint64_t tmp = op1;
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 29ab319..4589615 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -2678,17 +2678,17 @@ static ExitStatus translate_one(DisasContext *ctx,
uint32_t insn)
case 0x024:
/* MT_FPCR */
if (likely(ra != 31))
-gen_helper_store_fpcr(cpu_fir[ra]);
+gen_helper_store_fpcr(cpu_env, cpu_fir[ra]);
else {
TCGv tmp = tcg_const_i64(0);
-gen_helper_store_fpcr(tmp);
+gen_helper_store_fpcr(cpu_env, tmp);
tcg_temp_free(tmp);
}
break;
case 0x025:
/* MF_FPCR */
if (likely(ra != 31))
-gen_helper_load_fpcr(cpu_fir[ra]);
+gen_helper_load_fpcr(cpu_fir[ra], cpu_env);
break;
case 0x02A:
/* FCMOVEQ */
--
1.7.7.6
[Qemu-devel] [PATCH 6/9] target-alpha: Move integer overflow helpers to int_helper.c.
Signed-off-by: Richard Henderson r...@twiddle.net
---
target-alpha/helper.h | 12
target-alpha/int_helper.c | 63 +
target-alpha/op_helper.c | 62
target-alpha/translate.c | 44 ++-
4 files changed, 106 insertions(+), 75 deletions(-)
diff --git a/target-alpha/helper.h b/target-alpha/helper.h
index e193c26..45e187d 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -3,12 +3,12 @@
DEF_HELPER_3(excp, void, env, int, int)
DEF_HELPER_FLAGS_0(load_pcc, TCG_CALL_CONST | TCG_CALL_PURE, i64)
-DEF_HELPER_2(addqv, i64, i64, i64)
-DEF_HELPER_2(addlv, i64, i64, i64)
-DEF_HELPER_2(subqv, i64, i64, i64)
-DEF_HELPER_2(sublv, i64, i64, i64)
-DEF_HELPER_2(mullv, i64, i64, i64)
-DEF_HELPER_2(mulqv, i64, i64, i64)
+DEF_HELPER_3(addqv, i64, env, i64, i64)
+DEF_HELPER_3(addlv, i64, env, i64, i64)
+DEF_HELPER_3(subqv, i64, env, i64, i64)
+DEF_HELPER_3(sublv, i64, env, i64, i64)
+DEF_HELPER_3(mullv, i64, env, i64, i64)
+DEF_HELPER_3(mulqv, i64, env, i64, i64)
DEF_HELPER_FLAGS_2(umulh, TCG_CALL_CONST | TCG_CALL_PURE, i64, i64, i64)
DEF_HELPER_FLAGS_1(ctpop, TCG_CALL_CONST | TCG_CALL_PURE, i64, i64)
diff --git a/target-alpha/int_helper.c b/target-alpha/int_helper.c
index a46d71a..93a6417 100644
--- a/target-alpha/int_helper.c
+++ b/target-alpha/int_helper.c
@@ -253,3 +253,66 @@ uint64_t helper_unpkbw (uint64_t op1)
| ((op1 0xff) 16)
| ((op1 0xff00) 24));
}
+
+uint64_t helper_addqv (CPUAlphaState *env, uint64_t op1, uint64_t op2)
+{
+uint64_t tmp = op1;
+op1 += op2;
+if (unlikely((tmp ^ op2 ^ (-1ULL)) (tmp ^ op1) (1ULL 63))) {
+arith_excp(env, GETPC(), EXC_M_IOV, 0);
+}
+return op1;
+}
+
+uint64_t helper_addlv (CPUAlphaState *env, uint64_t op1, uint64_t op2)
+{
+uint64_t tmp = op1;
+op1 = (uint32_t)(op1 + op2);
+if (unlikely((tmp ^ op2 ^ (-1UL)) (tmp ^ op1) (1UL 31))) {
+arith_excp(env, GETPC(), EXC_M_IOV, 0);
+}
+return op1;
+}
+
+uint64_t helper_subqv (CPUAlphaState *env, uint64_t op1, uint64_t op2)
+{
+uint64_t res;
+res = op1 - op2;
+if (unlikely((op1 ^ op2) (res ^ op1) (1ULL 63))) {
+arith_excp(env, GETPC(), EXC_M_IOV, 0);
+}
+return res;
+}
+
+uint64_t helper_sublv (CPUAlphaState *env, uint64_t op1, uint64_t op2)
+{
+uint32_t res;
+res = op1 - op2;
+if (unlikely((op1 ^ op2) (res ^ op1) (1UL 31))) {
+arith_excp(env, GETPC(), EXC_M_IOV, 0);
+}
+return res;
+}
+
+uint64_t helper_mullv (CPUAlphaState *env, uint64_t op1, uint64_t op2)
+{
+int64_t res = (int64_t)op1 * (int64_t)op2;
+
+if (unlikely((int32_t)res != res)) {
+arith_excp(env, GETPC(), EXC_M_IOV, 0);
+}
+return (int64_t)((int32_t)res);
+}
+
+uint64_t helper_mulqv (CPUAlphaState *env, uint64_t op1, uint64_t op2)
+{
+uint64_t tl, th;
+
+muls64(tl, th, op1, op2);
+/* If th != 0 th != -1, then we had an overflow */
+if (unlikely((th + 1) 1)) {
+arith_excp(env, GETPC(), EXC_M_IOV, 0);
+}
+return tl;
+}
+
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index 59ee31e..c51b535 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -43,68 +43,6 @@ uint64_t helper_load_pcc (void)
#endif
}
-uint64_t helper_addqv (uint64_t op1, uint64_t op2)
-{
-uint64_t tmp = op1;
-op1 += op2;
-if (unlikely((tmp ^ op2 ^ (-1ULL)) (tmp ^ op1) (1ULL 63))) {
-arith_excp(env, GETPC(), EXC_M_IOV, 0);
-}
-return op1;
-}
-
-uint64_t helper_addlv (uint64_t op1, uint64_t op2)
-{
-uint64_t tmp = op1;
-op1 = (uint32_t)(op1 + op2);
-if (unlikely((tmp ^ op2 ^ (-1UL)) (tmp ^ op1) (1UL 31))) {
-arith_excp(env, GETPC(), EXC_M_IOV, 0);
-}
-return op1;
-}
-
-uint64_t helper_subqv (uint64_t op1, uint64_t op2)
-{
-uint64_t res;
-res = op1 - op2;
-if (unlikely((op1 ^ op2) (res ^ op1) (1ULL 63))) {
-arith_excp(env, GETPC(), EXC_M_IOV, 0);
-}
-return res;
-}
-
-uint64_t helper_sublv (uint64_t op1, uint64_t op2)
-{
-uint32_t res;
-res = op1 - op2;
-if (unlikely((op1 ^ op2) (res ^ op1) (1UL 31))) {
-arith_excp(env, GETPC(), EXC_M_IOV, 0);
-}
-return res;
-}
-
-uint64_t helper_mullv (uint64_t op1, uint64_t op2)
-{
-int64_t res = (int64_t)op1 * (int64_t)op2;
-
-if (unlikely((int32_t)res != res)) {
-arith_excp(env, GETPC(), EXC_M_IOV, 0);
-}
-return (int64_t)((int32_t)res);
-}
-
-uint64_t helper_mulqv (uint64_t op1, uint64_t op2)
-{
-uint64_t tl, th;
-
-muls64(tl, th, op1, op2);
-/* If th != 0 th != -1, then we had an overflow */
-if (unlikely((th + 1) 1)) {
-arith_excp(env, GETPC(), EXC_M_IOV, 0);
-}
-return tl;
-}
-
/* PALcode support special instructions */
#if !defined (CONFIG_USER_ONLY)
void helper_hw_ret (uint64_t a)
diff
[Qemu-devel] [PATCH 8/9] target-alpha: Move memory helpers to mem_helper.c.
This completes the transition away from AREG0. This patch must
be last because it requires CONFIG_TCG_PASS_AREG0 set too.
Signed-off-by: Richard Henderson r...@twiddle.net
---
Makefile.target |4 +-
configure |2 +-
target-alpha/helper.h |8 +-
target-alpha/mem_helper.c | 151 +
target-alpha/op_helper.c | 162 -
target-alpha/translate.c | 10 ++--
6 files changed, 164 insertions(+), 173 deletions(-)
create mode 100644 target-alpha/mem_helper.c
delete mode 100644 target-alpha/op_helper.c
diff --git a/Makefile.target b/Makefile.target
index 254a9fa..44b2e83 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -81,8 +81,10 @@ libobj-y += tcg/tcg.o tcg/optimize.o
libobj-$(CONFIG_TCG_INTERPRETER) += tci.o
libobj-y += fpu/softfloat.o
ifneq ($(TARGET_BASE_ARCH), sparc)
+ifneq ($(TARGET_BASE_ARCH), alpha)
libobj-y += op_helper.o
endif
+endif
libobj-y += helper.o
ifeq ($(TARGET_BASE_ARCH), i386)
libobj-y += cpuid.o
@@ -96,7 +98,7 @@ libobj-y += cpu_init.o
endif
libobj-$(TARGET_SPARC) += int32_helper.o
libobj-$(TARGET_SPARC64) += int64_helper.o
-libobj-$(TARGET_ALPHA) += int_helper.o fpu_helper.o sys_helper.o
+libobj-$(TARGET_ALPHA) += int_helper.o fpu_helper.o sys_helper.o mem_helper.o
libobj-y += disas.o
libobj-$(CONFIG_TCI_DIS) += tci-dis.o
diff --git a/configure b/configure
index 8b4e3c1..14ef738 100755
--- a/configure
+++ b/configure
@@ -3608,7 +3608,7 @@ case $target_arch2 in
esac
case $target_arch2 in
- sparc*)
+ alpha | sparc*)
echo CONFIG_TCG_PASS_AREG0=y $config_target_mak
;;
esac
diff --git a/target-alpha/helper.h b/target-alpha/helper.h
index f057ecf..03cc185 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -104,12 +104,12 @@ DEF_HELPER_2(hw_ret, void, env, i64)
DEF_HELPER_1(ldl_phys, i64, i64)
DEF_HELPER_1(ldq_phys, i64, i64)
-DEF_HELPER_1(ldl_l_phys, i64, i64)
-DEF_HELPER_1(ldq_l_phys, i64, i64)
+DEF_HELPER_2(ldl_l_phys, i64, env, i64)
+DEF_HELPER_2(ldq_l_phys, i64, env, i64)
DEF_HELPER_2(stl_phys, void, i64, i64)
DEF_HELPER_2(stq_phys, void, i64, i64)
-DEF_HELPER_2(stl_c_phys, i64, i64, i64)
-DEF_HELPER_2(stq_c_phys, i64, i64, i64)
+DEF_HELPER_3(stl_c_phys, i64, env, i64, i64)
+DEF_HELPER_3(stq_c_phys, i64, env, i64, i64)
DEF_HELPER_FLAGS_1(tbia, TCG_CALL_CONST, void, env)
DEF_HELPER_FLAGS_2(tbis, TCG_CALL_CONST, void, env, i64)
diff --git a/target-alpha/mem_helper.c b/target-alpha/mem_helper.c
new file mode 100644
index 000..a9109ad
--- /dev/null
+++ b/target-alpha/mem_helper.c
@@ -0,0 +1,151 @@
+/*
+ * Helpers for loads and stores
+ *
+ * Copyright (c) 2007 Jocelyn Mayer
+ *
+ * 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
+
+
+/* Softmmu support */
+#if !defined (CONFIG_USER_ONLY)
+
+uint64_t helper_ldl_phys(uint64_t p)
+{
+return (int32_t)ldl_phys(p);
+}
+
+uint64_t helper_ldq_phys(uint64_t p)
+{
+return ldq_phys(p);
+}
+
+uint64_t helper_ldl_l_phys(CPUAlphaState *env, uint64_t p)
+{
+env-lock_addr = p;
+return env-lock_value = (int32_t)ldl_phys(p);
+}
+
+uint64_t helper_ldq_l_phys(CPUAlphaState *env, uint64_t p)
+{
+env-lock_addr = p;
+return env-lock_value = ldq_phys(p);
+}
+
+void helper_stl_phys(uint64_t p, uint64_t v)
+{
+stl_phys(p, v);
+}
+
+void helper_stq_phys(uint64_t p, uint64_t v)
+{
+stq_phys(p, v);
+}
+
+uint64_t helper_stl_c_phys(CPUAlphaState *env, uint64_t p, uint64_t v)
+{
+uint64_t ret = 0;
+
+if (p == env-lock_addr) {
+int32_t old = ldl_phys(p);
+if (old == (int32_t)env-lock_value) {
+stl_phys(p, v);
+ret = 1;
+}
+}
+env-lock_addr = -1;
+
+return ret;
+}
+
+uint64_t helper_stq_c_phys(CPUAlphaState *env, uint64_t p, uint64_t v)
+{
+uint64_t ret = 0;
+
+if (p == env-lock_addr) {
+uint64_t old = ldq_phys(p);
+if (old == env-lock_value) {
+stq_phys(p, v);
+ret = 1;
+}
+}
+env-lock_addr = -1;
+
+return ret;
+}
+
+static void do_unaligned_access(CPUAlphaState *env, target_ulong addr,
+int is_write, int is_user, void *retaddr)
+{
+uint64_t pc;
+uint32_t insn;
+
+do_restore_state(env, retaddr);
+
+pc = env-pc;
+
Re: [Qemu-devel] [PATCH V2 0/4] MIPS ASE DSP Support for Qemu
+DEF_HELPER_1(absqsph, i32, i32) Many of these helpers merely compute a function. They do not trap, they do not modify global state. They should be using the DEF_HELPER_FLAGS_N macro to define them, so that the TCG compiler can optimize around the functions better. target-mips/op_helper.c | 3936 +++ 1 files changed, 3936 insertions(+), 0 deletions(-) Nearly 4000 lines to me says: put these in their own file. It would be my preference if this were done in a way that exposes any implicit uses of the ENV variable. But even failing that, the makefile can be adjusted to apply HELPER_CFLAGS to other helper files. r~
[Qemu-devel] [PATCH 9/9] target-alpha: Make use of fp_status.flush_inputs_to_zero.
This softfp feature post-dates the last major update to the Alpha
fpu translation. We can make use of this to eliminate at least
one helper function that was performing this operation by hand.
Signed-off-by: Richard Henderson r...@twiddle.net
---
target-alpha/cpu.h|1 -
target-alpha/fpu_helper.c | 44 ++--
target-alpha/helper.c |8 +++-
target-alpha/helper.h |5 ++---
target-alpha/translate.c | 18 +++---
5 files changed, 26 insertions(+), 50 deletions(-)
diff --git a/target-alpha/cpu.h b/target-alpha/cpu.h
index c7787f6..6c5d28b 100644
--- a/target-alpha/cpu.h
+++ b/target-alpha/cpu.h
@@ -234,7 +234,6 @@ struct CPUAlphaState {
uint8_t fpcr_exc_mask;
uint8_t fpcr_dyn_round;
uint8_t fpcr_flush_to_zero;
-uint8_t fpcr_dnz;
uint8_t fpcr_dnod;
uint8_t fpcr_undz;
diff --git a/target-alpha/fpu_helper.c b/target-alpha/fpu_helper.c
index 39c411a..feb4e6f 100644
--- a/target-alpha/fpu_helper.c
+++ b/target-alpha/fpu_helper.c
@@ -88,21 +88,17 @@ void helper_fp_exc_raise_s(CPUAlphaState *env, uint32_t
exc, uint32_t regno)
}
}
-/* Input remapping without software completion. Handle denormal-map-to-zero
- and trap for all other non-finite numbers. */
-uint64_t helper_ieee_input(CPUAlphaState *env, uint64_t val)
+/* Input handing without software completion. Trap for all
+ non-finite numbers. */
+void helper_ieee_input(CPUAlphaState *env, uint64_t val)
{
uint32_t exp = (uint32_t)(val 52) 0x7ff;
uint64_t frac = val 0xfull;
if (exp == 0) {
-if (frac != 0) {
-/* If DNZ is set flush denormals to zero on input. */
-if (env-fpcr_dnz) {
-val = 1ull 63;
-} else {
-arith_excp(env, GETPC(), EXC_M_UNF, 0);
-}
+/* Denormals without DNZ set raise an exception. */
+if (frac != 0 !env-fp_status.flush_inputs_to_zero) {
+arith_excp(env, GETPC(), EXC_M_UNF, 0);
}
} else if (exp == 0x7ff) {
/* Infinity or NaN. */
@@ -111,43 +107,23 @@ uint64_t helper_ieee_input(CPUAlphaState *env, uint64_t
val)
just emulates the insn to figure out what exception to use. */
arith_excp(env, GETPC(), frac ? EXC_M_INV : EXC_M_FOV, 0);
}
-return val;
}
/* Similar, but does not trap for infinities. Used for comparisons. */
-uint64_t helper_ieee_input_cmp(CPUAlphaState *env, uint64_t val)
+void helper_ieee_input_cmp(CPUAlphaState *env, uint64_t val)
{
uint32_t exp = (uint32_t)(val 52) 0x7ff;
uint64_t frac = val 0xfull;
if (exp == 0) {
-if (frac != 0) {
-/* If DNZ is set flush denormals to zero on input. */
-if (env-fpcr_dnz) {
-val = 1ull 63;
-} else {
-arith_excp(env, GETPC(), EXC_M_UNF, 0);
-}
+/* Denormals without DNZ set raise an exception. */
+if (frac != 0 !env-fp_status.flush_inputs_to_zero) {
+arith_excp(env, GETPC(), EXC_M_UNF, 0);
}
} else if (exp == 0x7ff frac) {
/* NaN. */
arith_excp(env, GETPC(), EXC_M_INV, 0);
}
-return val;
-}
-
-/* Input remapping with software completion enabled. All we have to do
- is handle denormal-map-to-zero; all other inputs get exceptions as
- needed from the actual operation. */
-uint64_t helper_ieee_input_s(CPUAlphaState *env, uint64_t val)
-{
-if (env-fpcr_dnz) {
-uint32_t exp = (uint32_t)(val 52) 0x7ff;
-if (exp == 0) {
-val = 1ull 63;
-}
-}
-return val;
}
/* F floating (VAX) */
diff --git a/target-alpha/helper.c b/target-alpha/helper.c
index bfa..765e650 100644
--- a/target-alpha/helper.c
+++ b/target-alpha/helper.c
@@ -82,7 +82,7 @@ uint64_t cpu_alpha_load_fpcr (CPUAlphaState *env)
break;
}
-if (env-fpcr_dnz) {
+if (env-fp_status.flush_inputs_to_zero) {
r |= FPCR_DNZ;
}
if (env-fpcr_dnod) {
@@ -151,12 +151,10 @@ void cpu_alpha_store_fpcr (CPUAlphaState *env, uint64_t
val)
}
env-fpcr_dyn_round = t;
-env-fpcr_flush_to_zero
- = (val (FPCR_UNDZ|FPCR_UNFD)) == (FPCR_UNDZ|FPCR_UNFD);
-
-env-fpcr_dnz = (val FPCR_DNZ) != 0;
env-fpcr_dnod = (val FPCR_DNOD) != 0;
env-fpcr_undz = (val FPCR_UNDZ) != 0;
+env-fpcr_flush_to_zero = env-fpcr_dnod env-fpcr_undz;
+env-fp_status.flush_inputs_to_zero = (val FPCR_DNZ) != 0;
}
uint64_t helper_load_fpcr(CPUAlphaState *env)
diff --git a/target-alpha/helper.h b/target-alpha/helper.h
index 03cc185..9f97c5d 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -95,9 +95,8 @@ DEF_HELPER_FLAGS_1(fp_exc_get, TCG_CALL_CONST |
TCG_CALL_PURE, i32, env)
DEF_HELPER_3(fp_exc_raise, void, env, i32, i32)
DEF_HELPER_3(fp_exc_raise_s, void, env, i32, i32)
-DEF_HELPER_2(ieee_input, i64,
[Qemu-devel] [PATCH 2/9] target-alpha: Move integer helpers to int_helper.c.
Signed-off-by: Richard Henderson r...@twiddle.net
---
Makefile.target |1 +
target-alpha/int_helper.c | 255 +
target-alpha/op_helper.c | 233 -
3 files changed, 256 insertions(+), 233 deletions(-)
create mode 100644 target-alpha/int_helper.c
diff --git a/Makefile.target b/Makefile.target
index 63cf769..ddeb7e0 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -96,6 +96,7 @@ libobj-y += cpu_init.o
endif
libobj-$(TARGET_SPARC) += int32_helper.o
libobj-$(TARGET_SPARC64) += int64_helper.o
+libobj-$(TARGET_ALPHA) += int_helper.o
libobj-y += disas.o
libobj-$(CONFIG_TCI_DIS) += tci-dis.o
diff --git a/target-alpha/int_helper.c b/target-alpha/int_helper.c
new file mode 100644
index 000..a46d71a
--- /dev/null
+++ b/target-alpha/int_helper.c
@@ -0,0 +1,255 @@
+/*
+ * Helpers for integer and multimedia instructions.
+ *
+ * Copyright (c) 2007 Jocelyn Mayer
+ *
+ * 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 host-utils.h
+
+
+uint64_t helper_umulh (uint64_t op1, uint64_t op2)
+{
+uint64_t tl, th;
+mulu64(tl, th, op1, op2);
+return th;
+}
+
+uint64_t helper_ctpop (uint64_t arg)
+{
+return ctpop64(arg);
+}
+
+uint64_t helper_ctlz (uint64_t arg)
+{
+return clz64(arg);
+}
+
+uint64_t helper_cttz (uint64_t arg)
+{
+return ctz64(arg);
+}
+
+static inline uint64_t byte_zap(uint64_t op, uint8_t mskb)
+{
+uint64_t mask;
+
+mask = 0;
+mask |= ((mskb 0) 1) * 0x00FFULL;
+mask |= ((mskb 1) 1) * 0xFF00ULL;
+mask |= ((mskb 2) 1) * 0x00FFULL;
+mask |= ((mskb 3) 1) * 0xFF00ULL;
+mask |= ((mskb 4) 1) * 0x00FFULL;
+mask |= ((mskb 5) 1) * 0xFF00ULL;
+mask |= ((mskb 6) 1) * 0x00FFULL;
+mask |= ((mskb 7) 1) * 0xFF00ULL;
+
+return op ~mask;
+}
+
+uint64_t helper_zap(uint64_t val, uint64_t mask)
+{
+return byte_zap(val, mask);
+}
+
+uint64_t helper_zapnot(uint64_t val, uint64_t mask)
+{
+return byte_zap(val, ~mask);
+}
+
+uint64_t helper_cmpbge (uint64_t op1, uint64_t op2)
+{
+uint8_t opa, opb, res;
+int i;
+
+res = 0;
+for (i = 0; i 8; i++) {
+opa = op1 (i * 8);
+opb = op2 (i * 8);
+if (opa = opb)
+res |= 1 i;
+}
+return res;
+}
+
+uint64_t helper_minub8 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+uint8_t opa, opb, opr;
+int i;
+
+for (i = 0; i 8; ++i) {
+opa = op1 (i * 8);
+opb = op2 (i * 8);
+opr = opa opb ? opa : opb;
+res |= (uint64_t)opr (i * 8);
+}
+return res;
+}
+
+uint64_t helper_minsb8 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+int8_t opa, opb;
+uint8_t opr;
+int i;
+
+for (i = 0; i 8; ++i) {
+opa = op1 (i * 8);
+opb = op2 (i * 8);
+opr = opa opb ? opa : opb;
+res |= (uint64_t)opr (i * 8);
+}
+return res;
+}
+
+uint64_t helper_minuw4 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+uint16_t opa, opb, opr;
+int i;
+
+for (i = 0; i 4; ++i) {
+opa = op1 (i * 16);
+opb = op2 (i * 16);
+opr = opa opb ? opa : opb;
+res |= (uint64_t)opr (i * 16);
+}
+return res;
+}
+
+uint64_t helper_minsw4 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+int16_t opa, opb;
+uint16_t opr;
+int i;
+
+for (i = 0; i 4; ++i) {
+opa = op1 (i * 16);
+opb = op2 (i * 16);
+opr = opa opb ? opa : opb;
+res |= (uint64_t)opr (i * 16);
+}
+return res;
+}
+
+uint64_t helper_maxub8 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+uint8_t opa, opb, opr;
+int i;
+
+for (i = 0; i 8; ++i) {
+opa = op1 (i * 8);
+opb = op2 (i * 8);
+opr = opa opb ? opa : opb;
+res |= (uint64_t)opr (i * 8);
+}
+return res;
+}
+
+uint64_t helper_maxsb8 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+int8_t opa, opb;
+uint8_t opr;
+int i;
+
+for (i = 0; i 8; ++i) {
+opa = op1 (i * 8);
+opb = op2 (i * 8);
+opr = opa opb ? opa : opb;
+res |= (uint64_t)opr (i * 8);
+}
[Qemu-devel] [PATCH v5 1/2] target-arm: Drop cpu_arm_close()
It's unused, so no need to QOM'ify it later.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-arm/cpu.h|1 -
target-arm/helper.c |5 -
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 26c114b..69ef142 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -238,7 +238,6 @@ typedef struct CPUARMState {
CPUARMState *cpu_arm_init(const char *cpu_model);
void arm_translate_init(void);
int cpu_arm_exec(CPUARMState *s);
-void cpu_arm_close(CPUARMState *s);
void do_interrupt(CPUARMState *);
void switch_mode(CPUARMState *, int);
uint32_t do_arm_semihosting(CPUARMState *env);
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 1314f23..1ce8105 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -493,11 +493,6 @@ static uint32_t cpu_arm_find_by_name(const char *name)
return id;
}
-void cpu_arm_close(CPUARMState *env)
-{
-g_free(env);
-}
-
static int bad_mode_switch(CPUARMState *env, int mode)
{
/* Return true if it is not valid for us to switch to
--
1.7.7
[Qemu-devel] [PATCH v5 2/2] target-arm: Minimalistic CPU QOM'ification
Introduce only one non-abstract type TYPE_ARM_CPU and do not touch
cp15 registers to not interfere with Peter's ongoing remodelling.
Embed CPUARMState as first (additional) field of ARMCPU.
Signed-off-by: Andreas Färber afaer...@suse.de
---
Makefile.target |1 +
target-arm/cpu-qom.h | 68 ++
target-arm/cpu.c | 37 +++
target-arm/cpu.h |1 +
target-arm/helper.c |4 ++-
5 files changed, 110 insertions(+), 1 deletions(-)
create mode 100644 target-arm/cpu-qom.h
create mode 100644 target-arm/cpu.c
diff --git a/Makefile.target b/Makefile.target
index 63cf769..4fa03e4 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -90,6 +90,7 @@ endif
libobj-$(TARGET_SPARC64) += vis_helper.o
libobj-$(CONFIG_NEED_MMU) += mmu.o
libobj-$(TARGET_ARM) += neon_helper.o iwmmxt_helper.o
+libobj-$(TARGET_ARM) += cpu.o
ifeq ($(TARGET_BASE_ARCH), sparc)
libobj-y += fop_helper.o cc_helper.o win_helper.o mmu_helper.o ldst_helper.o
libobj-y += cpu_init.o
diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h
new file mode 100644
index 000..464a29b
--- /dev/null
+++ b/target-arm/cpu-qom.h
@@ -0,0 +1,68 @@
+/*
+ * QEMU ARM CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see
+ * http://www.gnu.org/licenses/gpl-2.0.html
+ */
+#ifndef QEMU_ARM_CPU_QOM_H
+#define QEMU_ARM_CPU_QOM_H
+
+#include qemu/cpu.h
+#include cpu.h
+
+#define TYPE_ARM_CPU arm-cpu
+
+#define ARM_CPU_CLASS(klass) \
+OBJECT_CLASS_CHECK(ARMCPUClass, (klass), TYPE_ARM_CPU)
+#define ARM_CPU(obj) \
+OBJECT_CHECK(ARMCPU, (obj), TYPE_ARM_CPU)
+#define ARM_CPU_GET_CLASS(obj) \
+OBJECT_GET_CLASS(ARMCPUClass, (obj), TYPE_ARM_CPU)
+
+/**
+ * ARMCPUClass:
+ *
+ * An ARM CPU model.
+ */
+typedef struct ARMCPUClass {
+/* private */
+CPUClass parent_class;
+/* public */
+} ARMCPUClass;
+
+/**
+ * ARMCPU:
+ * @env: #CPUARMState
+ *
+ * An ARM CPU core.
+ */
+typedef struct ARMCPU {
+/* private */
+CPUState parent_obj;
+/* public */
+
+CPUARMState env;
+} ARMCPU;
+
+static inline ARMCPU *arm_env_get_cpu(CPUARMState *env)
+{
+return ARM_CPU(container_of(env, ARMCPU, env));
+}
+
+#define ENV_GET_CPU(e) CPU(arm_env_get_cpu(e))
+
+
+#endif
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
new file mode 100644
index 000..8019be0
--- /dev/null
+++ b/target-arm/cpu.c
@@ -0,0 +1,37 @@
+/*
+ * QEMU ARM CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see
+ * http://www.gnu.org/licenses/gpl-2.0.html
+ */
+
+#include cpu-qom.h
+#include qemu-common.h
+
+static const TypeInfo arm_cpu_type_info = {
+.name = TYPE_ARM_CPU,
+.parent = TYPE_CPU,
+.instance_size = sizeof(ARMCPU),
+.abstract = false, /* TODO Reconsider once cp15 reworked. */
+.class_size = sizeof(ARMCPUClass),
+};
+
+static void arm_cpu_register_types(void)
+{
+type_register_static(arm_cpu_type_info);
+}
+
+type_init(arm_cpu_register_types)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 69ef142..a68df61 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -475,6 +475,7 @@ static inline void cpu_clone_regs(CPUARMState *env,
target_ulong newsp)
#endif
#include cpu-all.h
+#include cpu-qom.h
/* Bit usage in the TB flags field: */
#define ARM_TBFLAG_THUMB_SHIFT 0
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 1ce8105..709de52 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -400,6 +400,7 @@ static int vfp_gdb_set_reg(CPUARMState *env, uint8_t *buf,
int reg)
CPUARMState *cpu_arm_init(const char *cpu_model)
{
+ARMCPU *cpu;
CPUARMState *env;
uint32_t id;
static int inited = 0;
@@ -407,7 +408,8 @@ CPUARMState *cpu_arm_init(const char *cpu_model)
[Qemu-devel] [PATCH v5 0/2] QOM'ify ARM CPU
Hello Peter, Following long discussions about where this series collides with cp15 rework and whether things should be done declarative as in eepro100.c or imperative, I have stripped down the series to the bare minimum necessary for proceeding with QOM'ifying the remaining targets. This does not mean that all patches were invalid, it's an intermediate step. Please apply to target-arm.next tree. Any further target-arm QOM cleanups can then be based onto it. Available at: https://github.com/afaerber/qemu-cpu/commits/qom-cpu-arm.v5 Regards, Andreas Cc: Anthony Liguori anth...@codemonkey.ws Cc: Peter Maydell peter.mayd...@linaro.org Cc: Paul Brook p...@codesourcery.com Cc: Andrzej Zaborowski balr...@gmail.com v4 - v5: * Use only one non-abstract CPU type for now, leave everything else as is. * Drop cpu_arm_close() instead of converting it. * Still make available cpu-qom.h through cpu.h for convenience. v3 - v4: * Rebased on top of type_init() v2, object_class_get_list() v2, qom-cpu v4. * Rename cpu-core.h to cpu-qom.h. While the term ARM core is quite common, it is less so for other architectures like s390x so use a neutral term. * Use container_of() for CPUState - CPU macros (suggested by Anthony). * Rework arm_env_get_object() - arm_env_get_cpu(), avoids some casts (suggested by Anthony). Also rename ENV_GET_OBJECT() - ENV_GET_CPU(). * Sort -cpu ? list. * Use object_class_get_list() and sort ourselves rather than using object_class_foreach_ordered() with callbacks (suggested by Anthony). * Drop ARMCPUClass jtag_id since it turned out unneeded in QEMU (Peter+Andrzej). * Drop experimental halted property since that should be in common code. * Introduce cpuid-variant and cpuid-revision properties. * Use CPU properties to drop unneeded pxa270-* classes. * Move /cpu child property to integratorcp machine. v2 - v3: * Rebased against qom-upstream.14 branch (and that against master). * Rename target-arm/cpu-core.c to cpu.c now that we no longer need VPATH. * Leave cpu-core.h as is to separate from legacy cpu.h. * Fix -cpu alias pxa270: handled in cpu_arm_init(). * Use proper GPL headers. * Start removing CPUID uses in cpu_reset_model_id() and cpu.h. * Fully convert cpu_reset_model_id() to ARMCPUInfo or per-model code. * Experiment with adding properties (halted). * For testing, add a /cpu child property (HACK). v1 - v2: * Cherry-pick Anthony's object_class_foreach() patch. * Fix ARMCPUClass type name (arm-cpu-core - arm-cpu). * Add documentation. * Rename ARMCPUDef to ARMCPUInfo. * Use a C99-style table for initializing the classes through class_data instead of individual class_init functions (suggested by Anthony). * Prepare reset callback. * Make ENV_GET_OBJECT() use an inline function for readability. * Invoke the CPU's reset method from cpu_reset(). * Do feature initialization via table where sensible. * Add feature flags to ARMCPU as well (suggested by PMM for future tweaking, also simplifies load/save a bit) and initialize them from ARMCPUClass. * Make feature inference work for ARMCPU as well by not passing the ARMCPUClass. Use function-local macros to avoid the ugliness of deferencing the features pointer. Andreas Färber (2): target-arm: Drop cpu_arm_close() target-arm: Minimalistic CPU QOM'ification Makefile.target |1 + target-arm/cpu-qom.h | 68 ++ target-arm/cpu.c | 37 +++ target-arm/cpu.h |2 +- target-arm/helper.c |9 ++ 5 files changed, 110 insertions(+), 7 deletions(-) create mode 100644 target-arm/cpu-qom.h create mode 100644 target-arm/cpu.c -- 1.7.7
Re: [Qemu-devel] [QEMU][RFC PATCH 3/6] memory: Add xen memory hook
On 2012-03-23 16:08, Julien Grall wrote:
On 03/22/2012 05:44 PM, Jan Kiszka wrote:
static void core_region_nop(MemoryListener *listener,
diff --git a/ioport.c b/ioport.c
index 78a3b89..073ed75 100644
--- a/ioport.c
+++ b/ioport.c
@@ -28,6 +28,7 @@
#include ioport.h
#include trace.h
#include memory.h
+#include hw/xen.h
/***/
/* IO Port */
@@ -155,6 +156,11 @@ int register_ioport_read(pio_addr_t start, int
length, int size,
i);
ioport_opaque[i] = opaque;
}
+
+if (xen_enabled()) {
+xen_map_iorange(start, length, 0);
+}
+
return 0;
}
@@ -175,7 +181,13 @@ int register_ioport_write(pio_addr_t start, int
length, int size,
i);
ioport_opaque[i] = opaque;
}
+
+if (xen_enabled()) {
+xen_map_iorange(start, length, 0);
+}
+
return 0;
+
}
static uint32_t ioport_readb_thunk(void *opaque, uint32_t addr)
@@ -260,6 +272,11 @@ void isa_unassign_ioport(pio_addr_t start, int
length)
ioport_destructor_table[start](ioport_opaque[start]);
ioport_destructor_table[start] = NULL;
}
+
+if (xen_enabled()) {
+xen_unmap_iorange(start, length, 0);
+}
+
for(i = start; i start + length; i++) {
ioport_read_table[0][i] = NULL;
ioport_read_table[1][i] = NULL;
memory_listener_register(xen_hooks, system_io)?
QEMU doesn't seem to call region_add/region_del for ioport.
Moreover, some of ioport are directly register without
using memory hook (for example cirrus vga).
What is the best way to do it ?
I haven't looked at details. Maybe it is just a combination of use case
not yet considered, but can easily be added and need to switch legacy
code to new scheme. Then this still remains the better option than this
hook. Avi?
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2 06/10] qapi: untangle next_list
On Thu, Mar 22, 2012 at 10:38:40PM +0100, Paolo Bonzini wrote:
Right now, the semantics of next_list are complicated. The caller must:
* call start_list
* call next_list for each element *including the first*
* on the first call to next_list, the second argument should point to
NULL and the result is the head of the list. On subsequent calls,
the second argument should point to the last node (last result of
next_list) and next_list itself tacks the element at the tail of the
list.
This works for both input and output visitor, but having the visitor
write memory when it is only reading the list is ugly. Plus, relying
on *list to detect the first call is tricky and undocumented.
We can initialize so-entry in next_list instead of start_list, leaving
it NULL in start_list. This way next_list sees clearly whether it is
on the first call---as a bonus, it discriminates the cases based on
internal state of the visitor rather than external state. We can
also pull the assignment of the list head from generated code up to
next_list.
Nice cleanup. We'd originally moved assignment of the list head out of
next_list because we had no way of knowing whether it was the first call
at that point, so it was either always assign the current entry or
never, so we did the latter, but that complicated the calling code.
Now that we can make that distinction I think doing this change makes
sense.
Patch in general looks good as well.
Reviewed-by: Michael Roth mdr...@linux.vnet.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
docs/qapi-code-gen.txt |4 ++--
qapi/qmp-input-visitor.c | 22 +-
scripts/qapi-visit.py|4 ++--
3 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
index 5831e37..ad11767 100644
--- a/docs/qapi-code-gen.txt
+++ b/docs/qapi-code-gen.txt
@@ -194,11 +194,11 @@ Example:
void visit_type_UserDefOneList(Visitor *m, UserDefOneList ** obj, const
char *name, Error **errp)
{
-GenericList *i;
+GenericList *i, **prev = (GenericList **)obj;
visit_start_list(m, name, errp);
-for (i = visit_next_list(m, (GenericList **)obj, errp); i; i =
visit_next_list(m, i, errp)) {
+for (; (i = visit_next_list(m, prev, errp)) != NULL; prev = i) {
UserDefOneList *native_i = (UserDefOneList *)i;
visit_type_UserDefOne(m, native_i-value, NULL, errp);
}
diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
index ef9288f..413e333 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qmp-input-visitor.c
@@ -64,9 +64,7 @@ static const QObject *qmp_input_get_object(QmpInputVisitor
*qiv,
static void qmp_input_push(QmpInputVisitor *qiv, const QObject *obj, Error
**errp)
{
qiv-stack[qiv-nb_stack].obj = obj;
-if (qobject_type(obj) == QTYPE_QLIST) {
-qiv-stack[qiv-nb_stack].entry = qlist_first(qobject_to_qlist(obj));
-}
+qiv-stack[qiv-nb_stack].entry = NULL;
qiv-nb_stack++;
if (qiv-nb_stack = QIV_STACK_SIZE) {
@@ -132,18 +130,24 @@ static GenericList *qmp_input_next_list(Visitor *v,
GenericList **list,
QmpInputVisitor *qiv = to_qiv(v);
GenericList *entry;
StackObject *so = qiv-stack[qiv-nb_stack - 1];
+bool first;
+
+if (so-entry == NULL) {
+so-entry = qlist_first(qobject_to_qlist(so-obj));
+first = true;
+} else {
+so-entry = qlist_next(so-entry);
+first = false;
+}
if (so-entry == NULL) {
return NULL;
}
entry = g_malloc0(sizeof(*entry));
-if (*list) {
-so-entry = qlist_next(so-entry);
-if (so-entry == NULL) {
-g_free(entry);
-return NULL;
-}
+if (first) {
+*list = entry;
+} else {
(*list)-next = entry;
}
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index a85fb76..1ff81f4 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -86,14 +86,14 @@ def generate_visit_list(name, members):
void visit_type_%(name)sList(Visitor *m, %(name)sList ** obj, const char
*name, Error **errp)
{
-GenericList *i, **head = (GenericList **)obj;
+GenericList *i, **prev = (GenericList **)obj;
if (error_is_set(errp)) {
return;
}
visit_start_list(m, name, errp);
-for (*head = i = visit_next_list(m, head, errp); i; i =
visit_next_list(m, i, errp)) {
+for (; (i = visit_next_list(m, prev, errp)) != NULL; prev = i) {
%(name)sList *native_i = (%(name)sList *)i;
visit_type_%(name)s(m, native_i-value, NULL, errp);
}
--
1.7.9.1
Re: [Qemu-devel] [QEMU][RFC PATCH 3/6] memory: Add xen memory hook
On 03/22/2012 11:01 AM, Julien Grall wrote:
QEMU will now register all memory range (PIO and MMIO) in Xen.
We distinct two phases in memory registered :
- initialization
- running
For all range registered during the initialization, QEMU will
check with XenStore if it is authorized to use them.
After the initialization, QEMU can register all range. Indeed,
the new ranges will be for PCI Bar.
Signed-off-by: Julien Gralljulien.gr...@citrix.com
---
exec.c|9 ++
ioport.c | 17
xen-all.c | 83 +
3 files changed, 109 insertions(+), 0 deletions(-)
diff --git a/exec.c b/exec.c
index 780f63f..42d8c56 100644
--- a/exec.c
+++ b/exec.c
@@ -3557,12 +3557,21 @@ static void core_commit(MemoryListener *listener)
static void core_region_add(MemoryListener *listener,
MemoryRegionSection *section)
{
+if (xen_enabled()) {
+ xen_map_iorange(section-offset_within_address_space,
+ section-size, 1);
+}
+
cpu_register_physical_memory_log(section, section-readonly);
}
static void core_region_del(MemoryListener *listener,
MemoryRegionSection *section)
{
+if (xen_enabled()) {
+ xen_unmap_iorange(section-offset_within_address_space,
+ section-size, 1);
+}
}
static void core_region_nop(MemoryListener *listener,
diff --git a/ioport.c b/ioport.c
index 78a3b89..073ed75 100644
--- a/ioport.c
+++ b/ioport.c
@@ -28,6 +28,7 @@
#include ioport.h
#include trace.h
#include memory.h
+#include hw/xen.h
/***/
/* IO Port */
@@ -155,6 +156,11 @@ int register_ioport_read(pio_addr_t start, int length, int
size,
i);
ioport_opaque[i] = opaque;
}
+
+if (xen_enabled()) {
+xen_map_iorange(start, length, 0);
+}
+
return 0;
}
@@ -175,7 +181,13 @@ int register_ioport_write(pio_addr_t start, int length,
int size,
i);
ioport_opaque[i] = opaque;
}
+
+if (xen_enabled()) {
+xen_map_iorange(start, length, 0);
+}
+
return 0;
+
}
This is the opposite direction we need to head.
I really don't think this series is the right way to handle things. I don't
want to see random hooks throughout QEMU to intercept for APIs affectively
disabling large chunks of QEMU in the process.
You should look at (1) creating only the devices you want (2) use a clean
interface to interact with those devices.
That would mean having a Xen specific AddressSpaceOps for ioports or something
like that. Not having hooks in areas of code like this.
Regards,
Anthony Liguori
Re: [Qemu-devel] [PATCH 0/7] QOM'ify UniCore32 CPU
Am 14.03.2012 08:32, schrieb Guan Xuetao: On Wed, 2012-03-14 at 02:39 +0100, Andreas Färber wrote: Based on qom-cpu v4 and object_class_get_list() v2, this series converts the UniCore32 CPU to QOM. Code-wise, target-unicore32 is pretty close to target-arm and faces a similar issue of CPU-dependent init code, so let's tackle it next. Patch 1 adds a UniCore32 CPU guest core (TCG) section to MAINTAINERS, so that the target-unicore32 author gets notified of patches against his code. Patch 2, based on feedback from Guan Xuetao, changes the license of most target-unicore32 files from GPLv2 to GPLv2+. Anthony had contributed a qemu_malloc() - g_malloc() substitution that he can't relicense at this time, so leave that as GPLv2 and declare my following patches explicitly as GPLv2+. Patch 2 embeds CPUUniCore32State into UniCore32CPU. My new cpu-qom.h header can be GPLv2+, but into cpu.c we're moving helper.c code so make it GPLv2 for now. Patches 4-7 move code out of the uc32_cpu_init() function and into classes. I pulled the latest qemu code, but these patches seems to rely on the former qom-cpu v4 series. That series has been applied in the meantime, so unicore32 should no longer depend on other series. Could you tell me where I can pull the testable branch/tree? Sorry, repo.or.cz was having problems at the time of posting, this v1 series is now available at: git://repo.or.cz/qemu/afaerber.git qom-cpu-unicore32.v1 http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-cpu-unicore32.v1 I've added links to the Wiki for my work-in-progress branches on GitHub: http://wiki.qemu.org/Features/QOM/CPU Today I've reworked the preceding ARM series and rebased onto v5; I still need to revisit the table-driven class initialization before sending out a v2. MAINTAINERS and licenses are already adjusted. 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] block: add the support to drain throttled requests
On Fri, Mar 23, 2012 at 11:32 AM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Mar 23, 2012 at 11:02 AM, Richard Davies rich...@arachsys.com wrote: Stefan Hajnoczi wrote: Hi. We were producing the IDE assert()s and deadlocks with linux kernels. Although I believe the same symptoms exist on windows, I haven't actually tested it myself. Typically they would show up in the 16-bit bootloader code, even before the 32-bit OS has started. Okay, that makes sense. Bootloaders and the BIOS may use the simplest driver interface - which may be PIO in the case. I asked because the IDE DMA code path should work with I/O throttling and Windows is known for sometimes falling back to the PIO code path when some heuristics trigger. Whilst the bootloader was the easiest place for us to replicate this deadlock, we have also seen it with running Linux VMs. Older Linux kernels (e.g. CentOS 5) will fall back to PIO mode on IDE devices if they experience storage timeouts (e.g. due to heavy contention of underlying storage from other VMs). Hence, the IO limits deadlock can lead to running Linux VMs locking up as well as just Windows and Linux bootloaders. Thanks for pointing out that Linux falls back too. I have a prototype that converts hw/ide/core.c to asynchronous I/O functions. It still needs to be cleaned up and tested against Windows (Linux with libata.dma=0 is happy). Patches will be sent next week. Stefan
Re: [Qemu-devel] [PATCH v5 1/2] target-arm: Drop cpu_arm_close()
On 23 March 2012 16:24, Andreas Färber afaer...@suse.de wrote: It's unused, so no need to QOM'ify it later. Signed-off-by: Andreas Färber afaer...@suse.de Reviewed-by: Peter Maydell peter.mayd...@linaro.org
Re: [Qemu-devel] [PATCH 11/11 v10] introduce a new monitor command 'dump-guest-memory' to dump guest's memory
On Fri, 23 Mar 2012 17:06:22 +0900 ( )
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 11/11 v10] introduce a new monitor command
'dump-guest-memory' to dump guest's memory
Date: Tue, 20 Mar 2012 11:57:43 +0800
cut
+typedef struct DumpState {
+ArchDumpInfo dump_info;
+MemoryMappingList list;
+uint16_t phdr_num;
+uint32_t sh_info;
+bool have_section;
+bool resume;
+target_phys_addr_t memory_offset;
+write_core_dump_function f;
f() is so general. Type information is meaningless enough, but there's
no explicit occurence of the function call of f(). Could you consider
renaming?
Agreed. I actually don't see why this indirection is needed.
Re: [Qemu-devel] [PATCH v5 2/2] target-arm: Minimalistic CPU QOM'ification
On 23 March 2012 16:24, Andreas Färber afaer...@suse.de wrote: Introduce only one non-abstract type TYPE_ARM_CPU and do not touch cp15 registers to not interfere with Peter's ongoing remodelling. Embed CPUARMState as first (additional) field of ARMCPU. Signed-off-by: Andreas Färber afaer...@suse.de Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
Re: [Qemu-devel] [PATCH v5 0/2] QOM'ify ARM CPU
2012/3/23 Andreas Färber afaer...@suse.de: Following long discussions about where this series collides with cp15 rework and whether things should be done declarative as in eepro100.c or imperative, I have stripped down the series to the bare minimum necessary for proceeding with QOM'ifying the remaining targets. This does not mean that all patches were invalid, it's an intermediate step. Please apply to target-arm.next tree. Any further target-arm QOM cleanups can then be based onto it. Looks OK to me. I managed to balance my wobbly stack of cp15 related patches on top of it: http://git.linaro.org/gitweb?p=people/pmaydell/qemu-arm.git;a=shortlog;h=refs/heads/cp15-on-qom-on-miniqom (the third patch which creates QOM subclasses for each cpu implementation is doing too many things and needs splitting, and there's still plenty of stuff TODO but it's where I currently think we ought to be heading...) -- PMM
Re: [Qemu-devel] [PATCH 11/11 v10] introduce a new monitor command 'dump-guest-memory' to dump guest's memory
On Tue, 20 Mar 2012 11:57:43 +0800
Wen Congyang we...@cn.fujitsu.com wrote:
The command's usage:
dump [-p] protocol [begin] [length]
The supported protocol can be file or fd:
1. file: the protocol starts with file:, and the following string is
the file's path.
2. fd: the protocol starts with fd:, and the following string is the
fd's name.
Note:
1. If you want to use gdb to process the core, please specify -p option.
The reason why the -p option is not default is: guest machine in a
catastrophic state can have corrupted memory, which we cannot trust.
2. This command doesn't support the fd that is is associated with a pipe,
socket, or FIFO(lseek will fail with such fd).
3. If you don't want to dump all guest's memory, please specify the start
physical address and the length.
All the explanation above (except the HMP command-line) pertains to the
qapi-schema.json file.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
Makefile.target |2 +-
dump.c | 841
++
elf.h|5 +
hmp-commands.hx | 28 ++
hmp.c| 22 ++
hmp.h|1 +
memory_mapping.c | 27 ++
memory_mapping.h |3 +
qapi-schema.json | 18 ++
qmp-commands.hx | 38 +++
10 files changed, 984 insertions(+), 1 deletions(-)
create mode 100644 dump.c
diff --git a/Makefile.target b/Makefile.target
index c3aa5d7..0e179c9 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -219,7 +219,7 @@ obj-$(CONFIG_NO_KVM) += kvm-stub.o
obj-$(CONFIG_VGA) += vga.o
obj-y += memory.o savevm.o
obj-y += memory_mapping.o
-obj-$(CONFIG_HAVE_CORE_DUMP) += arch_dump.o
+obj-$(CONFIG_HAVE_CORE_DUMP) += arch_dump.o dump.o
LIBS+=-lz
obj-i386-$(CONFIG_KVM) += hyperv.o
diff --git a/dump.c b/dump.c
new file mode 100644
index 000..917bccc
--- /dev/null
+++ b/dump.c
@@ -0,0 +1,841 @@
+/*
+ * QEMU dump
+ *
+ * Copyright Fujitsu, Corp. 2011, 2012
+ *
+ * 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.
+ *
+ */
+
+#include qemu-common.h
+#include unistd.h
+#include elf.h
+#include sys/procfs.h
+#include glib.h
+#include cpu.h
+#include cpu-all.h
+#include targphys.h
+#include monitor.h
+#include kvm.h
+#include dump.h
+#include sysemu.h
+#include bswap.h
+#include memory_mapping.h
+#include error.h
+#include qmp-commands.h
+#include gdbstub.h
+
+static inline uint16_t cpu_convert_to_target16(uint16_t val, int endian)
+{
+if (endian == ELFDATA2LSB) {
+val = cpu_to_le16(val);
+} else {
+val = cpu_to_be16(val);
+}
+
+return val;
+}
+
+static inline uint32_t cpu_convert_to_target32(uint32_t val, int endian)
+{
+if (endian == ELFDATA2LSB) {
+val = cpu_to_le32(val);
+} else {
+val = cpu_to_be32(val);
+}
+
+return val;
+}
+
+static inline uint64_t cpu_convert_to_target64(uint64_t val, int endian)
+{
+if (endian == ELFDATA2LSB) {
+val = cpu_to_le64(val);
+} else {
+val = cpu_to_be64(val);
+}
+
+return val;
+}
Nitpick: I personally, wouldn't make these functions inline.
+
+typedef struct DumpState {
+ArchDumpInfo dump_info;
+MemoryMappingList list;
+uint16_t phdr_num;
+uint32_t sh_info;
+bool have_section;
+bool resume;
+target_phys_addr_t memory_offset;
+write_core_dump_function f;
+void (*cleanup)(void *opaque);
+void *opaque;
+
+RAMBlock *block;
+ram_addr_t start;
+bool has_filter;
+int64_t begin;
+int64_t length;
+} DumpState;
+
+static DumpState *dump_get_current(void)
+{
+static DumpState current_dump;
+
+return current_dump;
+}
You can drop this function if you allocate DumpState in the stack in
qmp_dump_guest_memory().
+
+static int dump_cleanup(DumpState *s)
+{
+int ret = 0;
+
+memory_mapping_list_free(s-list);
+s-cleanup(s-opaque);
+if (s-resume) {
+vm_start();
+}
+
+return ret;
+}
+
+static void dump_error(DumpState *s, const char *reason)
+{
+dump_cleanup(s);
+}
+
+static int write_elf64_header(DumpState *s)
+{
+Elf64_Ehdr elf_header;
+int ret;
+int endian = s-dump_info.d_endian;
+
+memset(elf_header, 0, sizeof(Elf64_Ehdr));
+memcpy(elf_header, ELFMAG, 4);
+elf_header.e_ident[EI_CLASS] = ELFCLASS64;
+elf_header.e_ident[EI_DATA] = s-dump_info.d_endian;
+elf_header.e_ident[EI_VERSION] = EV_CURRENT;
+elf_header.e_type = cpu_convert_to_target16(ET_CORE, endian);
+elf_header.e_machine = cpu_convert_to_target16(s-dump_info.d_machine,
+ endian);
+elf_header.e_version = cpu_convert_to_target32(EV_CURRENT, endian);
+
Re: [Qemu-devel] [PATCH 00/11 v10] introducing a new, dedicated guest memory dump mechanism
On Tue, 20 Mar 2012 11:28:17 +0800 Wen Congyang we...@cn.fujitsu.com wrote: Hi, all 'virsh dump' can not work when host pci device is used by guest. We have discussed this issue here: http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html I've reviewed the QMP part of this series and it looks good to me (only spot small things). Now, I'd like to get an ACK from Jan and/or Anthony before applying, specially wrt the fact this is a long running synchronous command (btw, I think this is ok, as this command is more likely to run when the VM guest crashes...).
Re: [Qemu-devel] [PATCH v5 0/2] QOM'ify ARM CPU
On 23 March 2012 17:17, Peter Maydell peter.mayd...@linaro.org wrote: 2012/3/23 Andreas Färber afaer...@suse.de: Following long discussions about where this series collides with cp15 rework and whether things should be done declarative as in eepro100.c or imperative, I have stripped down the series to the bare minimum necessary for proceeding with QOM'ifying the remaining targets. This does not mean that all patches were invalid, it's an intermediate step. Please apply to target-arm.next tree. Any further target-arm QOM cleanups can then be based onto it. Looks OK to me. Oh, these two patches are currently the only thing in target-arm.next. At the usual rate I would probably send out a pullreq end of next week; feel free to get them committed earlier by other means if you need them to unblock something else. -- PMM
Re: [Qemu-devel] [RFC 11/12] target-sparc: QOM'ify CPU
Am 14.03.2012 21:16, schrieb Blue Swirl:
On Wed, Mar 14, 2012 at 17:53, Andreas Färber afaer...@suse.de wrote:
diff --git a/target-sparc/cpu-qom.h b/target-sparc/cpu-qom.h
new file mode 100644
index 000..15dcf84
--- /dev/null
+++ b/target-sparc/cpu-qom.h
[...]
+/**
+ * SPARCCPUClass:
+ * @parent_reset: The parent class' reset handler.
+ *
+ * A SPARC CPU model.
+ */
+typedef struct SPARCCPUClass {
+/* private */
+CPUClass parent_class;
+/* public */
+
+void (*parent_reset)(CPUState *cpu);
+
+target_ulong iu_version;
+uint32_t fpu_version;
+uint32_t mmu_version;
+uint32_t mmu_bm;
+uint32_t mmu_ctpr_mask;
+uint32_t mmu_cxr_mask;
+uint32_t mmu_sfsr_mask;
+uint32_t mmu_trcr_mask;
+uint32_t mxcc_version;
+uint32_t features;
+uint32_t nwindows;
+uint32_t maxtl;
+} SPARCCPUClass;
+
+/**
+ * SPARCCPU:
+ * @env: Legacy CPU state.
+ *
+ * A SPARC CPU.
+ */
+typedef struct SPARCCPU {
+/* private */
+CPUState parent_obj;
+/* public */
+
+CPUSPARCState env;
+
+target_ulong iu_version;
+uint32_t fpu_version;
+uint32_t mmu_version;
+uint32_t features;
+uint32_t nwindows;
+} SPARCCPU;
The fields do not look correct at all, the same fields are in both
structs.
Formerly you had the model of an array of sparc_def_t structs, which you
would duplicate and then associate with CPUSPARCState, modifying the
duplicate.
SPARCCPUClass exists only once though. Therefore we cannot modify
classes based on command line parameters and must do so on the instance
instead. I have therefore duplicated some fields from class to instance
as you have noticed, initialized the object's value from the class' and
let any -cpu options modify the latter.
The same pattern has been used for arm and i386. On arm my v5 postpones
this by doing a bare-bones conversion for now; on x86 the only request
so far was to set the values via QOM properties.
Moreover Sparc32 and Sparc64 fields are mixed. Maybe I don't
fully understand the conversion.
Mixed fields likely means they were mixed in your original code. It is a
mostly mechanical conversion.
Would it be possible to make a common parent class which is then
specialized by Sparc32 and Sparc64 classes? There are many common
fields but also many 32/64 specific ones. Also cpu_common.c, cpu32.c
and cpu64.c to avoid #ifdeffery?
That is possible, but I would ask that you do such split-ups later.
Discussions for arm and ppc have shown that the structure of subclasses
in lack of multi-inheritence can be a tricky and controversial issue and
requires a lot of target knowledge that I do not posses for sparc.
Also, restructuring target code, e.g., into multiple files is orthogonal
to the goal of QOM'ifying all target CPUs and doing cleanups in common code.
If you think this is heading into a totally wrong direction due to some
in-progress work of yours, we could strip it down like target-arm v5,
but ATM I don't believe so. ;)
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] Can VMX provide real mode support?
On Wed, 21 Mar 2012 15:48:43 +0200 Avi Kivity a...@redhat.com wrote: On 03/21/2012 03:40 PM, Jan Kiszka wrote: On 2012-03-21 13:38, GaoYi wrote: Hi Jan, Since the newest Intel-VT supports the guest OS under the real mode, which was already supported in AMD-V, can the VMX in the latest KVM support that case? Yes, both with our without that unrestricted guest support (as Intel called it), real mode will generally work. Without that CPU feature, I think to recall that there were some limitations for big real mode, not sure. Yes, big real mode will not work without unrestricted guest. There was some work to emulate it (module option emulate_invalid_guest_state), but it is not complete. Can you provide a pointer for this? series?
Re: [Qemu-devel] [PATCH] qemu-ga: stub out guest-suspend* for non-linux
On Tue, 20 Mar 2012 19:54:09 -0500
Michael Roth mdr...@linux.vnet.ibm.com wrote:
This currently breaks the build for BSDs.
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
qga/commands-posix.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 89dde92..16737d7 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -24,10 +24,12 @@
#include sys/types.h
#include sys/ioctl.h
+#if defined(__linux__)
#include ifaddrs.h
#include arpa/inet.h
#include sys/socket.h
#include net/if.h
+#endif
#include sys/wait.h
#include qga/guest-agent-core.h
#include qga-qmp-commands.h
@@ -542,6 +544,7 @@ int64_t qmp_guest_fsfreeze_thaw(Error **err)
#define SUSPEND_SUPPORTED 0
#define SUSPEND_NOT_SUPPORTED 1
Missing the macros and I think reopen_fd_to_null() is missing too, also
doesn't apply to latest master.
+#if defined(__linux__)
/**
* This function forks twice and the information about the mode support
* status is passed to the qemu-ga process via a pipe.
@@ -729,6 +732,25 @@ void qmp_guest_suspend_hybrid(Error **err)
guest_suspend(pm-suspend-hybrid, NULL, err);
}
+#else /* defined(linux) */
+
+void qmp_guest_suspend_disk(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+}
+
+void qmp_guest_suspend_ram(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+}
+
+void qmp_guest_suspend_hybrid(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+}
+
+#endif
+
#if defined(__linux__)
I think it would be nice to reorganize the functions in this file so that
we could have only one #if defined(__linux__) (or even split this into two
files)...
static GuestNetworkInterfaceList *
guest_find_interface(GuestNetworkInterfaceList *head,
Re: [Qemu-devel] [PATCH 00/11 v10] introducing a new, dedicated guest memory dump mechanism
On 03/19/2012 10:28 PM, Wen Congyang wrote: Hi, all 'virsh dump' can not work when host pci device is used by guest. We have discussed this issue here: http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html The last version is here: http://lists.nongnu.org/archive/html/qemu-devel/2012-03/msg02536.html We have determined to introduce a new command dump-guest-memory to dump guest's memory. The core file's format is elf32 or elf64. These patches aren't properly threaded and I don't see patch 5/11. Can you resubmit with git-send-email and follow the info on the wiki http://wiki.qemu.org/Contribute/SubmitAPatch Regards, Anthony Liguori
[Qemu-devel] used a qemu-processor ?
Hello , I am a student from kit Karlsruhe, Germany . I have a question, can I used a qemu-processor for example (MicroBlaze, PowerPC or Mips) for my external SystemC platform , not qemu-platform, the Processors-sources code use only in Qemu-platform? my SystemC simulator is : a NoC-simulator with a Cycle accurat (CA) developed: . and I must integrate processors in my NOC, but are not modeled in SystemC. if it is, it is modeled for TLM-T or TLM-CA? Thank you for your help Imrani I'm looking forward to your reply. Many greetings. Imrani
Re: [Qemu-devel] [PATCH] block: add the support to drain throttled requests
Stefan Hajnoczi wrote: Hi. We were producing the IDE assert()s and deadlocks with linux kernels. Although I believe the same symptoms exist on windows, I haven't actually tested it myself. Typically they would show up in the 16-bit bootloader code, even before the 32-bit OS has started. Okay, that makes sense. Bootloaders and the BIOS may use the simplest driver interface - which may be PIO in the case. I asked because the IDE DMA code path should work with I/O throttling and Windows is known for sometimes falling back to the PIO code path when some heuristics trigger. Whilst the bootloader was the easiest place for us to replicate this deadlock, we have also seen it with running Linux VMs. Older Linux kernels (e.g. CentOS 5) will fall back to PIO mode on IDE devices if they experience storage timeouts (e.g. due to heavy contention of underlying storage from other VMs). Hence, the IO limits deadlock can lead to running Linux VMs locking up as well as just Windows and Linux bootloaders. Cheers, Richard.
[Qemu-devel] Windows Virtio Issue
Dear Yan, We seem to be having some trouble with virtio disk on Windows Server 2008 R2 running on qemu-kvm. Essentially, when disk IO is stressed, it seems to blue screen. These are potentially contended disks, since it's public cloud with multiple customers on the host - the issue could be connected to contention making disk response slow? Pertinent facts: * qemu-kvm 1.0 * Hosts have linux kernel 3.2.2, 64 bit, AMD Opteron 6128 * VM is Windows Server 2008 R2, 64 bit - all patches downloaded from MS * Virtio disk drivers are the February 2012 release .2200. Problem is apparent with the older .2000 driver as well. * Blue screen shows failure in viostor.sys - screen cap and minidump are at http://dl.dropbox.com/u/12332019/2200BSOD.zip * Replication: Yes. Easily. In this case I stressed the disk by running Crystal Disk mark (a free IO measuring tool). When it got to the 4 KB random seek tests - I think it was on write - it would consistently blue screen. * If it would help, I can provide remote access to this virtual machine if you wish - it's in our cloud system. * qemu-kvm command line: qemu-kvm -m MEMORY -smp SMP -cpu host -nodefaults -vga cirrus -vnc :1 -drive if=none,id=block.0,format=raw, cache=writeback,file=drive.img -device virtio-blk-pci,bootindex=1, drive=block.0 -monitor stdio Any help would be greatly appreciated. Regards, Paul Fisher Operations Manager ElasticHosts Ltd
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 10/15] xc: Add argument to allocate more special pages
On Thu, 2012-03-22 at 15:59 +, Julien Grall wrote:
This patchs permits to allocate more special pages. Indeed, for multiple
ioreq server, we need to have 2 shared pages by server.
xc_hvm_build will take an argument which will indicate the number of
special pages we want to allocate.
struct xc_hvm_build_args was just added to avoid exactly this
proliferation of arguments, you should add this there.
Signed-off-by: Julien Grall julien.gr...@citrix.com
---
tools/libxc/xc_hvm_build.c | 57 +--
tools/libxc/xenguest.h |6 +++-
tools/libxc/xg_private.c |3 +-
3 files changed, 39 insertions(+), 27 deletions(-)
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 696c012..62b4ff1 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -47,10 +47,11 @@
#define SPECIALPAGE_IDENT_PT 6
#define SPECIALPAGE_CONSOLE 7
#define NR_SPECIAL_PAGES 8
-#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+#define special_pfn(x, add) (0xff000u - (NR_SPECIAL_PAGES + (add)) + (x))
static void build_hvm_info(void *hvm_info_page, uint64_t mem_size,
- uint64_t mmio_start, uint64_t mmio_size)
+ uint64_t mmio_start, uint64_t mmio_size,
+ uint32_t nr_special_pages)
{
struct hvm_info_table *hvm_info = (struct hvm_info_table *)
(((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
@@ -78,7 +79,7 @@ static void build_hvm_info(void *hvm_info_page, uint64_t
mem_size,
/* Memory parameters. */
hvm_info-low_mem_pgend = lowmem_end PAGE_SHIFT;
hvm_info-high_mem_pgend = highmem_end PAGE_SHIFT;
-hvm_info-reserved_mem_pgstart = special_pfn(0);
+hvm_info-reserved_mem_pgstart = special_pfn(0, nr_special_pages);
/* Finish with the checksum. */
for ( i = 0, sum = 0; i hvm_info-length; i++ )
@@ -141,7 +142,8 @@ static int check_mmio_hole(uint64_t start, uint64_t
memsize,
static int setup_guest(xc_interface *xch,
uint32_t dom, const struct xc_hvm_build_args *args,
- char *image, unsigned long image_size)
+ char *image, unsigned long image_size,
+ uint32_t nr_special_pages)
{
xen_pfn_t *page_array = NULL;
unsigned long i, nr_pages = args-mem_size PAGE_SHIFT;
@@ -334,37 +336,42 @@ static int setup_guest(xc_interface *xch,
xch, dom, PAGE_SIZE, PROT_READ | PROT_WRITE,
HVM_INFO_PFN)) == NULL )
goto error_out;
-build_hvm_info(hvm_info_page, v_end, mmio_start, mmio_size);
+build_hvm_info(hvm_info_page, v_end, mmio_start, mmio_size,
nr_special_pages);
munmap(hvm_info_page, PAGE_SIZE);
/* Allocate and clear special pages. */
-for ( i = 0; i NR_SPECIAL_PAGES; i++ )
+for ( i = 0; i (NR_SPECIAL_PAGES + nr_special_pages); i++ )
{
-xen_pfn_t pfn = special_pfn(i);
+xen_pfn_t pfn = special_pfn(i, nr_special_pages);
rc = xc_domain_populate_physmap_exact(xch, dom, 1, 0, 0, pfn);
if ( rc != 0 )
{
PERROR(Could not allocate %d'th special page., i);
goto error_out;
}
-if ( xc_clear_domain_page(xch, dom, special_pfn(i)) )
+if ( xc_clear_domain_page(xch, dom, special_pfn(i,
nr_special_pages)) )
goto error_out;
}
xc_set_hvm_param(xch, dom, HVM_PARAM_STORE_PFN,
- special_pfn(SPECIALPAGE_XENSTORE));
+ special_pfn(SPECIALPAGE_XENSTORE, nr_special_pages));
xc_set_hvm_param(xch, dom, HVM_PARAM_BUFIOREQ_PFN,
- special_pfn(SPECIALPAGE_BUFIOREQ));
+ special_pfn(SPECIALPAGE_BUFIOREQ, nr_special_pages));
xc_set_hvm_param(xch, dom, HVM_PARAM_IOREQ_PFN,
- special_pfn(SPECIALPAGE_IOREQ));
+ special_pfn(SPECIALPAGE_IOREQ, nr_special_pages));
xc_set_hvm_param(xch, dom, HVM_PARAM_CONSOLE_PFN,
- special_pfn(SPECIALPAGE_CONSOLE));
+ special_pfn(SPECIALPAGE_CONSOLE, nr_special_pages));
xc_set_hvm_param(xch, dom, HVM_PARAM_PAGING_RING_PFN,
- special_pfn(SPECIALPAGE_PAGING));
+ special_pfn(SPECIALPAGE_PAGING, nr_special_pages));
xc_set_hvm_param(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
- special_pfn(SPECIALPAGE_ACCESS));
+ special_pfn(SPECIALPAGE_ACCESS, nr_special_pages));
xc_set_hvm_param(xch, dom, HVM_PARAM_SHARING_RING_PFN,
- special_pfn(SPECIALPAGE_SHARING));
+ special_pfn(SPECIALPAGE_SHARING, nr_special_pages));
+xc_set_hvm_param(xch, dom, HVM_PARAM_IO_PFN_FIRST,
+ special_pfn(NR_SPECIAL_PAGES, nr_special_pages));
+
Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH 11/15] xc: Fix python build
On Thu, 2012-03-22 at 15:59 +, Julien Grall wrote: Quickly fix for hvm_build in python. If an earlier patch breaks the build then this need to be part of that patch to allow bisection. Signed-off-by: Julien Grall julien.gr...@citrix.com --- tools/python/xen/lowlevel/xc/xc.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c index 7c89756..eb004b6 100644 --- a/tools/python/xen/lowlevel/xc/xc.c +++ b/tools/python/xen/lowlevel/xc/xc.c @@ -984,8 +984,9 @@ static PyObject *pyxc_hvm_build(XcObject *self, if ( target == -1 ) target = memsize; +// Ugly fix : we must retrieve the number of servers if ( xc_hvm_build_target_mem(self-xc_handle, dom, memsize, - target, image) != 0 ) + target, image, 0) != 0 ) return pyxc_error_to_exception(self-xc_handle); #if !defined(__ia64__)
