Re: [Qemu-devel] Virtual memory question
On Mon, Aug 9, 2010 at 7:15 AM, Mulyadi Santosa wrote: > On Mon, Aug 9, 2010 at 03:33, Dennis wrote: >> Hi, >> >> I've been looking at the qemu source code but couldn't find anything >> that would suit my needs. >> Basically I'm looking for a way to use a file on disk as physical >> memory inside Qemu. > > Once when I did code adventure in Qemu, I conclude Qemu create > temporary file (possibly using mktemp()) and mmap it, thus creating > "illusion" file as RAM for guest. > > So, I think it's already done. It's just not configurable through > command parameter Use -mem-path /path/to/directory. It's used for hugetlbfs support on Linux but it should work on a normal filesystem too. Stefan
[Qemu-devel] [Tracing] Compilation failure
Hi Stefan,
I think this needs to be resolved.
CCtrace.o
CCsimpletrace.o
cc1: warnings being treated as errors
/home/prerna/qemu-testing/git/qemu/simpletrace.c: In function
‘write_header’:
/home/prerna/qemu-testing/git/qemu/simpletrace.c:46: error: integer
constant is too large for ‘long’ type
/home/prerna/qemu-testing/git/qemu/simpletrace.c:46: error: large
integer implicitly truncated to unsigned type
make: *** [simpletrace.o] Error 1
The error arises due to :
TraceRecord header = {
.event = -1UL, /* max avoids conflicting with TraceEventIDs */
.timestamp_ns = 0xf2b177cb0aa429b4, /* magic number */
error.
Also, it would be better to #define the magic number to some macro, and
use that instead of using the constant directly.
Regards,
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
[Qemu-devel] Re: [Tracing] Compilation failure
On Mon, Aug 09, 2010 at 02:26:05PM +0530, Prerna Saxena wrote:
> Hi Stefan,
> I think this needs to be resolved.
>
> CCtrace.o
> CCsimpletrace.o
> cc1: warnings being treated as errors
> /home/prerna/qemu-testing/git/qemu/simpletrace.c: In function
> ‘write_header’:
> /home/prerna/qemu-testing/git/qemu/simpletrace.c:46: error: integer
> constant is too large for ‘long’ type
> /home/prerna/qemu-testing/git/qemu/simpletrace.c:46: error: large
> integer implicitly truncated to unsigned type
> make: *** [simpletrace.o] Error 1
>
> The error arises due to :
> TraceRecord header = {
> .event = -1UL, /* max avoids conflicting with TraceEventIDs */
> .timestamp_ns = 0xf2b177cb0aa429b4, /* magic number */
> error.
>
> Also, it would be better to #define the magic number to some macro,
> and use that instead of using the constant directly.
Thanks for pointing this out. The trace file format does not use
portable field sizes. The unsigned long field size changes depending on
the host architecture (32-bit or 64-bit).
I think 64-bit fields is reasonable. 32-bit hosts will not make use of
the high 32-bits but that seems okay.
Stefan
Re: [Qemu-devel] [PATCH v2] rtc: Remove TARGET_I386 from qemu-config.c, enables driftfix
On 08/06/2010 03:40 PM, Amit Shah wrote:
On (Fri) Aug 06 2010 [12:12:45], Daniel P. Berrange wrote:
On Wed, Jun 23, 2010 at 08:14:04PM +0530, Amit Shah wrote:
qemu-config.c doesn't contain any target-specific code, and the
TARGET_I386 conditional code didn't get compiled as a result. Removing
this enables the driftfix parameter for rtc.
Signed-off-by: Amit Shah
---
qemu-config.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index 95abe61..730ffd9 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -247,11 +247,9 @@ QemuOptsList qemu_rtc_opts = {
},{
.name = "clock",
.type = QEMU_OPT_STRING,
-#ifdef TARGET_I386
},{
.name = "driftfix",
.type = QEMU_OPT_STRING,
-#endif
},
{ /* end if list */ }
},
Is there any reason this patch hasn't been applied to GIT yet ? I'm told
that using this option is critical to making certain guests work reliably
so we want to use it from libvirt/virt-manager for the OS in question.
Multiple pings have gone out already; I hope it's in someone's queue to
be applied
Sorry, I've got it now. In the future, please resend patches with
[RESEND] as opposed to just bumping it.
Regards,
Anthony Liguori
Amit
[Qemu-devel] [PATCH] trace: Make trace record fields 64-bit
Explicitly use 64-bit fields in trace records so that timestamps and
magic numbers work for 32-bit host builds.
Signed-off-by: Stefan Hajnoczi
---
simpletrace.c | 31 +--
simpletrace.h | 11 ++-
simpletrace.py |2 +-
tracetool |6 +++---
4 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/simpletrace.c b/simpletrace.c
index 954cc4e..01acfc5 100644
--- a/simpletrace.c
+++ b/simpletrace.c
@@ -9,18 +9,29 @@
*/
#include
+#include
#include
#include
#include "trace.h"
+/** Trace file header event ID */
+#define HEADER_EVENT_ID (~(uint64_t)0) /* avoids conflicting with
TraceEventIDs */
+
+/** Trace file magic number */
+#define HEADER_MAGIC 0xf2b177cb0aa429b4ULL
+
+/** Trace file version number, bump if format changes */
+#define HEADER_VERSION 0
+
+/** Trace buffer entry */
typedef struct {
-unsigned long event;
-unsigned long timestamp_ns;
-unsigned long x1;
-unsigned long x2;
-unsigned long x3;
-unsigned long x4;
-unsigned long x5;
+uint64_t event;
+uint64_t timestamp_ns;
+uint64_t x1;
+uint64_t x2;
+uint64_t x3;
+uint64_t x4;
+uint64_t x5;
} TraceRecord;
enum {
@@ -42,9 +53,9 @@ void st_print_trace_file_status(FILE *stream, int
(*stream_printf)(FILE *stream,
static bool write_header(FILE *fp)
{
TraceRecord header = {
-.event = -1UL, /* max avoids conflicting with TraceEventIDs */
-.timestamp_ns = 0xf2b177cb0aa429b4, /* magic number */
-.x1 = 0, /* bump this version number if file format changes */
+.event = HEADER_EVENT_ID,
+.timestamp_ns = HEADER_MAGIC,
+.x1 = HEADER_VERSION,
};
return fwrite(&header, sizeof header, 1, fp) == 1;
diff --git a/simpletrace.h b/simpletrace.h
index 6a2b8d9..f81aa8e 100644
--- a/simpletrace.h
+++ b/simpletrace.h
@@ -10,6 +10,7 @@
#define SIMPLETRACE_H
#include
+#include
#include
typedef unsigned int TraceEventID;
@@ -20,11 +21,11 @@ typedef struct {
} TraceEvent;
void trace0(TraceEventID event);
-void trace1(TraceEventID event, unsigned long x1);
-void trace2(TraceEventID event, unsigned long x1, unsigned long x2);
-void trace3(TraceEventID event, unsigned long x1, unsigned long x2, unsigned
long x3);
-void trace4(TraceEventID event, unsigned long x1, unsigned long x2, unsigned
long x3, unsigned long x4);
-void trace5(TraceEventID event, unsigned long x1, unsigned long x2, unsigned
long x3, unsigned long x4, unsigned long x5);
+void trace1(TraceEventID event, uint64_t x1);
+void trace2(TraceEventID event, uint64_t x1, uint64_t x2);
+void trace3(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3);
+void trace4(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3,
uint64_t x4);
+void trace5(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3,
uint64_t x4, uint64_t x5);
void st_print_trace(FILE *stream, int (*stream_printf)(FILE *stream, const
char *fmt, ...));
void st_print_trace_events(FILE *stream, int (*stream_printf)(FILE *stream,
const char *fmt, ...));
void st_change_trace_event_state(const char *tname, bool tstate);
diff --git a/simpletrace.py b/simpletrace.py
index 979d911..fdf0eb5 100755
--- a/simpletrace.py
+++ b/simpletrace.py
@@ -17,7 +17,7 @@ header_event_id = 0x
header_magic= 0xf2b177cb0aa429b4
header_version = 0
-trace_fmt = 'LLL'
+trace_fmt = '=QQQ'
trace_len = struct.calcsize(trace_fmt)
event_re = re.compile(r'(disable\s+)?([a-zA-Z0-9_]+)\(([^)]*)\)\s+"([^"]*)"')
diff --git a/tracetool b/tracetool
index c5a5bdc..b78cd97 100755
--- a/tracetool
+++ b/tracetool
@@ -151,11 +151,11 @@ EOF
simple_event_num=0
}
-cast_args_to_ulong()
+cast_args_to_uint64_t()
{
local arg
for arg in $(get_argnames "$1"); do
-echo -n "(unsigned long)$arg"
+echo -n "(uint64_t)$arg"
done
}
@@ -173,7 +173,7 @@ linetoh_simple()
trace_args="$simple_event_num"
if [ "$argc" -gt 0 ]
then
-trace_args="$trace_args, $(cast_args_to_ulong "$1")"
+trace_args="$trace_args, $(cast_args_to_uint64_t "$1")"
fi
cat <
Re: [Qemu-devel] [STABLE 0.13][PULL 0/3] Block patches for stable-0.13
On 08/03/2010 09:46 AM, Kevin Wolf wrote: The following changes since commit 8f6e28789faeac4f01f8dbfdac147a3d3b635f24: savevm: Fix memory leak of compat struct (2010-07-30 23:02:03 +0200) Pulled, thanks. Regards, Anthony Liguori are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-stable-0.13 Andrea Arcangeli (1): ide: Avoid canceling IDE DMA Kevin Wolf (1): block: Fix bdrv_has_zero_init Markus Armbruster (1): block: Change bdrv_eject() not to drop the image block.c | 13 ++--- block/raw-posix.c | 13 + block/raw-win32.c |6 ++ block/raw.c |6 ++ block_int.h |8 ++-- hw/ide/pci.c | 23 +-- 6 files changed, 54 insertions(+), 15 deletions(-)
Re: [Qemu-devel] [PULL 0/6] Block patches
On 08/03/2010 09:44 AM, Kevin Wolf wrote: The following changes since commit 5933e8a96ab9c59cb6b6c80c9db385364a68c959: fix last cpu timer initialization (2010-08-02 18:49:13 +) Pulled, thanks. Regards, Anthony Liguori are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-anthony Andrea Arcangeli (1): ide: Avoid canceling IDE DMA Kevin Wolf (2): block: Change bdrv_commit to handle multiple sectors at once block: Fix bdrv_has_zero_init Markus Armbruster (1): block: Change bdrv_eject() not to drop the image Miguel Di Ciurcio Filho (1): loadvm: improve tests before bdrv_snapshot_goto() Yoshiaki Tamura (1): block migration: replace tabs by spaces. block-migration.c | 12 block.c | 50 ++-- block/raw-posix.c | 13 ++--- block/raw-win32.c |6 block/raw.c |6 block_int.h |8 - hw/ide/pci.c | 23 +++- monitor.c |3 +- savevm.c | 71 +--- 9 files changed, 115 insertions(+), 77 deletions(-)
[Qemu-devel] [PATCH] trace: Documentation update
Signed-off-by: Stefan Hajnoczi
---
docs/tracing.txt | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/docs/tracing.txt b/docs/tracing.txt
index abbae6b..fe3c6ac 100644
--- a/docs/tracing.txt
+++ b/docs/tracing.txt
@@ -18,7 +18,7 @@ for debugging, profiling, and observing execution.
3. Pretty-print the binary trace file:
-./simpletrace.py trace-events /tmp/trace.log
+./simpletrace.py trace-events /tmp/trace-*
== Trace events ==
@@ -70,11 +70,11 @@ trace events.
== Trace backends ==
-The tracetool script not only automates tedious trace event code generation,
-it also keeps the trace event declarations independent of the trace backend.
-The trace events are not tightly coupled to a specific trace backend, such as
-LTTng or SystemTap. Support for trace backends can be added by extending the
-tracetool script.
+The tracetool script automates tedious trace event code generation and also
+keeps the trace event declarations independent of the trace backend. The trace
+events are not tightly coupled to a specific trace backend, such as LTTng or
+SystemTap. Support for trace backends can be added by extending the tracetool
+script.
The trace backend is chosen at configure time and only one trace backend can
be built into the binary:
@@ -116,16 +116,19 @@ unless you have specific needs for more advanced backends.
* trace-event NAME on|off
Enable/disable a given trace event.
+* trace-file on|off|flush|set
+ Enable/disable/flush the trace file or set the trace file name.
+
Enabling/disabling trace events programmatically
-The change_trace_event_state() function can be used to enable or disable trace
+The st_change_trace_event_state() function can be used to enable or disable
trace
events at runtime inside QEMU:
#include "trace.h"
-change_trace_event_state("virtio_irq", true); /* enable */
+st_change_trace_event_state("virtio_irq", true); /* enable */
[...]
-change_trace_event_state("virtio_irq", false); /* disable */
+st_change_trace_event_state("virtio_irq", false); /* disable */
Analyzing trace files
--
1.7.1
[Qemu-devel] [PATCH] elf: Calculate symbol size if needed
Symbols with a size of 0 are unusable for the disassembler.
Example:
While running an arm linux kernel, no symbolic names are
used in qemu.log when the cpu is executing an assembler function.
Assume that the size of such symbols is the difference to the
next symbol value.
Signed-off-by: Stefan Weil
---
hw/elf_ops.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/hw/elf_ops.h b/hw/elf_ops.h
index 27d1ab9..0bd7235 100644
--- a/hw/elf_ops.h
+++ b/hw/elf_ops.h
@@ -153,6 +153,11 @@ static int glue(load_symbols, SZ)(struct elfhdr *ehdr, int
fd, int must_swab,
syms = qemu_realloc(syms, nsyms * sizeof(*syms));
qsort(syms, nsyms, sizeof(*syms), glue(symcmp, SZ));
+for (i = 0; i < nsyms - 1; i++) {
+if (syms[i].st_size == 0) {
+syms[i].st_size = syms[i + 1].st_value - syms[i].st_value;
+}
+}
} else {
qemu_free(syms);
syms = NULL;
--
1.7.1
[Qemu-devel] [PATCH] hw/arm: Improve detection of Linux kernels
ELF images were not detected as linux kernels. Assume that they are linux kernels if the kernel name contains 'vmlinux'. Cc: Paul Brook Signed-off-by: Stefan Weil --- hw/arm_boot.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/hw/arm_boot.c b/hw/arm_boot.c index 620550b..e73ef42 100644 --- a/hw/arm_boot.c +++ b/hw/arm_boot.c @@ -204,7 +204,7 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info) int kernel_size; int initrd_size; int n; -int is_linux = 0; +int is_linux; uint64_t elf_entry; target_phys_addr_t entry; int big_endian; @@ -225,7 +225,9 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info) big_endian = 0; #endif -/* Assume that raw images are linux kernels, and ELF images are not. */ +/* Assume that raw images are linux kernels, and ELF images + are not (unless the kernel filename contains 'vmlinux'). */ +is_linux = (strstr(info->kernel_filename, "vmlinux") != NULL); kernel_size = load_elf(info->kernel_filename, NULL, NULL, &elf_entry, NULL, NULL, big_endian, ELF_MACHINE, 1); entry = elf_entry; -- 1.7.1
[Qemu-devel] [PATCH] hw/musicpal: Set loader start address
Start address 0x0 did not work with a linux kernel.
Cc: Jan Kiszka
Signed-off-by: Stefan Weil
---
hw/musicpal.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/musicpal.c b/hw/musicpal.c
index 33180a2..dc6bc21 100644
--- a/hw/musicpal.c
+++ b/hw/musicpal.c
@@ -1470,7 +1470,7 @@ static SysBusDeviceInfo musicpal_key_info = {
};
static struct arm_boot_info musicpal_binfo = {
-.loader_start = 0x0,
+.loader_start = MP_SRAM_BASE,
.board_id = 0x20e,
};
--
1.7.1
Re: [Qemu-devel] Virtual memory question
On 08/09/2010 03:17 AM, Stefan Hajnoczi wrote: Use -mem-path /path/to/directory. It's used for hugetlbfs support on Linux but it should work on a normal filesystem too. Stefan It *almost* works, except for some minor obstacles: 1) Normally the pages get mmap()'d with MAP_PRIVATE so they COW'd rather than written to the backing file: #ifdef MAP_POPULATE /* NB: MAP_POPULATE won't exhaustively alloc all phys pages in the case * MAP_PRIVATE is requested. For mem_prealloc we mmap as MAP_SHARED * to sidestep this quirk. */ flags = mem_prealloc ? MAP_POPULATE | MAP_SHARED : MAP_PRIVATE; area = mmap(0, memory, PROT_READ | PROT_WRITE, flags, fd, 0); #else area = mmap(0, memory, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0); #endif You can force a MAP_SHARED mapping without any changes to qemu by using the -mem_prealloc option, but you'll get MAP_POPULATE as well, which may not be desirable. A small patch would do the job though. 2) exec.c:file_ram_alloc() assumes you're allocating off a hugetlbfs and makes some system calls to get the block/hugepage size. A quick hack might be to comment out the following in exec.c:gethugepagesize(): if (fs.f_type != HUGETLBFS_MAGIC) fprintf(stderr, "Warning: path not on HugeTLBFS: %s\n", path); You may also want to replace the mkstemp() with a mkostemp() and set O_SYNC on the file But beyond hacks, I think generalizing -mempath might have some other useful applications (using it as a way to expose tmpfs-backed/numactl'd files as numa nodes to guests came up in an earlier discussion, and memory compression via zram/compcache is another).
Re: [Qemu-devel] [PATCH 00/12 v4] Clean up linux-user/elfload.c
Am Dienstag, 27. Juli 2010, 19:25:26 schrieb Richard Henderson: > A re-based and re-tested version of a patch series I > posted back in April and May. These cleanups prepare > elfload.c for loading the VDSO for x86_64. > > Do you have a repo where i could pull these from ? Best, Jan-Simon
[Qemu-devel] [PATCH 0/2] QMP: update 'query-version'
This series changes how QMP exports the version of QEMU to clients.
Current behavior:
{"QMP": {"version": {"qemu": "0.13.50", "package": ""}, "capabilities": []}}
New behavior:
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 13, "major": 0}, "package":
""}, "capabilities": []}}
Clients will no longer need to parse the entire string.
Regards,
Miguel
---
Miguel Di Ciurcio Filho (2):
QMP: update 'query-version' documentation
QMP/monitor: update do_info_version() to output broken down version
string
monitor.c | 23 +++
qemu-monitor.hx | 16 ++--
2 files changed, 33 insertions(+), 6 deletions(-)
[Qemu-devel] [PATCH 1/2] QMP: update 'query-version' documentation
Update the documentation of 'query-version' to output the string version broken
down.
Signed-off-by: Miguel Di Ciurcio Filho
---
qemu-monitor.hx | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 2af3de6..9c27b31 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -1623,13 +1623,25 @@ Show QEMU version.
Return a json-object with the following information:
-- "qemu": QEMU's version (json-string)
+- "qemu": A json-object containing three integer values:
+- "major": QEMU's major version (json-int)
+- "minor": QEMU's minor version (json-int)
+- "micro": QEMU's micro version (json-int)
- "package": package's version (json-string)
Example:
-> { "execute": "query-version" }
-<- { "return": { "qemu": "0.11.50", "package": "" } }
+<- {
+ "return":{
+ "qemu":{
+"major":0,
+"minor":11,
+"micro":5
+ },
+ "package":""
+ }
+ }
EQMP
--
1.7.1
[Qemu-devel] [PATCH 2/2] QMP/monitor: update do_info_version() to output broken down version string
This code was originally developed by Daniel P. Berrange
Signed-off-by: Miguel Di Ciurcio Filho
---
monitor.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
index c313d5a..e82c48f 100644
--- a/monitor.c
+++ b/monitor.c
@@ -669,17 +669,32 @@ help:
static void do_info_version_print(Monitor *mon, const QObject *data)
{
QDict *qdict;
+QDict *qemu;
qdict = qobject_to_qdict(data);
+qemu = qdict_get_qdict(qdict, "qemu");
-monitor_printf(mon, "%s%s\n", qdict_get_str(qdict, "qemu"),
- qdict_get_str(qdict, "package"));
+monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
+ qdict_get_int(qemu, "major"),
+ qdict_get_int(qemu, "minor"),
+ qdict_get_int(qemu, "micro"),
+ qdict_get_str(qdict, "package"));
}
static void do_info_version(Monitor *mon, QObject **ret_data)
{
-*ret_data = qobject_from_jsonf("{ 'qemu': %s, 'package': %s }",
- QEMU_VERSION, QEMU_PKGVERSION);
+const char *version = QEMU_VERSION;
+int major = 0, minor = 0, micro = 0;
+char *tmp;
+
+major = strtol(version, &tmp, 10);
+tmp++;
+minor = strtol(tmp, &tmp, 10);
+tmp++;
+micro = strtol(tmp, &tmp, 10);
+
+*ret_data = qobject_from_jsonf("{ 'qemu': { 'major': %d, 'minor': %d, \
+'micro': %d }, 'package': %s }", major, minor, micro, QEMU_PKGVERSION);
}
static void do_info_name_print(Monitor *mon, const QObject *data)
--
1.7.1
Re: [Qemu-devel] [Bug 614958] [NEW] copy-paste between client and host
--- On Sun, 8/8/10, Steve White wrote: > From: Steve White > Subject: [Qemu-devel] [Bug 614958] [NEW] copy-paste between client and host > To: qemu-devel@nongnu.org > Date: Sunday, August 8, 2010, 3:19 AM > I can tell you, the absence of a copy/paste mechanism makes > the project > an immediate no-go for many users. I work with a guy > who spent a lot of > time trying, gave up, and switched to VirtualBox for this > exact reason. +1e9. _Exactly_, _absolutely_. Been there, done that, and even though I write code professionally, I prefer VirtualBox just because many things in it simply work. Regards, Sergei.
[Qemu-devel] Re: patchwork
On Mon, Aug 9, 2010 at 6:29 AM, Anthony Liguori wrote: > > Sorry, I've got it now. In the future, please resend patches with [RESEND] > as opposed to just bumping it. Isn't anybody using http://patchwork.ozlabs.org/project/qemu-devel/list/ ? Tbat was designed specifically to help manage patch submissions. -Hollis
Re: [Qemu-devel] [PATCH 2/2] QMP/monitor: update do_info_version() to output broken down version string
On Mon, 9 Aug 2010, Miguel Di Ciurcio Filho wrote:
> This code was originally developed by Daniel P. Berrange
>
> Signed-off-by: Miguel Di Ciurcio Filho
> ---
> monitor.c | 23 +++
> 1 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/monitor.c b/monitor.c
> index c313d5a..e82c48f 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -669,17 +669,32 @@ help:
> static void do_info_version_print(Monitor *mon, const QObject *data)
> {
> QDict *qdict;
> +QDict *qemu;
>
> qdict = qobject_to_qdict(data);
> +qemu = qdict_get_qdict(qdict, "qemu");
>
> -monitor_printf(mon, "%s%s\n", qdict_get_str(qdict, "qemu"),
> - qdict_get_str(qdict, "package"));
> +monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
> +qdict_get_int(qemu, "major"),
> +qdict_get_int(qemu, "minor"),
> +qdict_get_int(qemu, "micro"),
> +qdict_get_str(qdict, "package"));
> }
Above snippet uses tab(s).
> static void do_info_version(Monitor *mon, QObject **ret_data)
> {
> -*ret_data = qobject_from_jsonf("{ 'qemu': %s, 'package': %s }",
> - QEMU_VERSION, QEMU_PKGVERSION);
> +const char *version = QEMU_VERSION;
> +int major = 0, minor = 0, micro = 0;
> +char *tmp;
> +
> +major = strtol(version, &tmp, 10);
> +tmp++;
> +minor = strtol(tmp, &tmp, 10);
> +tmp++;
> +micro = strtol(tmp, &tmp, 10);
> +
> +*ret_data = qobject_from_jsonf("{ 'qemu': { 'major': %d, 'minor': %d, \
> +'micro': %d }, 'package': %s }", major, minor, micro,
> QEMU_PKGVERSION);
> }
>
> static void do_info_name_print(Monitor *mon, const QObject *data)
>
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] Virtual memory question
On Mon, Aug 9, 2010 at 2:03 AM, Dennis wrote: >> >> Hi, >> >> I've been looking at the qemu source code but couldn't find anything >> that would suit my needs. >> Basically I'm looking for a way to use a file on disk as physical >> memory inside Qemu. >> >> Before I attempt to reinvent the wheel, has someone ever hacked in >> similar functionality and if so is there a diff patch available >> anywhere? On Mon, Aug 9, 2010 at 7:01 AM, C K Kashyap wrote: > I am curious to know why you'd want to do it? I have an application that takes up over 2 GB of memory but is otherwise demanding virtually no other resources at all. Running multiple instances of the application using physical memory isn't an option. Would it be hard to change Qemu's physical memory mapping to a file on disk ? (Not Qemu-KVM, just stock Qemu).
Re: [Qemu-devel] Virtual memory question
On 08/09/2010 11:46 AM, Michael Roth wrote: 2) exec.c:file_ram_alloc() assumes you're allocating off a hugetlbfs and makes some system calls to get the block/hugepage size. A quick hack might be to comment out the following in exec.c:gethugepagesize(): if (fs.f_type != HUGETLBFS_MAGIC) fprintf(stderr, "Warning: path not on HugeTLBFS: %s\n", path); You may also want to replace the mkstemp() with a mkostemp() and set O_SYNC on the file But beyond hacks, I think generalizing -mempath might have some other useful applications (using it as a way to expose tmpfs-backed/numactl'd files as numa nodes to guests came up in an earlier discussion, and memory compression via zram/compcache is another). Actually I guess 2) isn't really an issue, thought was an error path but I was mistaken. -Mike
[Qemu-devel] [Bug 614958] Re: copy-paste between client and host
SPICE is supposed to address this kind of issue. Hopefully it will be merged in 0.14. Anyway, after SPICE support is merged this feature would belong in SPICE, not in QEMU. See http://spice- space.org/page/Features/SharedClipboard for more information. We might keep this open until SPICE is merged, but I'm not sure this bug really belongs in QEMU's bug tracker. -- copy-paste between client and host https://bugs.launchpad.net/bugs/614958 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Hi, I propose that copy/paste between VMs be implemented somehow directly in QEMU. This has been discussed repeatedly elsewhere; various solutions are proposed. See below. As it is, each user has to do their own research and testing if they are to find a solution. This makes the product frustratingly unattractive for many. Most solutions involve either running vnc and using a vnc client that supports copy/paste (this can be tricky to find itself), or running some other tcp-based copy-paste application. For many users, the networking in a client VM is unimportant--they just want to run some application there, and setting up netoworking in a VM itself can be an issue. Most of these solutions rely on un-maintained software, and some require that other software be installed to make them work (Basic interpreter, Java, etc). Any of these solutions take some work to set up. I can tell you, the absence of a copy/paste mechanism makes the project an immediate no-go for many users. I work with a guy who spent a lot of time trying, gave up, and switched to VirtualBox for this exact reason. It would be much better if copy/paste worked out of the box. Ideally, it should work independently of networking. Cheers! Some discussions and proposed solutions: - http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=161 Somebody suggests VNC into the virtual host, and use vncviewer Somebody else suggests TCP/IP Clipboard (text editor with tcp/ip) http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=2626 primitive app for sharing text across machines (in Basic) http://homepage.mac.com/bnej/shareclip/ http://borderworlds.dk/blog/20070217-00.html Says doesn't know a good solution but points to unmaintained package Qemu Guest Tools http://wolfpackally.wo.funpic.de/qemu/qgt/ http://bonzoli.com/docs/How_to_setup_Qemu_on_Fedora_8.html proposes Java remoteclip running on client and server http://www.cs.cmu.edu/afs/cs/user/rcm/WWW/RemoteClip/
Re: [Qemu-devel] Virtual memory question
On Mon, Aug 9, 2010 at 7:49 PM, Dennis wrote: > I have an application that takes up over 2 GB of memory but is > otherwise demanding virtually no other resources at all. > Running multiple instances of the application using physical memory > isn't an option. Would it be hard to change Qemu's > physical memory mapping to a file on disk ? (Not Qemu-KVM, just stock Qemu). It's not 100% clear what you are trying to do, but are you aware that guest "physical" memory can be swapped on the host? If you put two VMs on one host which use more memory than available host RAM, some of their pages will get pushed out to swap, like any normal userspace process. Two things to consider in a memory overcommit scenario are reduced performance due to swapping and allocating enough swap so the out-of-memory killer does not terminate the QEMU process. Also, have you looked at Kernel Samepage Merging (KSM)? KSM detects guest physical pages that contain the same contents and merge them into a single page, saving memory. This is appropriate if you run multiple VMs based off the same disk image and expect they will be executing the same code. For more info, see http://kernelnewbies.org/Linux_2_6_32#head-d3f32e41df508090810388a57efce73f52660ccb. Stefan
Re: [Qemu-devel] Virtual memory question
On Mon, Aug 9, 2010 at 9:41 PM, Stefan Hajnoczi wrote: > On Mon, Aug 9, 2010 at 7:49 PM, Dennis wrote: >> I have an application that takes up over 2 GB of memory but is >> otherwise demanding virtually no other resources at all. >> Running multiple instances of the application using physical memory >> isn't an option. Would it be hard to change Qemu's >> physical memory mapping to a file on disk ? (Not Qemu-KVM, just stock Qemu). > > It's not 100% clear what you are trying to do, but are you aware that > guest "physical" memory can be swapped on the host? I know, but the host machine would have to run out of memory before it swaps. That's not very desirable ;-) > Also, have you looked at Kernel Samepage Merging (KSM)? KSM detects > guest physical pages that contain the same contents and merge them > into a single page, saving memory. This is appropriate if you run > multiple VMs based off the same disk image and expect they will be > executing the same code. For more info, see > http://kernelnewbies.org/Linux_2_6_32#head-d3f32e41df508090810388a57efce73f52660ccb. I havn't yet. One "problem" is I _have_ to run Qemu on FreeBSD. I doubt it's possible.
[Qemu-devel] Re: Question about starting 2 VMs using Qemu
Try removing ifname=tap0 and a different macaddr for second instance. --Nirmal On Fri, Aug 6, 2010 at 7:09 AM, Anjali Kulkarni wrote: > Hi, > > I can start my freebsd based image in Qemu, and I use tap interface for > connectivity to the host or external world, but when I try to fire up 2 > instances, using tap, it fails. For the second invocation, it gives me the > error: > > [r...@ipg-virt01 tmp]# ./qemu-system-x86_64 -m 512 anjali.img -net > nic,model=yukon,macaddr=52:54:00:00:aa:02 -net tap,ifname=tap0,script=no > warning: could not configure /dev/net/tun: no virtual network emulation > Could not initialize device 'tap' > > Am I doing something wrong? The first instance is running fine. > > Anjali > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[Qemu-devel] Fwd: [Lxde-list] LXAppearance 2 replaces the original LXAppearance in master branch.
-- Forwarded message -- From: PCMan Date: 2010/8/7 Subject: [Lxde-list] LXAppearance 2 replaces the original LXAppearance in master branch. To: lxde-list , "The mailing list for translators of LXDE and its components." Hi list, The rewrite of LXAppearance is finished and there are quite many nice new features. Today I move lxappearance2 back into the original repository of lxappearance. The original lxappearance is moved to "legacy" branch, and the new code replaces the "master" branch. I also made some modifications to reflect this change in transifex.net. So now the original lxappearance is moved to lxappearance-legacy. >From now on the new one should be translated instead. I have asked a friend who is a native English speaker to review to English strings and they look ok. So now translators can start doing the translation for the new lxappearance. Cheers! -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Lxde-list mailing list lxde-l...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list
[Qemu-devel] [Bug 595438] Re: KVM segmentation fault, using SCSI+writeback and linux 2.4 guest
** Description changed: I Use Ubuntu 32 bit 10.04 with standard KVM. I have Intel E7600 @ 3.06GHz processor with VMX In this system I Run: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -M pc-0.12 -enable-kvm -m 256 -smp 1 -name spamsender -uuid b9cacd5e-08f7-41fd-78c8-89cec59af881 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/spamsender.monitor,server,nowait -monitor chardev:monitor -boot d -drive file=/mnt/megadiff/cdiso_400_130.iso,if=ide,media=cdrom,index=2 -drive file=/home/mmarkk/spamsender2.img,if=scsi,index=0,format=qcow2,cache=writeback -net nic,macaddr=00:00:00:00:00:00,vlan=0,name=nic.0 -net tap,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -vnc 127.0.0.1:0 -vga cirrus .iso image contain custom distro of 2.4-linux kernel based system. During install process (when .tar.gz actively unpacked), kvm dead with segmentation fault. - And ONLY when I choose scsi virtual disk and writeback simultaneously. + And ONLY when I choose scsi virtual disk and writeback simultaneously. But, writeback+ide, writethrough+scsi works OK. I use qcow2. It seems, that qcow does not have such problems. Virtual machine get down at random time during file copy. It seems, when qcow2 file size need to be expanded. + + IMPACT: kvm used with scsi virtual disk and writeback dies with + segfault. + + FIX: is the inclusion of a patch cherry-picked from upstream which dequeues + requests before invoking callbacks. It is at + http://bazaar.launchpad.net/~serge-hallyn/ubuntu/lucid/qemu-kvm/fix-scsi-writeback/revision/70 + + TO REPRODUCE: See the command above. + + REGRESSION POTENTIAL: this is cherry-picked from upstream, and has been + tested by the bug reporter with no ill effects. ** Changed in: qemu Status: Fix Committed => Fix Released ** Changed in: qemu Status: Fix Released => Fix Committed ** Changed in: qemu-kvm Status: Confirmed => Fix Released -- KVM segmentation fault, using SCSI+writeback and linux 2.4 guest https://bugs.launchpad.net/bugs/595438 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in Kernel Virtual Machine: Confirmed Status in QEMU: Fix Committed Status in qemu-kvm: Fix Released Bug description: I Use Ubuntu 32 bit 10.04 with standard KVM. I have Intel E7600 @ 3.06GHz processor with VMX In this system I Run: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -M pc-0.12 -enable-kvm -m 256 -smp 1 -name spamsender -uuid b9cacd5e-08f7-41fd-78c8-89cec59af881 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/spamsender.monitor,server,nowait -monitor chardev:monitor -boot d -drive file=/mnt/megadiff/cdiso_400_130.iso,if=ide,media=cdrom,index=2 -drive file=/home/mmarkk/spamsender2.img,if=scsi,index=0,format=qcow2,cache=writeback -net nic,macaddr=00:00:00:00:00:00,vlan=0,name=nic.0 -net tap,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -vnc 127.0.0.1:0 -vga cirrus .iso image contain custom distro of 2.4-linux kernel based system. During install process (when .tar.gz actively unpacked), kvm dead with segmentation fault. And ONLY when I choose scsi virtual disk and writeback simultaneously. But, writeback+ide, writethrough+scsi works OK. I use qcow2. It seems, that qcow does not have such problems. Virtual machine get down at random time during file copy. It seems, when qcow2 file size need to be expanded. IMPACT: kvm used with scsi virtual disk and writeback dies with segfault. FIX: is the inclusion of a patch cherry-picked from upstream which dequeues requests before invoking callbacks. It is at http://bazaar.launchpad.net/~serge-hallyn/ubuntu/lucid/qemu-kvm/fix-scsi-writeback/revision/70 TO REPRODUCE: See the command above. REGRESSION POTENTIAL: this is cherry-picked from upstream, and has been tested by the bug reporter with no ill effects.
[Qemu-devel] [Bug 595438] Re: KVM segmentation fault, using SCSI+writeback and linux 2.4 guest
** Also affects: qemu-kvm (Ubuntu) Importance: Undecided Status: New ** Changed in: qemu-kvm (Ubuntu) Status: New => Fix Released ** Changed in: qemu-kvm (Ubuntu) Importance: Undecided => Medium -- KVM segmentation fault, using SCSI+writeback and linux 2.4 guest https://bugs.launchpad.net/bugs/595438 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in Kernel Virtual Machine: Confirmed Status in QEMU: Fix Committed Status in qemu-kvm: Fix Released Status in “qemu-kvm” package in Ubuntu: Fix Released Bug description: I Use Ubuntu 32 bit 10.04 with standard KVM. I have Intel E7600 @ 3.06GHz processor with VMX In this system I Run: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -M pc-0.12 -enable-kvm -m 256 -smp 1 -name spamsender -uuid b9cacd5e-08f7-41fd-78c8-89cec59af881 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/spamsender.monitor,server,nowait -monitor chardev:monitor -boot d -drive file=/mnt/megadiff/cdiso_400_130.iso,if=ide,media=cdrom,index=2 -drive file=/home/mmarkk/spamsender2.img,if=scsi,index=0,format=qcow2,cache=writeback -net nic,macaddr=00:00:00:00:00:00,vlan=0,name=nic.0 -net tap,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -vnc 127.0.0.1:0 -vga cirrus .iso image contain custom distro of 2.4-linux kernel based system. During install process (when .tar.gz actively unpacked), kvm dead with segmentation fault. And ONLY when I choose scsi virtual disk and writeback simultaneously. But, writeback+ide, writethrough+scsi works OK. I use qcow2. It seems, that qcow does not have such problems. Virtual machine get down at random time during file copy. It seems, when qcow2 file size need to be expanded. IMPACT: kvm used with scsi virtual disk and writeback dies with segfault. FIX: is the inclusion of a patch cherry-picked from upstream which dequeues requests before invoking callbacks. It is at http://bazaar.launchpad.net/~serge-hallyn/ubuntu/lucid/qemu-kvm/fix-scsi-writeback/revision/70 TO REPRODUCE: See the command above. REGRESSION POTENTIAL: this is cherry-picked from upstream, and has been tested by the bug reporter with no ill effects.
[Qemu-devel] [Bug 595438] Re: KVM segmentation fault, using SCSI+writeback and linux 2.4 guest
** Also affects: qemu-kvm (Ubuntu Lucid) Importance: Undecided Status: New ** Changed in: qemu-kvm (Ubuntu Lucid) Status: New => In Progress ** Changed in: qemu-kvm (Ubuntu Lucid) Importance: Undecided => Medium -- KVM segmentation fault, using SCSI+writeback and linux 2.4 guest https://bugs.launchpad.net/bugs/595438 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in Kernel Virtual Machine: Confirmed Status in QEMU: Fix Committed Status in qemu-kvm: Fix Released Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “qemu-kvm” source package in Lucid: In Progress Bug description: I Use Ubuntu 32 bit 10.04 with standard KVM. I have Intel E7600 @ 3.06GHz processor with VMX In this system I Run: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -M pc-0.12 -enable-kvm -m 256 -smp 1 -name spamsender -uuid b9cacd5e-08f7-41fd-78c8-89cec59af881 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/spamsender.monitor,server,nowait -monitor chardev:monitor -boot d -drive file=/mnt/megadiff/cdiso_400_130.iso,if=ide,media=cdrom,index=2 -drive file=/home/mmarkk/spamsender2.img,if=scsi,index=0,format=qcow2,cache=writeback -net nic,macaddr=00:00:00:00:00:00,vlan=0,name=nic.0 -net tap,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -vnc 127.0.0.1:0 -vga cirrus .iso image contain custom distro of 2.4-linux kernel based system. During install process (when .tar.gz actively unpacked), kvm dead with segmentation fault. And ONLY when I choose scsi virtual disk and writeback simultaneously. But, writeback+ide, writethrough+scsi works OK. I use qcow2. It seems, that qcow does not have such problems. Virtual machine get down at random time during file copy. It seems, when qcow2 file size need to be expanded. IMPACT: kvm used with scsi virtual disk and writeback dies with segfault. FIX: is the inclusion of a patch cherry-picked from upstream which dequeues requests before invoking callbacks. It is at http://bazaar.launchpad.net/~serge-hallyn/ubuntu/lucid/qemu-kvm/fix-scsi-writeback/revision/70 TO REPRODUCE: See the command above. REGRESSION POTENTIAL: this is cherry-picked from upstream, and has been tested by the bug reporter with no ill effects.
[Qemu-devel] about qemu
can any one suggest any study materials for start learning qemu and its internals i have already read the documentation in this qemu web page other than that any other materials,thanks
Re: [Qemu-devel] [RFC PATCH 10/14] KVM-test: Add a subtest of pxe
On Wed, Jul 28, 2010 at 07:07:34PM -0300, Lucas Meneghel Rodrigues wrote:
> On Tue, 2010-07-20 at 09:36 +0800, Amos Kong wrote:
> > This case just snoop tftp packet through tcpdump, it depends on public dhcp
> > server, better to test it through dnsmasq.
>
> It would be a good idea to have an alternate implementation using
> dnsmasq, but not urgent.
I changed unattended_install to use dnsmasq, but it was blocked by a pxe bug.
Also need completed test, we can add this later.
> > Signed-off-by: Jason Wang
> > Signed-off-by: Amos Kong
> > ---
> > 0 files changed, 0 insertions(+), 0 deletions(-)
> >
> > diff --git a/client/tests/kvm/tests/pxe.py b/client/tests/kvm/tests/pxe.py
> > new file mode 100644
> > index 000..8859aaa
> > --- /dev/null
> > +++ b/client/tests/kvm/tests/pxe.py
> > @@ -0,0 +1,30 @@
> > +import logging
> > +from autotest_lib.client.common_lib import error
> > +import kvm_subprocess, kvm_test_utils, kvm_utils
> > +
> > +
> > +def run_pxe(test, params, env):
> > +"""
> > +PXE test:
> > +
> > +1) Snoop the tftp packet in the tap device
> > +2) Wait for some seconds
> > +3) Check whether capture tftp packets
> > +
> > +@param test: kvm test object
> > +@param params: Dictionary with the test parameters
> > +@param env: Dictionary with test environment.
> > +"""
> > +vm = kvm_test_utils.get_living_vm(env, params.get("main_vm"))
> > +timeout = int(params.get("pxe_timeout", 60))
> > +
> > +logging.info("Try to boot from pxe")
> > +status, output = kvm_subprocess.run_fg("tcpdump -nli %s" %
> > vm.get_ifname(),
> > + logging.debug,
> > + "(pxe) ",
> > + timeout)
>
> ^ The only complaint I could make here is that since this command
> doesn't need to live throughout tests, utils.run would do just fine.
> Other than that, looks fine to me.
utils.run() desen't support timeout, tcpdump would not stop by itself.
also could not add output prefix "(pxe) " ?
> > +logging.info("Analysing the tcpdump result...")
>
> ^ typo, analyzing
>
> > +if not "tftp" in output:
> > +raise error.TestFail("Couldn't find tftp packet in %s seconds" %
> > timeout)
> > +logging.info("Found tftp packet")
> > diff --git a/client/tests/kvm/tests_base.cfg.sample
> > b/client/tests/kvm/tests_base.cfg.sample
> > index 9594a38..5515601 100644
> > --- a/client/tests/kvm/tests_base.cfg.sample
> > +++ b/client/tests/kvm/tests_base.cfg.sample
> > @@ -381,6 +381,19 @@ variants:
> > mgroup_count = 20
> > flood_minutes = 1
> >
> > +- pxe:
> > +type = pxe
> > +images = pxe
> > +image_name_pxe = pxe-test
> > +image_size_pxe = 1G
> > +force_create_image_pxe = yes
> > +remove_image_pxe = yes
> > +extra_params += ' -boot n'
> > +kill_vm_on_error = yes
> > +network = bridge
> > +restart_vm = yes
> > +pxe_timeout = 60
> > +
> > - physical_resources_check: install setup unattended_install.cdrom
> > type = physical_resources_check
> > catch_uuid_cmd = dmidecode | awk -F: '/UUID/ {print $2}'
> >
> >
>
>
