Re: [Qemu-devel] [PATCH 2/2] ac97: don't override the pci subsystem id
On 11/07/11 17:00, Anthony Liguori wrote: On 11/07/2011 09:33 AM, Gerd Hoffmann wrote: This patch removes the code lines which set the subsystem id for the emulated ac97 card to 8086:. Due to the device id being zero the subsystem id isn't vaild anyway. With the patch applied the sound card gets the default qemu subsystem id (1af4:1100) instead. I don't like having a property of use broken. Well, it *is* broken. Suggestions for a better name? Wouldn't it be better to have the subsystem vendor and device id be configurable, set the default to the qemu subsystem ids, and then set it to 8086: for 1.0? I don't want this being fully configurable just for the snake of backward compatibility with old qemu versions. cheers, Gerd
Re: [Qemu-devel] [PATCH] qmp: add test tool for QMP
When I run this tool, I got two python exceptions. It turned out that
both of them were caused by wrong usage. Do you think we need add
validation for input to handle these cases?
Thanks.
1. Not using '=' for path:
$ ./QMP/qmp --path monitor-address
Traceback (most recent call last):
File ./QMP/qmp, line 120, in module
sys.exit(main(sys.argv[1:]))
File ./QMP/qmp, line 71, in main
srv.connect()
File /home/mark/work/source/qemu/QMP/qmp.py, line 85, in connect
self.__sock.connect(self.__address)
File string, line 1, in connect
TypeError: argument must be string or read-only character buffer, not bool
Proposed patch:
@@ -48,7 +48,8 @@ def main(args):
arg, value = arg.split('=', 1)
if arg in ['path']:
-path = value
+ if isinstance(value, basestring):
+path = value
2. No qmp comand given in command line
$ ./QMP/qmp --path=monitor-address
Traceback (most recent call last):
File ./QMP/qmp, line 120, in module
sys.exit(main(sys.argv[1:]))
File ./QMP/qmp, line 65, in main
command, args = args[0], args[1:]
IndexError: list index out of range
@@ -62,11 +63,17 @@ def main(args):
print QMP path isn't set, use --path or set QMP_PATH
return 1
Proposed patch:
-command, args = args[0], args[1:]
+if len(args):
+ command, args = args[0], args[1:]
+else:
+ print 'No command found'
+ print 'Usage: qmp [--path=monitor-address] qmp-cmd arguments'
+ return 1
On 11/07/2011 11:11 PM, Anthony Liguori wrote:
I wrote this quickly to aid in testing. It's similar to qmp-shell with a few
important differences:
1) It is not interactive. That makes it useful for scripting.
2) qmp-shell:
(QEMU) set_password protocol=vnc password=foo
3) qmp:
$ qmp set_password --protocol=vnc --password=foo
4) Extensible, git-style interface. If an invalid command name is passed, it
will try to exec qmp-$1.
5) It attempts to pretty print the JSON responses in a shell friendly format
such that tools can work with the output.
Hope others will also find it useful.
Signed-off-by: Anthony Liguorialigu...@us.ibm.com
---
QMP/qmp | 120 +++
1 files changed, 120 insertions(+), 0 deletions(-)
create mode 100755 QMP/qmp
diff --git a/QMP/qmp b/QMP/qmp
new file mode 100755
index 000..7b2a3c7
--- /dev/null
+++ b/QMP/qmp
@@ -0,0 +1,120 @@
+#!/usr/bin/python
+#
+# QMP command line tool
+#
+# Copyright IBM, Corp. 2011
+#
+# Authors:
+# Anthony Liguorialigu...@us.ibm.com
+#
+# This work is licensed under the terms of the GNU GPLv2 or later.
+# See the COPYING file in the top-level directory.
+
+import sys, os
+from qmp import QEMUMonitorProtocol
+
+def print_response(rsp, prefix=[]):
+if type(rsp) == list:
+i = 0
+for item in rsp:
+if prefix == []:
+prefix = ['item']
+print_response(item, prefix[:-1] + ['%s[%d]' % (prefix[-1], i)])
+i += 1
+elif type(rsp) == dict:
+for key in rsp.keys():
+print_response(rsp[key], prefix + [key])
+else:
+if len(prefix):
+print '%s: %s' % ('.'.join(prefix), rsp)
+else:
+print '%s' % (rsp)
+
+def main(args):
+path = None
+
+# Use QMP_PATH if it's set
+if os.environ.has_key('QMP_PATH'):
+path = os.environ['QMP_PATH']
+
+while len(args):
+arg = args[0]
+
+if arg.startswith('--'):
+arg = arg[2:]
+if arg.find('=') == -1:
+value = True
+else:
+arg, value = arg.split('=', 1)
+
+if arg in ['path']:
+path = value
+elif arg in ['help']:
+os.execlp('man', 'man', 'qmp')
+else:
+print 'Unknown argument %s' % arg
+
+args = args[1:]
+else:
+break
+
+if not path:
+print QMP path isn't set, use --path or set QMP_PATH
+return 1
+
+command, args = args[0], args[1:]
+
+if command in ['help']:
+os.execlp('man', 'man', 'qmp')
+
+srv = QEMUMonitorProtocol(path)
+srv.connect()
+
+def do_command(srv, cmd, **kwds):
+rsp = srv.cmd(cmd, kwds)
+if rsp.has_key('error'):
+raise Exception(rsp['error']['desc'])
+return rsp['return']
+
+commands = map(lambda x: x['name'], do_command(srv, 'query-commands'))
+
+srv.close()
+
+if command not in commands:
+fullcmd = 'qmp-%s' % command
+try:
+os.environ['QMP_PATH'] = path
+os.execvp(fullcmd, [fullcmd] + args)
+except OSError, (errno, msg):
+if errno == 2:
+print 'Command %s not found.' % (fullcmd)
+return 1
+raise
+return 0
+
+srv = QEMUMonitorProtocol(path)
+srv.connect()
+
+arguments
Re: [Qemu-devel] [PATCH v12 3/5] block: add I/O throttling algorithm
Am 08.11.2011 05:34, schrieb Zhi Yong Wu:
On Mon, Nov 7, 2011 at 11:18 PM, Kevin Wolf kw...@redhat.com wrote:
Am 03.11.2011 09:57, schrieb Zhi Yong Wu:
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block.c | 220
+++
block.h |1 +
block_int.h |1 +
3 files changed, 222 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 79e7f09..b2af48f 100644
--- a/block.c
+++ b/block.c
@@ -74,6 +74,13 @@ static BlockDriverAIOCB
*bdrv_co_aio_rw_vector(BlockDriverState *bs,
bool is_write);
static void coroutine_fn bdrv_co_do_rw(void *opaque);
+static bool bdrv_exceed_bps_limits(BlockDriverState *bs, int nb_sectors,
+bool is_write, double elapsed_time, uint64_t *wait);
+static bool bdrv_exceed_iops_limits(BlockDriverState *bs, bool is_write,
+double elapsed_time, uint64_t *wait);
+static bool bdrv_exceed_io_limits(BlockDriverState *bs, int nb_sectors,
+bool is_write, int64_t *wait);
+
static QTAILQ_HEAD(, BlockDriverState) bdrv_states =
QTAILQ_HEAD_INITIALIZER(bdrv_states);
@@ -107,6 +114,24 @@ int is_windows_drive(const char *filename)
#endif
/* throttling disk I/O limits */
+void bdrv_io_limits_disable(BlockDriverState *bs)
+{
+bs-io_limits_enabled = false;
+
+while (qemu_co_queue_next(bs-throttled_reqs));
+
+if (bs-block_timer) {
+qemu_del_timer(bs-block_timer);
+qemu_free_timer(bs-block_timer);
+bs-block_timer = NULL;
+}
+
+bs-slice_start = 0;
+bs-slice_end = 0;
+bs-slice_time = 0;
+memset(bs-io_base, 0, sizeof(bs-io_base));
+}
+
static void bdrv_block_timer(void *opaque)
{
BlockDriverState *bs = opaque;
@@ -136,6 +161,31 @@ bool bdrv_io_limits_enabled(BlockDriverState *bs)
|| io_limits-iops[BLOCK_IO_LIMIT_TOTAL];
}
+static void bdrv_io_limits_intercept(BlockDriverState *bs,
+ bool is_write, int nb_sectors)
+{
+int64_t wait_time = -1;
+
+if (!qemu_co_queue_empty(bs-throttled_reqs)) {
+qemu_co_queue_wait(bs-throttled_reqs);
+}
+
+/* In fact, we hope to keep each request's timing, in FIFO mode. The
next
+ * throttled requests will not be dequeued until the current request is
+ * allowed to be serviced. So if the current request still exceeds the
+ * limits, it will be inserted to the head. All requests followed it
will
+ * be still in throttled_reqs queue.
+ */
+
+while (bdrv_exceed_io_limits(bs, nb_sectors, is_write, wait_time)) {
+qemu_mod_timer(bs-block_timer,
+ wait_time + qemu_get_clock_ns(vm_clock));
+qemu_co_queue_wait_insert_head(bs-throttled_reqs);
+}
+
+qemu_co_queue_next(bs-throttled_reqs);
+}
+
/* check if the path starts with protocol: */
static int path_has_protocol(const char *path)
{
@@ -718,6 +768,11 @@ int bdrv_open(BlockDriverState *bs, const char
*filename, int flags,
bdrv_dev_change_media_cb(bs, true);
}
+/* throttling disk I/O limits */
+if (bs-io_limits_enabled) {
+bdrv_io_limits_enable(bs);
+}
+
return 0;
unlink_and_fail:
@@ -753,6 +808,11 @@ void bdrv_close(BlockDriverState *bs)
bdrv_dev_change_media_cb(bs, false);
}
+
+/*throttling disk I/O limits*/
+if (bs-io_limits_enabled) {
+bdrv_io_limits_disable(bs);
+}
}
void bdrv_close_all(void)
@@ -1291,6 +1351,11 @@ static int coroutine_fn
bdrv_co_do_readv(BlockDriverState *bs,
return -EIO;
}
+/* throttling disk read I/O */
+if (bs-io_limits_enabled) {
+bdrv_io_limits_intercept(bs, false, nb_sectors);
+}
+
return drv-bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
}
@@ -1321,6 +1386,11 @@ static int coroutine_fn
bdrv_co_do_writev(BlockDriverState *bs,
return -EIO;
}
+/* throttling disk write I/O */
+if (bs-io_limits_enabled) {
+bdrv_io_limits_intercept(bs, true, nb_sectors);
+}
+
ret = drv-bdrv_co_writev(bs, sector_num, nb_sectors, qiov);
if (bs-dirty_bitmap) {
@@ -2512,6 +2582,156 @@ void bdrv_aio_cancel(BlockDriverAIOCB *acb)
acb-pool-cancel(acb);
}
+/* block I/O throttling */
+static bool bdrv_exceed_bps_limits(BlockDriverState *bs, int nb_sectors,
+ bool is_write, double elapsed_time, uint64_t *wait) {
+uint64_t bps_limit = 0;
+double bytes_limit, bytes_base, bytes_res;
+double slice_time, wait_time;
+
+if (bs-io_limits.bps[BLOCK_IO_LIMIT_TOTAL]) {
+bps_limit = bs-io_limits.bps[BLOCK_IO_LIMIT_TOTAL];
+} else if (bs-io_limits.bps[is_write]) {
+bps_limit = bs-io_limits.bps[is_write];
+} else {
+if (wait) {
+
Re: [Qemu-devel] [PATCH v12 3/5] block: add I/O throttling algorithm
On Tue, Nov 8, 2011 at 4:41 PM, Kevin Wolf kw...@redhat.com wrote:
Am 08.11.2011 05:34, schrieb Zhi Yong Wu:
On Mon, Nov 7, 2011 at 11:18 PM, Kevin Wolf kw...@redhat.com wrote:
Am 03.11.2011 09:57, schrieb Zhi Yong Wu:
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block.c | 220
+++
block.h | 1 +
block_int.h | 1 +
3 files changed, 222 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 79e7f09..b2af48f 100644
--- a/block.c
+++ b/block.c
@@ -74,6 +74,13 @@ static BlockDriverAIOCB
*bdrv_co_aio_rw_vector(BlockDriverState *bs,
bool is_write);
static void coroutine_fn bdrv_co_do_rw(void *opaque);
+static bool bdrv_exceed_bps_limits(BlockDriverState *bs, int nb_sectors,
+ bool is_write, double elapsed_time, uint64_t *wait);
+static bool bdrv_exceed_iops_limits(BlockDriverState *bs, bool is_write,
+ double elapsed_time, uint64_t *wait);
+static bool bdrv_exceed_io_limits(BlockDriverState *bs, int nb_sectors,
+ bool is_write, int64_t *wait);
+
static QTAILQ_HEAD(, BlockDriverState) bdrv_states =
QTAILQ_HEAD_INITIALIZER(bdrv_states);
@@ -107,6 +114,24 @@ int is_windows_drive(const char *filename)
#endif
/* throttling disk I/O limits */
+void bdrv_io_limits_disable(BlockDriverState *bs)
+{
+ bs-io_limits_enabled = false;
+
+ while (qemu_co_queue_next(bs-throttled_reqs));
+
+ if (bs-block_timer) {
+ qemu_del_timer(bs-block_timer);
+ qemu_free_timer(bs-block_timer);
+ bs-block_timer = NULL;
+ }
+
+ bs-slice_start = 0;
+ bs-slice_end = 0;
+ bs-slice_time = 0;
+ memset(bs-io_base, 0, sizeof(bs-io_base));
+}
+
static void bdrv_block_timer(void *opaque)
{
BlockDriverState *bs = opaque;
@@ -136,6 +161,31 @@ bool bdrv_io_limits_enabled(BlockDriverState *bs)
|| io_limits-iops[BLOCK_IO_LIMIT_TOTAL];
}
+static void bdrv_io_limits_intercept(BlockDriverState *bs,
+ bool is_write, int nb_sectors)
+{
+ int64_t wait_time = -1;
+
+ if (!qemu_co_queue_empty(bs-throttled_reqs)) {
+ qemu_co_queue_wait(bs-throttled_reqs);
+ }
+
+ /* In fact, we hope to keep each request's timing, in FIFO mode. The
next
+ * throttled requests will not be dequeued until the current request
is
+ * allowed to be serviced. So if the current request still exceeds the
+ * limits, it will be inserted to the head. All requests followed it
will
+ * be still in throttled_reqs queue.
+ */
+
+ while (bdrv_exceed_io_limits(bs, nb_sectors, is_write, wait_time)) {
+ qemu_mod_timer(bs-block_timer,
+ wait_time + qemu_get_clock_ns(vm_clock));
+ qemu_co_queue_wait_insert_head(bs-throttled_reqs);
+ }
+
+ qemu_co_queue_next(bs-throttled_reqs);
+}
+
/* check if the path starts with protocol: */
static int path_has_protocol(const char *path)
{
@@ -718,6 +768,11 @@ int bdrv_open(BlockDriverState *bs, const char
*filename, int flags,
bdrv_dev_change_media_cb(bs, true);
}
+ /* throttling disk I/O limits */
+ if (bs-io_limits_enabled) {
+ bdrv_io_limits_enable(bs);
+ }
+
return 0;
unlink_and_fail:
@@ -753,6 +808,11 @@ void bdrv_close(BlockDriverState *bs)
bdrv_dev_change_media_cb(bs, false);
}
+
+ /*throttling disk I/O limits*/
+ if (bs-io_limits_enabled) {
+ bdrv_io_limits_disable(bs);
+ }
}
void bdrv_close_all(void)
@@ -1291,6 +1351,11 @@ static int coroutine_fn
bdrv_co_do_readv(BlockDriverState *bs,
return -EIO;
}
+ /* throttling disk read I/O */
+ if (bs-io_limits_enabled) {
+ bdrv_io_limits_intercept(bs, false, nb_sectors);
+ }
+
return drv-bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
}
@@ -1321,6 +1386,11 @@ static int coroutine_fn
bdrv_co_do_writev(BlockDriverState *bs,
return -EIO;
}
+ /* throttling disk write I/O */
+ if (bs-io_limits_enabled) {
+ bdrv_io_limits_intercept(bs, true, nb_sectors);
+ }
+
ret = drv-bdrv_co_writev(bs, sector_num, nb_sectors, qiov);
if (bs-dirty_bitmap) {
@@ -2512,6 +2582,156 @@ void bdrv_aio_cancel(BlockDriverAIOCB *acb)
acb-pool-cancel(acb);
}
+/* block I/O throttling */
+static bool bdrv_exceed_bps_limits(BlockDriverState *bs, int nb_sectors,
+ bool is_write, double elapsed_time, uint64_t *wait) {
+ uint64_t bps_limit = 0;
+ double bytes_limit, bytes_base, bytes_res;
+ double slice_time, wait_time;
+
+ if (bs-io_limits.bps[BLOCK_IO_LIMIT_TOTAL]) {
+ bps_limit = bs-io_limits.bps[BLOCK_IO_LIMIT_TOTAL];
+ } else if (bs-io_limits.bps[is_write]) {
+ bps_limit =
Re: [Qemu-devel] [PATCH v2 0/2] nand/onenand: reject read-only drives
[Adding a few cc's, hope it helps] juha.riihim...@nokia.com writes: From: Juha Riihimäki juha.riihim...@nokia.com Make NAND and OneNAND device models reject read-only drives. Test for example by running $ qemu-system-arm -drive if=none,file=/dev/zero,readonly,id=foo -device nand,drive=foo,chip_id=0x59 -kernel /dev/null or $ qemu-system-arm -drive if=none,file=/dev/zero,readonly,id=foo -device onenand,drive=foo -kernel /dev/null Changes v1-v2: + fix bug introduced in pagesize calculation for NAND devices without a drive image + revise commit message in hw/nand patch Reviewed-by: Markus Armbruster arm...@redhat.com
[Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/
* Theodore Tso ty...@mit.edu wrote: On Nov 7, 2011, at 5:19 PM, Anthony Liguori wrote: The kernel ecosystem does not have to be limited to linux.git. There could be a process to be a kernel.org project for projects that fit a certain set of criteria. These projects could all share the Linux kernel release cadence and have a kernel maintainer as a sponsor or something like that. That is something that could potentially benefit things like e2fs-tools and all of the other tools that are tied closely to the kernel. We have that already. Packages such as e2fsprogs, xfsprogs, xfstests, sparse, git, etc., have git trees under git.kernel.org. And I agree that's the perfect place for kvm-tool and perf. :-) I guess this should be a F.A.Q., but it's worth repeating that from the perf tooling project perspective, being integrated into the kernel tree in the past 2-3 years had *numerous* *massive* advantages that improved the project's quality. The shared repo brought countless advantages that a simple kernel.org hosting in a split external tool repo would not have brought. No ifs and when about it, these are the plain facts: - Better features, better ABIs: perf maintainers can enforce clean, functional and usable tooling support *before* committing to an ABI on the kernel side. This is a *huge* deal to improve the quality of the kernel, the ABI and the tooling side and we made use of it a number of times. A perf kernel feature has to come with working, high-quality and usable tooling support - or it won't go upstream. (I could think of numerous other subsystems which would see improvements if they enforced this too.) - We have a shared Git tree with unified, visible version control. I can see kernel feature commits followed by tooling support, in a single flow of related commits: perf probe: Update perf-probe document perf probe: Support --del option trace-kprobe: Support delete probe syntax With two separate Git repositories this kind of connection between the tool and the kernel is inevitably weakened or lost. - Easier development, easier testing: if you work on a kernel feature and on matching tooling support then it's *much* easier to work in a single tree than working in two or more trees in parallel. I have worked on multi-tree features before, and except special exceptions they are generally a big pain to develop. It's not just a developer convenience factor: big pain inevitably transforms into lower quality as well. - There's a predictable 3 month release cycle of the perf tool, enforced *externally*, by the kernel project. This allowed much easier synchronization of kernel and user-space features and removes version friction. It also guarantees and simplifies the version frequency to packagers and users. - We are using and enforcing established quality control and coding principles of the kernel project. If we mess up then Linus pushes back on us at the last line of defense - and has pushed back on us in the past. I think many of the currently external kernel utilities could benefit from the resulting rise in quality. I've seen separate tool projects degrade into barely usable tinkerware - that i think cannot happen to perf, regardless of who maintains it in the future. - Better debuggability: sometimes a combination of a perf change in combination with a kernel change causes a breakage. I have bisected the shared tree a couple of times already, instead of having to bisect a (100,000 commits x 10,000 commits) combined space which much harder to debug ... - Code reuse: we can and do share source code between the kernel and the tool where it makes sense. Both the tooling and the kernel side code improves from this. (Often explicit librarization makes little sense due to the additional maintenance overhead of a split library project and the impossibly long latency of how the kernel can rely on the ready existence of such a newly created library project.) - [ etc: there's half a dozen of other, smaller positive effects as well. ] Also, while i'm generally pretty good at being the devil's advocate as well, but i've yet to see a *single* serious disadvantage of the shared repo: - Yes, in principle sharing code could be messy - in practice it is not, in fact it cleans things up where we share code and triggers fixes on both sides. Sharing code *works*, as long as there's no artificial project boundary. - Yes, in principle we could end up only testing new-kernel+new-tool and regress older ABI or tool versions. In practice it does not happen disproportionately: people (us developers included) do test the other combinations as well and the ABI has been designed in a way to make it backwards and forwards compatible by default. I think we have messed up a surprisingly
Re: [Qemu-devel] [PATCH v3] block: Use bdrv functions to replace file operation in cow.c
On Tue, Nov 08, 2011 at 02:21:13PM +0800, Li Zhi Hui wrote: Since common file operation functions lack of error detection, so change them to bdrv series functions. v3: correct some errors v2: Only contains the function modified. v1: Fix coding style and convert file operation functions to bdrv functions. Signed-off-by: Li Zhi Hui zhihu...@linux.vnet.ibm.com --- block/cow.c | 34 -- 1 files changed, 16 insertions(+), 18 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Re: [Qemu-devel] [RFC 4/6] block: request overlap detection
On Tue, Nov 08, 2011 at 02:34:22PM +0800, Zhi Yong Wu wrote:
On Mon, Nov 7, 2011 at 10:37 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Mon, Nov 7, 2011 at 11:49 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote:
On Mon, Oct 17, 2011 at 11:47 PM, Stefan Hajnoczi
stefa...@linux.vnet.ibm.com wrote:
Detect overlapping requests and remember to align to cluster boundaries
if the image format uses them. This assumes that allocating I/O is
performed in cluster granularity - which is true for qcow2, qed, etc.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block.c | 39 +--
1 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index cc3202c..0c22741 100644
--- a/block.c
+++ b/block.c
@@ -1052,21 +1052,56 @@ static BdrvTrackedRequest
*tracked_request_add(BlockDriverState *bs,
return req;
}
+/**
+ * Round a region to cluster boundaries
+ */
+static void round_to_clusters(BlockDriverState *bs,
+ int64_t sector_num, int nb_sectors,
+ int64_t *cluster_sector_num,
+ int *cluster_nb_sectors)
+{
+ BlockDriverInfo bdi;
+
+ if (bdrv_get_info(bs, bdi) 0 || bdi.cluster_size == 0) {
+ *cluster_sector_num = sector_num;
+ *cluster_nb_sectors = nb_sectors;
+ } else {
+ int64_t c = bdi.cluster_size / BDRV_SECTOR_SIZE;
+ *cluster_sector_num = (sector_num / c) * c;
I can understand the above formula, but the one below is
very magic. :) and can not be understood by me.
+ *cluster_nb_sectors = ((sector_num % c) + nb_sectors + c - 1) /
c * c;
I agree this is ugly. Here is what is going on:
c = number of sectors per cluster
cluster_sector_num = sector number rounded *down* to cluster boundary
cluster_nb_sectors = number of sectors from cluster_sector_num to
rounded up sector_num+nb_sectors
So the magic expression is takes the original sector_num to
sector_num+nb_sectors region:
|---XXX|XXX---|
Where |-| is a cluster and is the region from sector_num to
sector_num+nb_sectors, then the output should be:
|RR|RR|
Everything has been rounded to clusters. So here is the expression broken
down:
*cluster_nb_sectors = ((sector_num % c) + nb_sectors + c - 1) / c * c;
AA XX BB
|AAAXXX|XXXBBB|
A is actually equivalent to sector_num - cluster_sector_num.
X is the original unrounded region.
B is the rounding up to the next cluster bounary.
Another way of writing this:
*cluster_nb_sectors = ROUND_UP((sector_num - cluster_sector_num) +
nb_sectors, c);
Above expression seems to not be correct;
It should be
*cluster_nb_sectors = ROUND_UP((sector_num - cluster_sector_num) +
nb_sectors, c) * c;
*cluster_nb_sectors = ((sector_num % c) + nb_sectors + c - 1) / c * c;
#define ROUND_UP(x,y) (((x)+(y)-1)/(y))
ALIGN_UP() may be a better macro name, for example:
ALIGN_UP(1024, 4096) = 4096
I see how you're defining ROUND_UP() and it is different.
Stefan
Re: [Qemu-devel] Accessing a linux guest's data structures
Am 08.11.2011 06:27, schrieb 陳韋任: I am running a linux guest inside qemu and I need to determine what process, thread is currently running in the guest. How should I do this? Any suggestions? Or can anyone point me to the relevant areas in qemu's source. ^^^ I guess he want to know how to know which process is running in the guest OS from QEMU's perspective. And QEMU doesn't know or care, as a processor emulator. Therefore in some way the guest's cooperation is needed. HTE, 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] Accessing a linux guest's data structures
2011/11/8 Andreas Färber afaer...@suse.de: Am 08.11.2011 06:27, schrieb 陳韋任: I am running a linux guest inside qemu and I need to determine what process, thread is currently running in the guest. How should I do this? Any suggestions? Or can anyone point me to the relevant areas in qemu's source. ^^^ I guess he want to know how to know which process is running in the guest OS from QEMU's perspective. And QEMU doesn't know or care, as a processor emulator. Therefore in some way the guest's cooperation is needed. Try to see on libvmi (successor of xenaccess). Tou need vm introspection that can be possible via libvmi. -- Vasiliy Tolstov, Clodo.ru e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru
Re: [Qemu-devel] [RFC 4/6] block: request overlap detection
On Tue, Nov 8, 2011 at 4:16 PM, Stefan Hajnoczi
stefa...@linux.vnet.ibm.com wrote:
On Tue, Nov 08, 2011 at 02:34:22PM +0800, Zhi Yong Wu wrote:
On Mon, Nov 7, 2011 at 10:37 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Mon, Nov 7, 2011 at 11:49 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote:
On Mon, Oct 17, 2011 at 11:47 PM, Stefan Hajnoczi
stefa...@linux.vnet.ibm.com wrote:
Detect overlapping requests and remember to align to cluster boundaries
if the image format uses them. This assumes that allocating I/O is
performed in cluster granularity - which is true for qcow2, qed, etc.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block.c | 39 +--
1 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index cc3202c..0c22741 100644
--- a/block.c
+++ b/block.c
@@ -1052,21 +1052,56 @@ static BdrvTrackedRequest
*tracked_request_add(BlockDriverState *bs,
return req;
}
+/**
+ * Round a region to cluster boundaries
+ */
+static void round_to_clusters(BlockDriverState *bs,
+ int64_t sector_num, int nb_sectors,
+ int64_t *cluster_sector_num,
+ int *cluster_nb_sectors)
+{
+ BlockDriverInfo bdi;
+
+ if (bdrv_get_info(bs, bdi) 0 || bdi.cluster_size == 0) {
+ *cluster_sector_num = sector_num;
+ *cluster_nb_sectors = nb_sectors;
+ } else {
+ int64_t c = bdi.cluster_size / BDRV_SECTOR_SIZE;
+ *cluster_sector_num = (sector_num / c) * c;
I can understand the above formula, but the one below is
very magic. :) and can not be understood by me.
+ *cluster_nb_sectors = ((sector_num % c) + nb_sectors + c - 1) /
c * c;
I agree this is ugly. Here is what is going on:
c = number of sectors per cluster
cluster_sector_num = sector number rounded *down* to cluster boundary
cluster_nb_sectors = number of sectors from cluster_sector_num to
rounded up sector_num+nb_sectors
So the magic expression is takes the original sector_num to
sector_num+nb_sectors region:
|---XXX|XXX---|
Where |-| is a cluster and is the region from sector_num to
sector_num+nb_sectors, then the output should be:
|RR|RR|
Everything has been rounded to clusters. So here is the expression broken
down:
*cluster_nb_sectors = ((sector_num % c) + nb_sectors + c - 1) / c * c;
AA XX BB
|AAAXXX|XXXBBB|
A is actually equivalent to sector_num - cluster_sector_num.
X is the original unrounded region.
B is the rounding up to the next cluster bounary.
Another way of writing this:
*cluster_nb_sectors = ROUND_UP((sector_num - cluster_sector_num) +
nb_sectors, c);
Above expression seems to not be correct;
It should be
*cluster_nb_sectors = ROUND_UP((sector_num - cluster_sector_num) +
nb_sectors, c) * c;
*cluster_nb_sectors = ((sector_num % c) + nb_sectors + c - 1) / c * c;
#define ROUND_UP(x,y) (((x)+(y)-1)/(y))
ALIGN_UP() may be a better macro name, for example:
ALIGN_UP(1024, 4096) = 4096
OK. Hope to see this in your next revision.
I see how you're defining ROUND_UP() and it is different.
Stefan
--
Regards,
Zhi Yong Wu
[Qemu-devel] [PATCH] vvfat: Fix read-write mode
vvfat used to directly call into the qcow2 block driver instead of using the
block.c wrappers. With the coroutine conversion, this stopped working.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/vvfat.c | 44 +++-
1 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index 8511fe5..131680f 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -1254,15 +1254,15 @@ static int vvfat_read(BlockDriverState *bs, int64_t
sector_num,
return -1;
if (s-qcow) {
int n;
- if (s-qcow-drv-bdrv_is_allocated(s-qcow,
- sector_num, nb_sectors-i, n)) {
+if (bdrv_is_allocated(s-qcow, sector_num, nb_sectors-i, n)) {
DLOG(fprintf(stderr, sectors %d+%d allocated\n, (int)sector_num, n));
- if (s-qcow-drv-bdrv_read(s-qcow, sector_num, buf+i*0x200,
n))
- return -1;
- i += n - 1;
- sector_num += n - 1;
- continue;
- }
+if (bdrv_read(s-qcow, sector_num, buf + i*0x200, n)) {
+return -1;
+}
+i += n - 1;
+sector_num += n - 1;
+continue;
+}
DLOG(fprintf(stderr, sector %d not allocated\n, (int)sector_num));
}
if(sector_nums-faked_sectors) {
@@ -1516,7 +1516,7 @@ static inline int cluster_was_modified(BDRVVVFATState* s,
uint32_t cluster_num)
return 0;
for (i = 0; !was_modified i s-sectors_per_cluster; i++)
- was_modified = s-qcow-drv-bdrv_is_allocated(s-qcow,
+ was_modified = bdrv_is_allocated(s-qcow,
cluster2sector(s, cluster_num) + i, 1, dummy);
return was_modified;
@@ -1665,16 +1665,16 @@ static uint32_t
get_cluster_count_for_direntry(BDRVVVFATState* s,
int64_t offset = cluster2sector(s, cluster_num);
vvfat_close_current_file(s);
- for (i = 0; i s-sectors_per_cluster; i++)
- if (!s-qcow-drv-bdrv_is_allocated(s-qcow,
- offset + i, 1, dummy)) {
- if (vvfat_read(s-bs,
- offset, s-cluster_buffer, 1))
- return -1;
- if (s-qcow-drv-bdrv_write(s-qcow,
- offset, s-cluster_buffer, 1))
- return -2;
- }
+for (i = 0; i s-sectors_per_cluster; i++) {
+if (!bdrv_is_allocated(s-qcow, offset + i, 1, dummy)) {
+if (vvfat_read(s-bs, offset, s-cluster_buffer, 1)) {
+return -1;
+}
+if (bdrv_write(s-qcow, offset, s-cluster_buffer, 1))
{
+return -2;
+}
+}
+}
}
}
@@ -2619,7 +2619,9 @@ static int do_commit(BDRVVVFATState* s)
return ret;
}
-s-qcow-drv-bdrv_make_empty(s-qcow);
+if (s-qcow-drv-bdrv_make_empty) {
+s-qcow-drv-bdrv_make_empty(s-qcow);
+}
memset(s-used_clusters, 0, sector2cluster(s, s-sector_count));
@@ -2714,7 +2716,7 @@ DLOG(checkpoint());
* Use qcow backend. Commit later.
*/
DLOG(fprintf(stderr, Write to qcow backend: %d + %d\n, (int)sector_num,
nb_sectors));
-ret = s-qcow-drv-bdrv_write(s-qcow, sector_num, buf, nb_sectors);
+ret = bdrv_write(s-qcow, sector_num, buf, nb_sectors);
if (ret 0) {
fprintf(stderr, Error writing to qcow backend\n);
return ret;
--
1.7.6.4
[Qemu-devel] [PATCH] ui/vnc: Convert sasl.mechlist to g_malloc() friends
Fixes protocol_client_auth_sasl_mechname() not to crash when malloc()
fails. Spotted by Coverity.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
ui/vnc-auth-sasl.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
index 23b1bf5..a88973b 100644
--- a/ui/vnc-auth-sasl.c
+++ b/ui/vnc-auth-sasl.c
@@ -35,7 +35,7 @@ void vnc_sasl_client_cleanup(VncState *vs)
vs-sasl.encodedLength = vs-sasl.encodedOffset = 0;
vs-sasl.encoded = NULL;
g_free(vs-sasl.username);
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.username = vs-sasl.mechlist = NULL;
sasl_dispose(vs-sasl.conn);
vs-sasl.conn = NULL;
@@ -430,7 +430,7 @@ static int protocol_client_auth_sasl_start_len(VncState
*vs, uint8_t *data, size
static int protocol_client_auth_sasl_mechname(VncState *vs, uint8_t *data,
size_t len)
{
-char *mechname = malloc(len + 1);
+char *mechname = g_malloc(len + 1);
if (!mechname) {
VNC_DEBUG(Out of memory reading mechname\n);
vnc_client_error(vs);
@@ -460,7 +460,7 @@ static int protocol_client_auth_sasl_mechname(VncState *vs,
uint8_t *data, size_
}
}
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.mechlist = mechname;
VNC_DEBUG(Validated mechname '%s'\n, mechname);
@@ -469,7 +469,7 @@ static int protocol_client_auth_sasl_mechname(VncState *vs,
uint8_t *data, size_
fail:
vnc_client_error(vs);
-free(mechname);
+g_free(mechname);
return -1;
}
@@ -608,7 +608,7 @@ void start_auth_sasl(VncState *vs)
}
VNC_DEBUG(Available mechanisms for client: '%s'\n, mechlist);
-if (!(vs-sasl.mechlist = strdup(mechlist))) {
+if (!(vs-sasl.mechlist = g_strdup(mechlist))) {
VNC_DEBUG(Out of memory);
sasl_dispose(vs-sasl.conn);
vs-sasl.conn = NULL;
--
1.7.6.4
Re: [Qemu-devel] [PATCH v3] block: Use bdrv functions to replace file operation in cow.c
Am 08.11.2011 07:21, schrieb Li Zhi Hui: Since common file operation functions lack of error detection, so change them to bdrv series functions. v3: correct some errors v2: Only contains the function modified. v1: Fix coding style and convert file operation functions to bdrv functions. Signed-off-by: Li Zhi Hui zhihu...@linux.vnet.ibm.com Thanks, applied to the block branch (for 1.1) Kevin
[Qemu-devel] [PATCH] ui/vnc: Convert sasl.mechlist to g_malloc() friends
Fixes protocol_client_auth_sasl_mechname() not to crash when malloc()
fails. Spotted by Coverity.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
ui/vnc-auth-sasl.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
index 23b1bf5..a88973b 100644
--- a/ui/vnc-auth-sasl.c
+++ b/ui/vnc-auth-sasl.c
@@ -35,7 +35,7 @@ void vnc_sasl_client_cleanup(VncState *vs)
vs-sasl.encodedLength = vs-sasl.encodedOffset = 0;
vs-sasl.encoded = NULL;
g_free(vs-sasl.username);
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.username = vs-sasl.mechlist = NULL;
sasl_dispose(vs-sasl.conn);
vs-sasl.conn = NULL;
@@ -430,7 +430,7 @@ static int protocol_client_auth_sasl_start_len(VncState
*vs, uint8_t *data, size
static int protocol_client_auth_sasl_mechname(VncState *vs, uint8_t *data,
size_t len)
{
-char *mechname = malloc(len + 1);
+char *mechname = g_malloc(len + 1);
if (!mechname) {
VNC_DEBUG(Out of memory reading mechname\n);
vnc_client_error(vs);
@@ -460,7 +460,7 @@ static int protocol_client_auth_sasl_mechname(VncState *vs,
uint8_t *data, size_
}
}
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.mechlist = mechname;
VNC_DEBUG(Validated mechname '%s'\n, mechname);
@@ -469,7 +469,7 @@ static int protocol_client_auth_sasl_mechname(VncState *vs,
uint8_t *data, size_
fail:
vnc_client_error(vs);
-free(mechname);
+g_free(mechname);
return -1;
}
@@ -608,7 +608,7 @@ void start_auth_sasl(VncState *vs)
}
VNC_DEBUG(Available mechanisms for client: '%s'\n, mechlist);
-if (!(vs-sasl.mechlist = strdup(mechlist))) {
+if (!(vs-sasl.mechlist = g_strdup(mechlist))) {
VNC_DEBUG(Out of memory);
sasl_dispose(vs-sasl.conn);
vs-sasl.conn = NULL;
--
1.7.6.4
[Qemu-devel] [PATCH] Clean up assertion in get_boot_devices_list()
g_strdup() can't fail, remove assertion. Assert its argument can't be
null, because that's not obvious (add_boot_device_path() ensures it).
Signed-off-by: Markus Armbruster arm...@redhat.com
---
vl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/vl.c b/vl.c
index 641629b..f169aac 100644
--- a/vl.c
+++ b/vl.c
@@ -915,8 +915,8 @@ char *get_boot_devices_list(uint32_t *size)
} else if (devpath) {
bootpath = devpath;
} else {
+assert(i-suffix);
bootpath = g_strdup(i-suffix);
-assert(bootpath);
}
if (total) {
--
1.7.6.4
Re: [Qemu-devel] [PATCH] vvfat: Fix read-write mode
On 11/08/2011 10:55 AM, Kevin Wolf wrote:
vvfat used to directly call into the qcow2 block driver instead of using the
block.c wrappers. With the coroutine conversion, this stopped working.
Signed-off-by: Kevin Wolfkw...@redhat.com
---
block/vvfat.c | 44 +++-
1 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index 8511fe5..131680f 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -1254,15 +1254,15 @@ static int vvfat_read(BlockDriverState *bs, int64_t
sector_num,
return -1;
if (s-qcow) {
int n;
- if (s-qcow-drv-bdrv_is_allocated(s-qcow,
- sector_num, nb_sectors-i,n)) {
+if (bdrv_is_allocated(s-qcow, sector_num, nb_sectors-i,n)) {
DLOG(fprintf(stderr, sectors %d+%d allocated\n, (int)sector_num, n));
- if (s-qcow-drv-bdrv_read(s-qcow, sector_num, buf+i*0x200,
n))
- return -1;
- i += n - 1;
- sector_num += n - 1;
- continue;
- }
+if (bdrv_read(s-qcow, sector_num, buf + i*0x200, n)) {
+return -1;
+}
+i += n - 1;
+sector_num += n - 1;
+continue;
+}
DLOG(fprintf(stderr, sector %d not allocated\n, (int)sector_num));
}
if(sector_nums-faked_sectors) {
@@ -1516,7 +1516,7 @@ static inline int cluster_was_modified(BDRVVVFATState* s,
uint32_t cluster_num)
return 0;
for (i = 0; !was_modified i s-sectors_per_cluster; i++)
- was_modified = s-qcow-drv-bdrv_is_allocated(s-qcow,
+ was_modified = bdrv_is_allocated(s-qcow,
cluster2sector(s, cluster_num) + i, 1,dummy);
return was_modified;
@@ -1665,16 +1665,16 @@ static uint32_t
get_cluster_count_for_direntry(BDRVVVFATState* s,
int64_t offset = cluster2sector(s, cluster_num);
vvfat_close_current_file(s);
- for (i = 0; i s-sectors_per_cluster; i++)
- if (!s-qcow-drv-bdrv_is_allocated(s-qcow,
- offset + i, 1,dummy)) {
- if (vvfat_read(s-bs,
- offset, s-cluster_buffer, 1))
- return -1;
- if (s-qcow-drv-bdrv_write(s-qcow,
- offset, s-cluster_buffer, 1))
- return -2;
- }
+for (i = 0; i s-sectors_per_cluster; i++) {
+if (!bdrv_is_allocated(s-qcow, offset + i, 1,dummy)) {
+if (vvfat_read(s-bs, offset, s-cluster_buffer, 1)) {
+return -1;
+}
+if (bdrv_write(s-qcow, offset, s-cluster_buffer, 1))
{
+return -2;
+}
+}
+}
}
}
@@ -2619,7 +2619,9 @@ static int do_commit(BDRVVVFATState* s)
return ret;
}
-s-qcow-drv-bdrv_make_empty(s-qcow);
+if (s-qcow-drv-bdrv_make_empty) {
+s-qcow-drv-bdrv_make_empty(s-qcow);
+}
memset(s-used_clusters, 0, sector2cluster(s, s-sector_count));
@@ -2714,7 +2716,7 @@ DLOG(checkpoint());
* Use qcow backend. Commit later.
*/
DLOG(fprintf(stderr, Write to qcow backend: %d + %d\n, (int)sector_num,
nb_sectors));
-ret = s-qcow-drv-bdrv_write(s-qcow, sector_num, buf, nb_sectors);
+ret = bdrv_write(s-qcow, sector_num, buf, nb_sectors);
if (ret 0) {
fprintf(stderr, Error writing to qcow backend\n);
return ret;
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Re: [Qemu-devel] [PATCH] ui/vnc: Convert sasl.mechlist to g_malloc() friends
Butterfingers, apologies please ignore.
[Qemu-devel] [PATCH] qdev: Fix crash on -device '?=x'
Spotted by Coverity.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/qdev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 50976dd..106407f 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -186,7 +186,7 @@ int qdev_device_help(QemuOpts *opts)
return 1;
}
-if (!qemu_opt_get(opts, ?)) {
+if (!driver || !qemu_opt_get(opts, ?)) {
return 0;
}
--
1.7.6.4
Re: [Qemu-devel] [PATCH 2/2] ac97: don't override the pci subsystem id
On 11/08/2011 10:08 AM, Gerd Hoffmann wrote: On 11/07/11 17:00, Anthony Liguori wrote: On 11/07/2011 09:33 AM, Gerd Hoffmann wrote: This patch removes the code lines which set the subsystem id for the emulated ac97 card to 8086:. Due to the device id being zero the subsystem id isn't vaild anyway. With the patch applied the sound card gets the default qemu subsystem id (1af4:1100) instead. I don't like having a property of use broken. Well, it *is* broken. Suggestions for a better name? correctness_challenged? legacy? Wouldn't it be better to have the subsystem vendor and device id be configurable, set the default to the qemu subsystem ids, and then set it to 8086: for 1.0? I don't want this being fully configurable just for the snake of backward compatibility with old qemu versions. I imagine some downstreams will want to configure it, but if we ever do that, it's not for 1.0. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
[Qemu-devel] [TestDay] s390x build broken
Hi everyone,
Got this with v1.0-rc1 tarball:
CCi386-softmmu/tcg/tcg.o
In file included from /suse/afaerber/QEMU/qemu-1.0rc1/tcg/tcg.c:176:
/suse/afaerber/QEMU/qemu-1.0rc1/tcg/s390/tcg-target.c:677: error:
conflicting types for ‘tcg_out_mov’
/suse/afaerber/QEMU/qemu-1.0rc1/tcg/tcg.c:76: error: previous
declaration of ‘tcg_out_mov’ was here
/suse/afaerber/QEMU/qemu-1.0rc1/tcg/s390/tcg-target.c:689: error:
conflicting types for ‘tcg_out_movi’
/suse/afaerber/QEMU/qemu-1.0rc1/tcg/tcg.c:77: error: previous
declaration of ‘tcg_out_movi’ was here
/suse/afaerber/QEMU/qemu-1.0rc1/tcg/s390/tcg-target.c:829: error:
conflicting types for ‘tcg_out_ld’
/suse/afaerber/QEMU/qemu-1.0rc1/tcg/tcg.c:74: error: previous
declaration of ‘tcg_out_ld’ was here
/suse/afaerber/QEMU/qemu-1.0rc1/tcg/s390/tcg-target.c:839: error:
conflicting types for ‘tcg_out_st’
/suse/afaerber/QEMU/qemu-1.0rc1/tcg/tcg.c:81: error: previous
declaration of ‘tcg_out_st’ was here
make[1]: *** [tcg/tcg.o] Fehler 1
make: *** [subdir-i386-softmmu] Fehler 2
The difference is TCGReg vs. int.
tcg/tcg.c:
static void tcg_out_mov(TCGContext *s, TCGType type, int ret, int arg);
tcg/s390/tcg-target.c:
static void tcg_out_mov(TCGContext *s, TCGType type, TCGReg dst, TCGReg src)
tcg/s390/tcg-target.h:
typedef enum TCGReg {
TCG_REG_R0 = 0,
TCG_REG_R1,
TCG_REG_R2,
TCG_REG_R3,
TCG_REG_R4,
TCG_REG_R5,
TCG_REG_R6,
TCG_REG_R7,
TCG_REG_R8,
TCG_REG_R9,
TCG_REG_R10,
TCG_REG_R11,
TCG_REG_R12,
TCG_REG_R13,
TCG_REG_R14,
TCG_REG_R15
} TCGReg;
Alex, wasn't this already discussed a few weeks ago?
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] ui/vnc: Convert sasl.mechlist to g_malloc() friends
On Tue, Nov 08, 2011 at 10:55:52AM +0100, Markus Armbruster wrote:
Fixes protocol_client_auth_sasl_mechname() not to crash when malloc()
fails. Spotted by Coverity.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
ui/vnc-auth-sasl.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
index 23b1bf5..a88973b 100644
--- a/ui/vnc-auth-sasl.c
+++ b/ui/vnc-auth-sasl.c
@@ -35,7 +35,7 @@ void vnc_sasl_client_cleanup(VncState *vs)
vs-sasl.encodedLength = vs-sasl.encodedOffset = 0;
vs-sasl.encoded = NULL;
g_free(vs-sasl.username);
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.username = vs-sasl.mechlist = NULL;
sasl_dispose(vs-sasl.conn);
vs-sasl.conn = NULL;
@@ -430,7 +430,7 @@ static int protocol_client_auth_sasl_start_len(VncState
*vs, uint8_t *data, size
static int protocol_client_auth_sasl_mechname(VncState *vs, uint8_t *data,
size_t len)
{
-char *mechname = malloc(len + 1);
+char *mechname = g_malloc(len + 1);
if (!mechname) {
VNC_DEBUG(Out of memory reading mechname\n);
vnc_client_error(vs);
You can delete the if (!mechname) block now you have g_malloc
The reason for the crash on OOM is here, but the diff context doesn't show it:
Notice the missing 'return -1' statement following vnc_client_error(vs);
char *mechname = malloc(len + 1);
if (!mechname) {
VNC_DEBUG(Out of memory reading mechname\n);
vnc_client_error(vs);
}
strncpy(mechname, (char*)data, len);
mechname[len] = '\0';
@@ -460,7 +460,7 @@ static int protocol_client_auth_sasl_mechname(VncState
*vs, uint8_t *data, size_
}
}
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.mechlist = mechname;
VNC_DEBUG(Validated mechname '%s'\n, mechname);
@@ -469,7 +469,7 @@ static int protocol_client_auth_sasl_mechname(VncState
*vs, uint8_t *data, size_
fail:
vnc_client_error(vs);
-free(mechname);
+g_free(mechname);
return -1;
}
@@ -608,7 +608,7 @@ void start_auth_sasl(VncState *vs)
}
VNC_DEBUG(Available mechanisms for client: '%s'\n, mechlist);
-if (!(vs-sasl.mechlist = strdup(mechlist))) {
+if (!(vs-sasl.mechlist = g_strdup(mechlist))) {
VNC_DEBUG(Out of memory);
sasl_dispose(vs-sasl.conn);
vs-sasl.conn = NULL;
Again, you can delete the conditional here with g_strdup
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState
flash_mapped reflect the bit 2 of a control register.
Peter, does this patch look better ?
commit 2fa7b11ee2b2532d00056d6bbc928c5162925e1d
Author: Benoît Canet benoit.ca...@gmail.com
Date: Mon Oct 24 14:39:26 2011 +0200
integratorcp: convert integratorcm to VMState
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index 9a289b4..4e51579 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -34,6 +34,42 @@ typedef struct {
uint32_t fiq_enabled;
} integratorcm_state;
+static void integratorcm_do_remap(integratorcm_state *s, int flash);
+
+static int integratorcm_post_load(void *opaque, int version_id)
+{
+integratorcm_state *s = opaque;
+
+if (s-cm_ctrl 4) {
+integratorcm_do_remap(s, 0);
+}
+/* ??? tlb_flush (cpu_single_env, 1); */
+return 0;
+}
+
+static const VMStateDescription vmstate_integratorcm = {
+.name = integratorcm,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.post_load = integratorcm_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(memsz, integratorcm_state),
+VMSTATE_UINT32(cm_osc, integratorcm_state),
+VMSTATE_UINT32(cm_ctrl, integratorcm_state),
+VMSTATE_UINT32(cm_lock, integratorcm_state),
+VMSTATE_UINT32(cm_auxosc, integratorcm_state),
+VMSTATE_UINT32(cm_sdram, integratorcm_state),
+VMSTATE_UINT32(cm_init, integratorcm_state),
+VMSTATE_UINT32(cm_flags, integratorcm_state),
+VMSTATE_UINT32(cm_nvflags, integratorcm_state),
+VMSTATE_UINT32(int_level, integratorcm_state),
+VMSTATE_UINT32(irq_enabled, integratorcm_state),
+VMSTATE_UINT32(fiq_enabled, integratorcm_state),
+VMSTATE_END_OF_LIST()
+}
+};
+
static uint8_t integrator_spd[128] = {
128, 8, 4, 11, 9, 1, 64, 0, 2, 0xa0, 0xa0, 0, 0, 8, 0, 1,
0xe, 4, 0x1c, 1, 2, 0x20, 0xc0, 0, 0, 0, 0, 0x30, 0x28, 0x30, 0x28, 0x40
@@ -547,6 +583,7 @@ static SysBusDeviceInfo core_info = {
.init = integratorcm_init,
.qdev.name = integrator_core,
.qdev.size = sizeof(integratorcm_state),
+.qdev.vmsd = vmstate_integratorcm,
.qdev.props = (Property[]) {
DEFINE_PROP_UINT32(memsz, integratorcm_state, memsz, 0),
DEFINE_PROP_END_OF_LIST(),
On Tue, Nov 8, 2011 at 7:33 AM, Avi Kivity a...@redhat.com wrote:
On 11/08/2011 04:07 AM, Peter Maydell wrote:
2011/10/26 Peter Maydell peter.mayd...@linaro.org:
On 25 October 2011 12:09, Benoît Canet benoit.ca...@gmail.com wrote:
+static const VMStateDescription vmstate_integratorcm = {
+.name = integratorcm,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(memsz, integratorcm_state),
+VMSTATE_BOOL(flash_mapped, integratorcm_state),
This raises a question. flash_mapped here is a flag which just
tracks whether the associated MemoryRegion is currently mapped
or unmapped. Do we need to do anything special to ensure that
the MemoryRegion itself is reset to the correct mapped/unmapped
state on restore?
I recall discussing this kind of thing with Avi on IRC but I
can't remember what the conclusion was.
Avi, ping? I'm still interested in the answer to this question.
Sorry, missed this. Yes, you need to ensure the memory region mapping
reflects flash_mapped.
btw, is flash_mapped a real device state (corresponds to a real memory
bit on the device) or just an artefact? It's usually a bad idea to cast
implementation artefacts in vmstate concrete.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
Re: [Qemu-devel] [PATCH v12 4/5] hmp/qmp: add block_set_io_throttle
Am 08.11.2011 06:00, schrieb Zhi Yong Wu: Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- block.c | 15 + blockdev.c | 59 ++ blockdev.h |2 + hmp-commands.hx | 15 + hmp.c| 10 + qapi-schema.json | 16 +- qerror.c |4 +++ qerror.h |3 ++ qmp-commands.hx | 53 +++- 9 files changed, 175 insertions(+), 2 deletions(-) Thanks, applied all to the block branch (for 1.1) Kevin
Re: [Qemu-devel] [Qemu-ppc] [PATCH] pseries: Correct RAM size check for SLOF
Am Tue, 8 Nov 2011 16:52:16 +1100
schrieb David Gibson da...@gibson.dropbear.id.au:
The SLOF firmware used on the pseries machine needs a reasonable amount of
(guest) RAM in order to run, so we have a check in the machine init
function to check that this is available. However, SLOF runs in real mode
(MMU off) which means it can only actually access the RMA (Real Mode Area),
not all of RAM. In many cases the RMA is the same as all RAM, but when
running with Book3S HV KVM on PowerPC 970, the RMA must be especially
allocated to be (host) physically contiguous. In this case, the RMA size
is determined by what the host admin allocated at boot time, and will
usually be less than the whole guest RAM size.
This patch corrects the test to see if SLOF has enough memory for this
case.
[...]
@@ -562,9 +562,9 @@ static void ppc_spapr_init(ram_addr_t ram_size,
spapr-entry_point = KERNEL_LOAD_ADDR;
} else {
-if (ram_size (MIN_RAM_SLOF 20)) {
+if (rma_size (MIN_RMA_SLOF 20)) {
fprintf(stderr, qemu: pSeries SLOF firmware requires =
-%ldM guest RAM\n, MIN_RAM_SLOF);
+%ldM guest RAM\n, MIN_RMA_SLOF);
Maybe it's more helpful for the unexperienced users when we change the
term guest RAM to real mode area (RMA) memory here? What do you
think?
Thomas
Re: [Qemu-devel] [PATCH 2/2] ac97: don't override the pci subsystem id
Hi, Wouldn't it be better to have the subsystem vendor and device id be configurable, set the default to the qemu subsystem ids, and then set it to 8086: for 1.0? I don't want this being fully configurable just for the snake of backward compatibility with old qemu versions. I imagine some downstreams will want to configure it, but if we ever do that, it's not for 1.0. And for that it would make more sense to make the default qemu subsystem id configurable, not the individual device IDs ... cheers, Gerd
Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/
On Nov 8, 2011, at 4:32 AM, Ingo Molnar wrote: No ifs and when about it, these are the plain facts: - Better features, better ABIs: perf maintainers can enforce clean, functional and usable tooling support *before* committing to an ABI on the kernel side. We don't have to be careful about breaking interface compatibility while we are developing new features. The flip side of this is that it's not obvious when an interface is stable, and when it is still subject to change. It makes life much harder for any userspace code that doesn't live in the kernel. And I think we do agree that moving all of userspace into a single git tree makes no sense, right? - We have a shared Git tree with unified, visible version control. I can see kernel feature commits followed by tooling support, in a single flow of related commits: perf probe: Update perf-probe document perf probe: Support --del option trace-kprobe: Support delete probe syntax With two separate Git repositories this kind of connection between the tool and the kernel is inevitably weakened or lost. We don't have to clearly document new interfaces between kernel and userspace, and instead rely on git commit order for people to figure out what's going on with some new interface - Easier development, easier testing: if you work on a kernel feature and on matching tooling support then it's *much* easier to work in a single tree than working in two or more trees in parallel. I have worked on multi-tree features before, and except special exceptions they are generally a big pain to develop. I've developed in the split tree systems, and it's really not that hard. It does mean you have to be explicit about designing interfaces up front, and then you have to have a good, robust way of negotiating what features are in the kernel, and what features are supposed by the userspace --- but if you don't do that then having good backwards and forwards compatibility between different versions of the tool simply doesn't exist. So at the end of the day it question is whether you want to be able to (for example) update e2fsck to get better ability to fix more file system corruptions, without needing to upgrade the kernel. If you want to be able to use a newer, better e2fsck with an older, enterprise kernel, then you have use certain programming disciplines. That's where the work is, not in whether you have to maintain two git trees or a single git tree. - We are using and enforcing established quality control and coding principles of the kernel project. If we mess up then Linus pushes back on us at the last line of defense - and has pushed back on us in the past. I think many of the currently external kernel utilities could benefit from the resulting rise in quality. I've seen separate tool projects degrade into barely usable tinkerware - that i think cannot happen to perf, regardless of who maintains it in the future. That's basically saying that if you don't have someone competent managing the git tree and providing quality assurance, life gets hard. Sure. But at the same time, does it scale to move all of userspace under one git tree and depending on Linus to push back? I mean, it would have been nice to move all of GNOME 3 under the Linux kernel, so Linus could have pushed back on behalf of all of us power users, but as much as many of us would have appreciated someone being able to push back against the insanity which is the GNOME design process, is that really a good enough excuse to move all of GNOME 3 into the kernel source tree? :-) - Better debuggability: sometimes a combination of a perf change in combination with a kernel change causes a breakage. I have bisected the shared tree a couple of times already, instead of having to bisect a (100,000 commits x 10,000 commits) combined space which much harder to debug … What you are describing happens when someone hasn't been careful about their kernel/userspace interfaces. If you have been rigorous with your interfaces, this isn't really an issue. When's the last time we've had to do a NxM exhaustive testing to find a broken sys call ABI between (for example) the kernel and MySQL? - Code reuse: we can and do share source code between the kernel and the tool where it makes sense. Both the tooling and the kernel side code improves from this. (Often explicit librarization makes little sense due to the additional maintenance overhead of a split library project and the impossibly long latency of how the kernel can rely on the ready existence of such a newly created library project.) How much significant code really can get shared? Memory allocation is different between kernel and userspace code, how you do I/O is different, error reporting conventions are generally different, etc. You might have some serialization and deserialization code which is
Re: [Qemu-devel] Accessing a linux guest's data structures
Thanks for the suggestions, guys! I will take a look at libvmi. As an aside, can someone tell me where in the qemu source can I inspect each guest instruction? I want all guest instructions to first go through my code. Ankur Dahiya On Tue, Nov 8, 2011 at 3:18 PM, Vasiliy Tolstov v.tols...@selfip.ru wrote: 2011/11/8 Andreas Färber afaer...@suse.de: Am 08.11.2011 06:27, schrieb 陳韋任: I am running a linux guest inside qemu and I need to determine what process, thread is currently running in the guest. How should I do this? Any suggestions? Or can anyone point me to the relevant areas in qemu's source. ^^^ I guess he want to know how to know which process is running in the guest OS from QEMU's perspective. And QEMU doesn't know or care, as a processor emulator. Therefore in some way the guest's cooperation is needed. Try to see on libvmi (successor of xenaccess). Tou need vm introspection that can be possible via libvmi. -- Vasiliy Tolstov, Clodo.ru e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru
[Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility
* Ted Ts'o ty...@mit.edu wrote: I don't believe there's ever been any guarantee that perf test from version N of the kernel will always work on a version N+M of the kernel. Perhaps I am wrong, though. If that is a guarantee that the perf developers are willing to stand behind, or have already made, I would love to be corrected and would be delighted to hear that in fact there is a stable, backwards compatible perf ABI. We do even more than that, the perf ABI is fully backwards *and* forwards compatible: you can run older perf on newer ABIs and newer perf on older ABIs. To show you how it works in practice, here's a random cross-compatibility experiment: going back to the perf ABI of 2 years ago. I used v2.6.32 which was just the second upstream kernel with perf released in it. So i took a fresh perf tool version and booted a vanilla v2.6.32 (x86, defconfig, PERF_COUNTERS=y) kernel: $ uname -a Linux mercury 2.6.32 #162137 SMP Tue Nov 8 10:55:37 CET 2011 x86_64 x86_64 x86_64 GNU/Linux $ perf --version perf version 3.1.1927.gceec2 $ perf top Events: 2K cycles 61.68% [kernel] [k] sha_transform 16.09% [kernel] [k] mix_pool_bytes_extract 4.70% [kernel] [k] extract_buf 4.17% [kernel] [k] _spin_lock_irqsave 1.44% [kernel] [k] copy_user_generic_string 0.75% [kernel] [k] extract_entropy_user 0.37% [kernel] [k] acpi_pm_read [the box is running a /dev/urandom stress-test as you can see.] $ perf stat sleep 1 Performance counter stats for 'sleep 1': 0.766698 task-clock#0.001 CPUs utilized 1 context-switches #0.001 M/sec 0 CPU-migrations#0.000 M/sec 177 page-faults #0.231 M/sec 1,513,332 cycles#1.974 GHz not supported stalled-cycles-frontend not supported stalled-cycles-backend 522,609 instructions #0.35 insns per cycle 65,812 branches # 85.838 M/sec 7,762 branch-misses # 11.79% of all branches 1.076211168 seconds time elapsed The two not supported events are not supported by the old kernel - but the other events were and the tool picked them up without bailing out. Regular profiling: $ perf record -a sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.075 MB perf.data (~3279 samples) ] perf report output: $ perf report Events: 1K cycles 64.45% dd [kernel.kallsyms][k] sha_transform 19.39% dd [kernel.kallsyms][k] mix_pool_bytes_extract 4.11% dd [kernel.kallsyms][k] _spin_lock_irqsave 2.98% dd [kernel.kallsyms][k] extract_buf 0.84% dd [kernel.kallsyms][k] copy_user_generic_string 0.38% ssh libcrypto.so.0.9.8b [.] lh_insert 0.28% flush-8:0 [kernel.kallsyms][k] block_write_full_page_endio 0.28% flush-8:0 [kernel.kallsyms][k] generic_make_request These examples show *PICTURE PERFECT* backwards ABI compatibility, when using the bleeding perf tool on an ancient perf kernel (when it wasnt even called 'perf events' but 'perf counters'). [ Note, i didnt go back to v2.6.31, the oldest upstream perf kernel, because it's such a pain to build with recent binutils and recent GCC ... v2.6.32 already needed a workaround and a couple of .config tweaks to build and boot at all. ] Then i built the ancient v2.6.32 perf tool from 2 years ago: $ perf --version perf version 0.0.2.PERF and booted a fresh v3.1+ kernel: $ uname -a Linux mercury 3.1.0-tip+ #162138 SMP Tue Nov 8 11:14:26 CET 2011 x86_64 x86_64 x86_64 GNU/Linux $ perf stat ls Performance counter stats for 'ls': 1.739193 task-clock-msecs # 0.069 CPUs 0 context-switches # 0.000 M/sec 0 CPU-migrations # 0.000 M/sec 250 page-faults # 0.144 M/sec 3477562 cycles # 1999.526 M/sec 1661460 instructions # 0.478 IPC 839826 cache-references #482.883 M/sec 15742 cache-misses # 9.051 M/sec 0.025231139 seconds time elapsed $ perf top -- PerfTop: 38916 irqs/sec kernel:99.6% [10 cycles], (all, 2 CPUs) -- samplespcnt kernel function ___ _ ___ 41191.00 - 53.1% : sha_transform 20818.00 - 26.8% : mix_pool_bytes_extract
Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility
On Tue, 2011-11-08 at 11:22 +0100, Ingo Molnar wrote: We do even more than that, the perf ABI is fully backwards *and* forwards compatible: you can run older perf on newer ABIs and newer perf on older ABIs. The ABI yes, the tool no, the tool very much relies on some newer ABI parts. Supporting fallbacks isn't always possible/wanted.
[Qemu-devel] pseries segfault
Hi, qemu-system-ppc64 segfaults with todays git master: $ qemu-img create -f qcow2 empty.img 1G Formatting 'empty.img', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 $ /home/kraxel/projects/qemu/build-default/ppc64-softmmu/qemu-system-ppc64 -M pseries -m 1024 -nodefaults -serial vc:100Cx50C -hda empty.img sPAPR reset Segmentation fault (core dumped) Program terminated with signal 11, Segmentation fault. #0 spapr_populate_pci_devices (phb=0x3d4219cf38, xics_phandle=4369, fdt=0x22ba620) at /home/kraxel/projects/qemu/hw/spapr_pci.c:368 368 uint32_t interrupt_map[bus-nirq][7]; (gdb) bt #0 spapr_populate_pci_devices (phb=0x3d4219cf38, xics_phandle=4369, fdt=0x22ba620) at /home/kraxel/projects/qemu/hw/spapr_pci.c:368 #1 0x00599228 in spapr_finalize_fdt (opaque=0x1ccf390) at /home/kraxel/projects/qemu/hw/spapr.c:340 #2 spapr_reset (opaque=0x1ccf390) at /home/kraxel/projects/qemu/hw/spapr.c:381 #3 0x004cd312 in qemu_system_reset (report=false) at /home/kraxel/projects/qemu/vl.c:1381 #4 0x004ce93b in main (argc=value optimized out, argv=value optimized out, envp=value optimized out) at /home/kraxel/projects/qemu/vl.c:3452 (gdb) print bus $1 = (PCIBus *) 0x0
[Qemu-devel] [TestDay] ppc64 pseries segfault
Hello, On openSUSE 12.1 RC2 x86_64 host $ ppc64-softmmu/qemu-system-ppc64 -M pseries -L .../pc-bios segfaults. Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00578a7e in spapr_create_phb (spapr=0x1247f80, busname= 0x77f1b2 pci, buid=optimized out, mem_win_addr=optimized out, mem_win_size=536870912, io_win_addr=1101659111424) at /home/andreas/QEMU/qemu/hw/spapr_pci.c:306 306 QLIST_INSERT_HEAD(spapr-phbs, phb, list); (gdb) bt #0 0x00578a7e in spapr_create_phb (spapr=0x1247f80, busname= 0x77f1b2 pci, buid=optimized out, mem_win_addr=optimized out, mem_win_size=536870912, io_win_addr=1101659111424) at /home/andreas/QEMU/qemu/hw/spapr_pci.c:306 #1 0x005760f8 in ppc_spapr_init (ram_size=134217728, boot_device= 0x7fffdd50 cad, kernel_filename=0x0, kernel_cmdline=0x69d000 , initrd_filename=0x0, cpu_model=0x7ab640 POWER7) at /home/andreas/QEMU/qemu/hw/spapr.c:507 #2 0x0040a4a9 in main (argc=optimized out, argv=optimized out, envp=optimized out) at /home/andreas/QEMU/qemu/vl.c:3340 I'd expect seeing SLOF boot. 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] [F.A.Q.] perf ABI backwards and forwards compatibility
On Nov 8, 2011, at 5:22 AM, Ingo Molnar wrote: We do even more than that, the perf ABI is fully backwards *and* forwards compatible: you can run older perf on newer ABIs and newer perf on older ABIs. It's great to hear that! But in that case, there's an experiment we can't really run, which is if perf had been developed in a separate tree, would it have been just as successful? My belief is that perf was successful because *you* and the other perf developers were competent developers, and who got things right. Not because it was inside the kernel tree. You've argued that things were much better because it was inside the tree, but that's not actually something we can put to a scientific repeatable experiment. I will observe that some of the things that caused me to be come enraged by system tap (such as the fact that I simply couldn't even build the damned thing on a non-Red Hat compilation environment, would not have been solved by moving Systemtap into the kernel git tree --- at least not without moving a large number of its external dependencies into the kernel tree as well, such as the elf library, et. al.) So there is a whole class of problems that were seen in previous tooling systems that were not caused by the fact that they were separate from the kernel, but that they weren't being developed by the kernel developers, so they didn't understand how to make the tool work well for kernel developers. If we had gone back in time, and had the same set of perf developers working in an external tree, and Systemtap and/or Oprofile had been developed in the kernel tree, would it really have made that much difference? Sure, Linus and other kernel developers would have yelled at the Systemtap and Oprofile folks more, but I haven't seen that much evidence that they listened to us when they were outside of the kernel tree, and it's not obvious they would have listened with the code being inside the kernel tree. My claim is that is that outcome wouldn't have been all that different, and that's because the difference was *you*, Ingo Molnar, as a good engineer, would have designed a good backwards compatible ABI whether the code was inside or outside of the kernel, and you would have insisted on good taste and usefulness to kernel programmers whether perf was in our out of the kernel, and you would have insisted on kernel coding guidelines and regular release cycles, even if perf was outside of the kernel. As Linus sometimes like to say, in many cases it's more about the _people_. Regards, -- Ted
Re: [Qemu-devel] [PATCH 1/3] sonic: fix typo
On Sun, Nov 06, 2011 at 10:48:50PM +0100, Hervé Poussineau wrote: Signed-off-by: Hervé Poussineau hpous...@reactos.org --- hw/dp8393x.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Thanks, applied to the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Stefan
Re: [Qemu-devel] [Qemu-trivial] [PATCH] arm: Fix CP15 FSR (C5) domain setting
On Fri, Nov 04, 2011 at 09:50:25PM +0100, Jean-Christophe DUBOIS wrote: During Xvisor development, it was noted that qemu did not return the correct domain value in the Cp15 [Data] FSR register (C5). This patch is a proposal to fix it. Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net --- CCed Peter Maydell so this can go through the ARM tree. Stefan
Re: [Qemu-devel] [Qemu-trivial][PATCH] linux-user/main.c: Add option to user-mode emulation so that user can specify log file name
On Tue, Nov 08, 2011 at 05:46:44PM +0800, 陳韋任 wrote:
QEMU linux user-mode's default log file name is /tmp/qemu.log. In order to
change the log file name, user need to modify the source code then recompile
QEMU. This patch allow user use -D logfile option to specify the log file
name.
Signed-off-by: Chen Wen-Ren che...@iis.sinica.edu.tw
---
linux-user/main.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index d1bbc57..95d689e 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2945,6 +2945,11 @@ static void handle_arg_log(const char *arg)
cpu_set_log(mask);
}
+static void handle_arg_log_filename(const char *arg)
+{
+cpu_set_log_filename(arg);
+}
+
static void handle_arg_set_env(const char *arg)
{
char *r, *p, *token;
@@ -3125,6 +3130,8 @@ struct qemu_argument arg_table[] = {
#endif
{d, QEMU_LOG, true, handle_arg_log,
options,activate log},
+{D, QEMU_LOG_FILENAME, true, handle_arg_log_filename,
+ logfile, override default logfile location},
{p, QEMU_PAGESIZE,true, handle_arg_pagesize,
pagesize, set the host page size to 'pagesize'},
{singlestep, QEMU_SINGLESTEP, false, handle_arg_singlestep,
--
1.7.3.4
CCing this patch onto qemu-devel@nongnu.org.
Stefan
Re: [Qemu-devel] [PATCH] ui/vnc: Convert sasl.mechlist to g_malloc() friends
Daniel P. Berrange berra...@redhat.com writes:
On Tue, Nov 08, 2011 at 10:55:52AM +0100, Markus Armbruster wrote:
Fixes protocol_client_auth_sasl_mechname() not to crash when malloc()
fails. Spotted by Coverity.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
ui/vnc-auth-sasl.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
index 23b1bf5..a88973b 100644
--- a/ui/vnc-auth-sasl.c
+++ b/ui/vnc-auth-sasl.c
@@ -35,7 +35,7 @@ void vnc_sasl_client_cleanup(VncState *vs)
vs-sasl.encodedLength = vs-sasl.encodedOffset = 0;
vs-sasl.encoded = NULL;
g_free(vs-sasl.username);
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.username = vs-sasl.mechlist = NULL;
sasl_dispose(vs-sasl.conn);
vs-sasl.conn = NULL;
@@ -430,7 +430,7 @@ static int protocol_client_auth_sasl_start_len(VncState
*vs, uint8_t *data, size
static int protocol_client_auth_sasl_mechname(VncState *vs, uint8_t *data,
size_t len)
{
-char *mechname = malloc(len + 1);
+char *mechname = g_malloc(len + 1);
if (!mechname) {
VNC_DEBUG(Out of memory reading mechname\n);
vnc_client_error(vs);
You can delete the if (!mechname) block now you have g_malloc
Should've seen that myself. Guess I stared at Coverity reports for too
long. I'll respin.
The reason for the crash on OOM is here, but the diff context doesn't show it:
Notice the missing 'return -1' statement following vnc_client_error(vs);
char *mechname = malloc(len + 1);
if (!mechname) {
VNC_DEBUG(Out of memory reading mechname\n);
vnc_client_error(vs);
}
strncpy(mechname, (char*)data, len);
mechname[len] = '\0';
Correct.
@@ -460,7 +460,7 @@ static int protocol_client_auth_sasl_mechname(VncState
*vs, uint8_t *data, size_
}
}
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.mechlist = mechname;
VNC_DEBUG(Validated mechname '%s'\n, mechname);
@@ -469,7 +469,7 @@ static int protocol_client_auth_sasl_mechname(VncState
*vs, uint8_t *data, size_
fail:
vnc_client_error(vs);
-free(mechname);
+g_free(mechname);
return -1;
}
@@ -608,7 +608,7 @@ void start_auth_sasl(VncState *vs)
}
VNC_DEBUG(Available mechanisms for client: '%s'\n, mechlist);
-if (!(vs-sasl.mechlist = strdup(mechlist))) {
+if (!(vs-sasl.mechlist = g_strdup(mechlist))) {
VNC_DEBUG(Out of memory);
sasl_dispose(vs-sasl.conn);
vs-sasl.conn = NULL;
Again, you can delete the conditional here with g_strdup
Yes.
Thanks!
Re: [Qemu-devel] [PATCH] ui/vnc: Convert sasl.mechlist to g_malloc() friends
On Tue, Nov 08, 2011 at 10:55:52AM +0100, Markus Armbruster wrote: Fixes protocol_client_auth_sasl_mechname() not to crash when malloc() fails. Spotted by Coverity. Signed-off-by: Markus Armbruster arm...@redhat.com --- ui/vnc-auth-sasl.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) g_malloc(), the allocator the never* fails. * Or if it does you won't be around to care about it ;-) Thanks, merged into the trivial-patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Stefan
Re: [Qemu-devel] [PATCH] qdev: Fix crash on -device '?=x'
On Tue, Nov 08, 2011 at 11:00:38AM +0100, Markus Armbruster wrote: Spotted by Coverity. Signed-off-by: Markus Armbruster arm...@redhat.com --- hw/qdev.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Thanks, applied to the trivial patches tree: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches Stefan
Re: [Qemu-devel] [PATCH] Support for UDP unicast network backend
On 2011-11-07 23:03, Benjamin wrote:
On 11/07/11 12:23, Jan Kiszka wrote:
On 2011-11-07 15:01, Benjamin wrote:
Here is the updated patch, using only localaddr. mcast expects it to be
addr whereas udp expects addr:port. It's documented in the help output.
I also corrected the error message when checking udp parameters.
Sorry, missed that: please never forget to run your patches through
checkpatch.pl. Once fixed, consider this
Acked-by: Jan Kiszkajan.kis...@siemens.com
Oh, my bad, I happen to have copied some parts from net/socket.c
that do no respect the coding style requirements. Well I guess I know
what my next submission will be.
Fixed, it's my first time submitting a patch here, is this enough?
Yep.
Jan
Support for UDP unicast network backend
Signed-off-by: Benjamin MARSILI marsi...@epitech.eu
Acked-by: Jan Kiszka jan.kis...@siemens.com
---
net.c |9 +-
net/socket.c| 71
+-
qemu-options.hx |2 +
3 files changed, 78 insertions(+), 4 deletions(-)
diff --git a/net.c b/net.c
index cb52050..c75be08 100644
--- a/net.c
+++ b/net.c
@@ -999,7 +999,11 @@ static const struct {
}, {
.name = localaddr,
.type = QEMU_OPT_STRING,
-.help = source address for multicast packets,
+.help = source address and port for multicast and udp
packets,
+}, {
+.name = udp,
+.type = QEMU_OPT_STRING,
+.help = UDP unicast address and port number,
},
{ /* end of list */ }
},
@@ -1070,7 +1074,8 @@ int net_client_init(Monitor *mon, QemuOpts *opts,
int is_netdev)
#ifdef CONFIG_VDE
strcmp(type, vde) != 0
#endif
-strcmp(type, socket) != 0) {
+strcmp(type, socket) != 0
+strcmp(type, udp) != 0) {
qerror_report(QERR_INVALID_PARAMETER_VALUE, type,
a netdev backend type);
return -1;
diff --git a/net/socket.c b/net/socket.c
index e9ef128..ca183f2 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -524,6 +524,55 @@ static int net_socket_mcast_init(VLANState *vlan,
}
+static int net_socket_udp_init(VLANState *vlan,
+ const char *model,
+ const char *name,
+ const char *rhost,
+ const char *lhost)
+{
+NetSocketState *s;
+int fd, val, ret;
+struct sockaddr_in laddr, raddr;
+
+if (parse_host_port(laddr, lhost) 0) {
+return -1;
+}
+
+if (parse_host_port(raddr, rhost) 0) {
+return -1;
+}
+
+fd = qemu_socket(PF_INET, SOCK_DGRAM, 0);
+if (fd 0) {
+perror(socket(PF_INET, SOCK_DGRAM));
+return -1;
+}
+val = 1;
+ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
+ (const char *)val, sizeof(val));
+if (ret 0) {
+perror(setsockopt(SOL_SOCKET, SO_REUSEADDR));
+return -1;
+}
+ret = bind(fd, (struct sockaddr *)laddr, sizeof(laddr));
+if (ret 0) {
+perror(bind);
+return -1;
+}
+
+s = net_socket_fd_init(vlan, model, name, fd, 0);
+if (!s) {
+return -1;
+}
+
+s-dgram_dst = raddr;
+
+snprintf(s-nc.info_str, sizeof(s-nc.info_str),
+ socket: udp=%s:%d,
+ inet_ntoa(raddr.sin_addr), ntohs(raddr.sin_port));
+return 0;
+}
+
int net_init_socket(QemuOpts *opts,
Monitor *mon,
const char *name,
@@ -597,10 +646,28 @@ int net_init_socket(QemuOpts *opts,
if (net_socket_mcast_init(vlan, socket, name, mcast,
localaddr) == -1) {
return -1;
}
+} else if (qemu_opt_get(opts, udp)) {
+const char *udp, *localaddr;
+
+if (qemu_opt_get(opts, fd) ||
+qemu_opt_get(opts, connect) ||
+qemu_opt_get(opts, listen) ||
+qemu_opt_get(opts, mcast)) {
+error_report(fd=, connect=, listen=\
+ and mcast= is invalid with udp=);
+return -1;
+}
+
+udp = qemu_opt_get(opts, udp);
+localaddr = qemu_opt_get(opts, localaddr);
+
+if (net_socket_udp_init(vlan, udp, name, udp, localaddr) ==
-1) {
+return -1;
+}
} else {
-error_report(-socket requires fd=, listen=, connect= or mcast=);
+error_report(-socket requires fd=, listen=, \
+ connect=, mcast= or udp=);
return -1;
}
-
return 0;
}
diff --git a/qemu-options.hx b/qemu-options.hx
index 681eaf1..5495368 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1217,6 +1217,8 @@ DEF(net, HAS_ARG, QEMU_OPTION_net,
-net
Re: [Qemu-devel] [PATCH V3] Introduce a new bus ICC to connect APIC
On 2011-11-08 02:44, liu ping fan wrote:
On Sun, Nov 06, 2011 at 07:06:29PM +0100, Jan Kiszka wrote:
On 2011-11-03 10:30, pingf...@linux.vnet.ibm.com wrote:
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
Introduce a new structure CPUS as the controller of ICC (INTERRUPT
CONTROLLER COMMUNICATIONS), and new bus ICC to hold APIC,instead
of sysbus. So we can support APIC hot-plug feature.
Signed-off-by: liu ping fan pingf...@linux.vnet.ibm.com
---
Makefile.target |1 +
hw/apic.c | 24 +
hw/apic.h |1 +
hw/icc_bus.c| 92
+++
hw/icc_bus.h| 61 +
hw/pc.c |9 +++--
hw/pc_piix.c| 14 +++-
target-i386/cpu.h |1 +
target-i386/cpuid.c | 16 +
9 files changed, 207 insertions(+), 12 deletions(-)
create mode 100644 hw/icc_bus.c
create mode 100644 hw/icc_bus.h
diff --git a/Makefile.target b/Makefile.target
index 9011f28..5607c6d 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -241,6 +241,7 @@ obj-i386-$(CONFIG_KVM) += kvmclock.o
obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
obj-i386-y += testdev.o
obj-i386-y += acpi.o acpi_piix4.o
+obj-i386-y += icc_bus.o
obj-i386-y += pcspk.o i8254.o
obj-i386-$(CONFIG_KVM_PIT) += i8254-kvm.o
diff --git a/hw/apic.c b/hw/apic.c
index 69d6ac5..34fa1dd 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -21,9 +21,10 @@
#include ioapic.h
#include qemu-timer.h
#include host-utils.h
-#include sysbus.h
+#include icc_bus.h
#include trace.h
#include kvm.h
+#include exec-memory.h
/* APIC Local Vector Table */
#define APIC_LVT_TIMER 0
@@ -80,7 +81,7 @@
typedef struct APICState APICState;
struct APICState {
-SysBusDevice busdev;
+ICCBusDevice busdev;
MemoryRegion io_memory;
void *cpu_env;
uint32_t apicbase;
@@ -1104,9 +1105,19 @@ static const MemoryRegionOps apic_io_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
-static int apic_init1(SysBusDevice *dev)
+int apic_mmio_map(DeviceState *dev, target_phys_addr_t base)
{
-APICState *s = FROM_SYSBUS(APICState, dev);
+APICState *s = DO_UPCAST(APICState, busdev.qdev, dev);
+
+memory_region_add_subregion(get_system_memory(),
+base,
+s-io_memory);
+return 0;
+}
+
+static int apic_init1(ICCBusDevice *dev)
+{
+APICState *s = DO_UPCAST(APICState, busdev, dev);
static int last_apic_idx;
if (last_apic_idx = MAX_APICS) {
@@ -1114,7 +1125,6 @@ static int apic_init1(SysBusDevice *dev)
}
memory_region_init_io(s-io_memory, apic_io_ops, s, apic,
MSI_ADDR_SIZE);
-sysbus_init_mmio_region(dev, s-io_memory);
s-timer = qemu_new_timer_ns(vm_clock, apic_timer, s);
s-idx = last_apic_idx++;
@@ -1122,7 +1132,7 @@ static int apic_init1(SysBusDevice *dev)
return 0;
}
-static SysBusDeviceInfo apic_info = {
+static ICCBusDeviceInfo apic_info = {
.init = apic_init1,
.qdev.name = apic,
.qdev.size = sizeof(APICState),
@@ -1138,7 +1148,7 @@ static SysBusDeviceInfo apic_info = {
static void apic_register_devices(void)
{
-sysbus_register_withprop(apic_info);
+iccbus_register_devinfo(apic_info);
}
device_init(apic_register_devices)
diff --git a/hw/apic.h b/hw/apic.h
index c857d52..e2c0af5 100644
--- a/hw/apic.h
+++ b/hw/apic.h
@@ -20,6 +20,7 @@ void cpu_set_apic_tpr(DeviceState *s, uint8_t val);
uint8_t cpu_get_apic_tpr(DeviceState *s);
void apic_init_reset(DeviceState *s);
void apic_sipi(DeviceState *s);
+int apic_mmio_map(DeviceState *dev, target_phys_addr_t base);
/* pc.c */
int cpu_is_bsp(CPUState *env);
diff --git a/hw/icc_bus.c b/hw/icc_bus.c
new file mode 100644
index 000..ac88f2e
--- /dev/null
+++ b/hw/icc_bus.c
@@ -0,0 +1,92 @@
+/* icc_bus.c
+ * emulate x86 ICC(INTERRUPT CONTROLLER COMMUNICATIONS) bus
+ *
+ * Copyright IBM, Corp. 2011
+ *
+ * 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 icc_bus.h
+
+static CPUSockets *cpu_sockets;
+
+static ICCBusInfo icc_bus_info = {
+.qinfo.name = icc,
+.qinfo.size = sizeof(ICCBus),
+.qinfo.props =
Re: [Qemu-devel] Accessing a linux guest's data structures
Thanks for the suggestions, guys! I will take a look at libvmi. As an aside, can someone tell me where in the qemu source can I inspect each guest instruction? I want all guest instructions to first go through my code. For i386 guest, see disas_insn (target-i386/translate.c). It disassembles i386 guest binary. QEMU provides -d in_asm option to log every guest instruction it translates. You might want to take a look on qemu_log. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility
On Tue, 8 Nov 2011, Theodore Tso wrote: It's great to hear that! But in that case, there's an experiment we can't really run, which is if perf had been developed in a separate tree, would it have been just as successful? Experiment, eh? We have the staging tree because it's a widely acknowledged belief that kernel code in the tree tends to improve over time compared to code that's sitting out of the tree. Are you disputing that belief? If you don't dispute that, what makes you think the same effect doesn't apply to code that looks like Linux code and is developed the same way but runs in userspace? Pekka
[Qemu-devel] [Bug 887516] [NEW] VFP support reported for the PXA270
Public bug reported: The HWCAPS seems to be broken on PXA, because sigsetjmp of eglibc-2.14 chooses a VFP code path after the hwcaps test [1][2] which causes a SIGILL on a VSTM instruction. How to reproduce: 1. build an arm-linux-gnueabi toolchain with eglibc-2.14 2. compile a trivial main() 3. run it with qemu-arm -cpu pxa270 Host: Debian Testing 64bit, 3.0 kernel Command line: ~/bin/qemu/bin/qemu-arm -cpu pxa270 -L ~/bin/arm-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot ./test2 Qemu version: git 1d769ceda65eef76bad3356f5b7b0ce8a61e5d76 [1] http://cygwin.com/ml/crossgcc/2011-11/msg00016.html [2] http://cygwin.com/ml/crossgcc/2011-11/msg00019.html ** 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/887516 Title: VFP support reported for the PXA270 Status in QEMU: New Bug description: The HWCAPS seems to be broken on PXA, because sigsetjmp of eglibc-2.14 chooses a VFP code path after the hwcaps test [1][2] which causes a SIGILL on a VSTM instruction. How to reproduce: 1. build an arm-linux-gnueabi toolchain with eglibc-2.14 2. compile a trivial main() 3. run it with qemu-arm -cpu pxa270 Host: Debian Testing 64bit, 3.0 kernel Command line: ~/bin/qemu/bin/qemu-arm -cpu pxa270 -L ~/bin/arm-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot ./test2 Qemu version: git 1d769ceda65eef76bad3356f5b7b0ce8a61e5d76 [1] http://cygwin.com/ml/crossgcc/2011-11/msg00016.html [2] http://cygwin.com/ml/crossgcc/2011-11/msg00019.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/887516/+subscriptions
Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility
On Nov 8, 2011, at 6:20 AM, Pekka Enberg wrote: We have the staging tree because it's a widely acknowledged belief that kernel code in the tree tends to improve over time compared to code that's sitting out of the tree. Are you disputing that belief? Kernel code in the kernel source tree improves; because that's where it will eventually end up --- linked against the kernel. There are all sorts of dynamics in play that don't necessarily apply to userspace code. Otherwise we could just link in all of the userspace code in a Linux distribution and magically expect it will get better, eh? Not! -- Ted
Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility
On Tue, 8 Nov 2011, Theodore Tso wrote: We have the staging tree because it's a widely acknowledged belief that kernel code in the tree tends to improve over time compared to code that's sitting out of the tree. Are you disputing that belief? Kernel code in the kernel source tree improves; because that's where it will eventually end up --- linked against the kernel. There are all sorts of dynamics in play that don't necessarily apply to userspace code. Otherwise we could just link in all of the userspace code in a Linux distribution and magically expect it will get better, eh? Not! You just yourself said it's about the people. Why do you now think it's about linking against the kernel? I know I have hacked on various parts of the kernel that I have never linked to my kernel. Pekka
Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility
Hi - On Tue, Nov 08, 2011 at 11:22:35AM +0100, Ingo Molnar wrote: [...] These examples show *PICTURE PERFECT* forwards ABI compatibility, using the ancient perf tool on a bleeding edge kernel. [...] Almost: they demonstrate that those parts of the ABI that these particular perf commands rely on have been impressively compatible. Do you have any sort of ABI coverage measurement, to see what parts of the ABI these perf commands do not use? - FChE
Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility
* Peter Zijlstra a.p.zijls...@chello.nl wrote: The ABI yes, the tool no, the tool very much relies on some newer ABI parts. Supporting fallbacks isn't always possible/wanted. Yeah, sure - and an older tool cannot possibly support newer features either. Thanks, Ingo
Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility
On Tue, 8 Nov 2011, Frank Ch. Eigler wrote: Almost: they demonstrate that those parts of the ABI that these particular perf commands rely on have been impressively compatible. Do you have any sort of ABI coverage measurement, to see what parts of the ABI these perf commands do not use? It's pretty obvious that perf ABI is lacking on that department based on Vince's comments, isn't it? There's an easy fix for this too: improve perf test to cover the cases you're intested in. While ABI spec would be a nice addition, it's not going to make compatibility problems magically go away. Pekka
[Qemu-devel] multiprocessor on kvm
I am wondering that when one uses qemu with kvm. How many cores are exposed and available to the guest os ( assuming the host has 4 cores ). is this configurable ? Thanks Xin
Re: [Qemu-devel] [PATCH] qmp: add test tool for QMP
On Tue, 08 Nov 2011 16:36:55 +0800
Mark Wu wu...@linux.vnet.ibm.com wrote:
When I run this tool, I got two python exceptions. It turned out that
both of them were caused by wrong usage. Do you think we need add
validation for input to handle these cases?
Yes.
Thanks.
1. Not using '=' for path:
$ ./QMP/qmp --path monitor-address
Traceback (most recent call last):
File ./QMP/qmp, line 120, in module
sys.exit(main(sys.argv[1:]))
File ./QMP/qmp, line 71, in main
srv.connect()
File /home/mark/work/source/qemu/QMP/qmp.py, line 85, in connect
self.__sock.connect(self.__address)
File string, line 1, in connect
TypeError: argument must be string or read-only character buffer, not bool
Proposed patch:
@@ -48,7 +48,8 @@ def main(args):
arg, value = arg.split('=', 1)
if arg in ['path']:
-path = value
+ if isinstance(value, basestring):
+path = value
2. No qmp comand given in command line
$ ./QMP/qmp --path=monitor-address
Traceback (most recent call last):
File ./QMP/qmp, line 120, in module
sys.exit(main(sys.argv[1:]))
File ./QMP/qmp, line 65, in main
command, args = args[0], args[1:]
IndexError: list index out of range
@@ -62,11 +63,17 @@ def main(args):
print QMP path isn't set, use --path or set QMP_PATH
return 1
Proposed patch:
-command, args = args[0], args[1:]
+if len(args):
+ command, args = args[0], args[1:]
+else:
+ print 'No command found'
+ print 'Usage: qmp [--path=monitor-address] qmp-cmd arguments'
+ return 1
On 11/07/2011 11:11 PM, Anthony Liguori wrote:
I wrote this quickly to aid in testing. It's similar to qmp-shell with a
few
important differences:
1) It is not interactive. That makes it useful for scripting.
2) qmp-shell:
(QEMU) set_password protocol=vnc password=foo
3) qmp:
$ qmp set_password --protocol=vnc --password=foo
4) Extensible, git-style interface. If an invalid command name is passed,
it
will try to exec qmp-$1.
5) It attempts to pretty print the JSON responses in a shell friendly format
such that tools can work with the output.
Hope others will also find it useful.
Signed-off-by: Anthony Liguorialigu...@us.ibm.com
---
QMP/qmp | 120
+++
1 files changed, 120 insertions(+), 0 deletions(-)
create mode 100755 QMP/qmp
diff --git a/QMP/qmp b/QMP/qmp
new file mode 100755
index 000..7b2a3c7
--- /dev/null
+++ b/QMP/qmp
@@ -0,0 +1,120 @@
+#!/usr/bin/python
+#
+# QMP command line tool
+#
+# Copyright IBM, Corp. 2011
+#
+# Authors:
+# Anthony Liguorialigu...@us.ibm.com
+#
+# This work is licensed under the terms of the GNU GPLv2 or later.
+# See the COPYING file in the top-level directory.
+
+import sys, os
+from qmp import QEMUMonitorProtocol
+
+def print_response(rsp, prefix=[]):
+if type(rsp) == list:
+i = 0
+for item in rsp:
+if prefix == []:
+prefix = ['item']
+print_response(item, prefix[:-1] + ['%s[%d]' % (prefix[-1],
i)])
+i += 1
+elif type(rsp) == dict:
+for key in rsp.keys():
+print_response(rsp[key], prefix + [key])
+else:
+if len(prefix):
+print '%s: %s' % ('.'.join(prefix), rsp)
+else:
+print '%s' % (rsp)
+
+def main(args):
+path = None
+
+# Use QMP_PATH if it's set
+if os.environ.has_key('QMP_PATH'):
+path = os.environ['QMP_PATH']
+
+while len(args):
+arg = args[0]
+
+if arg.startswith('--'):
+arg = arg[2:]
+if arg.find('=') == -1:
+value = True
+else:
+arg, value = arg.split('=', 1)
+
+if arg in ['path']:
+path = value
+elif arg in ['help']:
+os.execlp('man', 'man', 'qmp')
+else:
+print 'Unknown argument %s' % arg
+
+args = args[1:]
+else:
+break
+
+if not path:
+print QMP path isn't set, use --path or set QMP_PATH
+return 1
+
+command, args = args[0], args[1:]
+
+if command in ['help']:
+os.execlp('man', 'man', 'qmp')
+
+srv = QEMUMonitorProtocol(path)
+srv.connect()
+
+def do_command(srv, cmd, **kwds):
+rsp = srv.cmd(cmd, kwds)
+if rsp.has_key('error'):
+raise Exception(rsp['error']['desc'])
+return rsp['return']
+
+commands = map(lambda x: x['name'], do_command(srv, 'query-commands'))
+
+srv.close()
+
+if command not in commands:
+fullcmd
Re: [Qemu-devel] multiprocessor on kvm
I am wondering that when one uses qemu with kvm. How many cores are exposed and available to the guest os ( assuming the host has 4 cores ). is this configurable ? QEMU provides -smp option, but those virtual cpus are scheduled in round-robin fashion. In other words, it's not real parallelism. I don't know if there is any difference with kvm enabled. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
* Vince Weaver vi...@deater.net wrote: On Mon, 7 Nov 2011, Ingo Molnar wrote: I think we needed to do only one revert along the way in the past two years, to fix an unintended ABI breakage in PowerTop. Considering the total complexity of the perf ABI our compatibility track record is *very* good. There have been more breakages, as you know. It's just they weren't caught in time so they were declared to be grandfathered in rather than fixed. I remember one such instance were you reported a 'regression' that spanned several -stable kernel releases - and unless the fix is easy and obvious that's the regular upstream treatment. As Linus said it too on the recent Kernel Summit an ABI is only an ABI if it's actually *used*. But there's more, you've repeatedly rejected our offer to extend 'perf test' to cover the functionality that your library relies on. If you refuse to timely test newer upstream kernels while you rely on obscure details that nobody else uses and if you refuse to make your testcases more prominent it becomes *your* problem. There's not much we can do if you refuse to test and refuse to push your testcases upstream ... ... and you have argued against perf from the very first day on, when you were one of the perfmon developers - and IMO in hindsight you've been repeatedly wrong about most of your design arguments. I can't find an exact e-mail, but I seem to recall my arguments were that Pentium 4 support would be hard (it was), [...] To the contrary, a single person implemented most of it, out of curiosity. [...] that in-kernel generalized events were a bad idea (I still think that, try talking to the ARM guys sometime about that) [...] To the contrary, generalized events work very well and they are one of the reasons why the perf tooling is so usable. [...] and that making access to raw events hard (by not using a naming library) was silly. [...] To the contrary, by 'making it easy' you mean 'translate hexa codes to vendor specific gibberish' which is hardly any better to actual users of the tool and gives the false appearance of being a solution. All in one you advocated all the oprofile design mistakes and you have been proven thoroughly wrong by reality. The PAPI project has the (fundamental) problem that you are still doing it in the old-style sw design fashion, with many months long delays in testing, and then you are blaming the problems you inevitably meet with that model on *us*. The fundamental problem with the PAPI project is that we only have 3 full-time developers, and we have to make sure PAPI runs on about 10 different platforms, of which perf_events/Linux is only one. Time I waste tracking down perf_event ABI regressions and DoS bugs takes away from actual useful userspace PAPI development. If people are not interested in even testing the basic test-suite of PAPI on a recent kernel then i'm afraid there must be something very wrong with the PAPI project structure. Somehow that testing is not missing from the perf tool, despite it being a much younger and smaller project. Did you ever stop to think why that is so? There was one PAPI incident i remember where it took you several *months* to report a regression in a regular PAPI test-case (no actual app affected as far as i know). No other tester ever ran the PAPI testcases so nobody else reported it. We have a huge userbase. They run on some pretty amazing machines and do some tests that strain perf libraries to the limit. They also tend to use distro kernels, assuming they even have moved to 2.6.31+ kernels yet. When these power users report problems, they aren't going to be against the -tip tree. Nobody expects you to test the -tip tree if you don't want to (it would certainly be useful to you if you are interested in PMU development), but there's a 2.5 months stabilization window after the upstream merge. Nobody but you tests PAPI so you need to become *part* of the upstream development process, which releases a new upstream kernel every 3 months. PAPI is a free software project, with the devel tree available from CVS. It takes maybe 15 minutes to run the full PAPI regression suite. I encourage you or any perf developer to try it and report any issues. I will fix what gets reported and neither i nor other regular kernel testers actually use it. You really need to do more testing to fill that gap, expecting others to volunteer time into a project they don't actually use is extremely backwards... I can only be so comprehensive. I didn't find the current NMI-watchdog regression right away because my git tree builds didn't have it enabled. It wasn't until there started being 3.0 distro kernels that people started reporting the problem to us. Also, as i mentioned it several times before, you are free to add an arbitrary number of ABI test-cases to 'perf test' and we can
Re: [Qemu-devel] multiprocessor on kvm
On Tue, Nov 08, 2011 at 08:04:44PM +0800, 陳韋任 wrote: I am wondering that when one uses qemu with kvm. How many cores are exposed and available to the guest os ( assuming the host has 4 cores ). is this configurable ? QEMU provides -smp option, but those virtual cpus are scheduled in round-robin fashion. In other words, it's not real parallelism. I don't know if there is any difference with kvm enabled. IIRC, kvm uses QEMU for device emulation only. Those virtual cpus are ran on physical cpus simultaneously. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState
On 8 November 2011 06:33, Avi Kivity a...@redhat.com wrote:
On 11/08/2011 04:07 AM, Peter Maydell wrote:
2011/10/26 Peter Maydell peter.mayd...@linaro.org:
On 25 October 2011 12:09, Benoît Canet benoit.ca...@gmail.com wrote:
+static const VMStateDescription vmstate_integratorcm = {
+ .name = integratorcm,
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .minimum_version_id_old = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_UINT32(memsz, integratorcm_state),
+ VMSTATE_BOOL(flash_mapped, integratorcm_state),
This raises a question. flash_mapped here is a flag which just
tracks whether the associated MemoryRegion is currently mapped
or unmapped. Do we need to do anything special to ensure that
the MemoryRegion itself is reset to the correct mapped/unmapped
state on restore?
I recall discussing this kind of thing with Avi on IRC but I
can't remember what the conclusion was.
Avi, ping? I'm still interested in the answer to this question.
Sorry, missed this. Yes, you need to ensure the memory region mapping
reflects flash_mapped.
This needs to be in the MemoryRegion core implementation, please.
I don't want to have to redo it for every device that has a
remappable region. In particular, at the moment memory.c's
add/delete region functions will assert if the region was already
added/deleted, which means the device has to keep track in a
not-vm-saved state flag whether the memory was mapped so it can
resync things on load (by comparing the non-saved flag and the
saved-state).
Ideally memory.c should just ensure that the memory hierarchy
is saved and restored without devices having to do anything.
btw, is flash_mapped a real device state (corresponds to a real memory
bit on the device) or just an artefact? It's usually a bad idea to cast
implementation artefacts in vmstate concrete.
It's an implementation artefact that you introduced when you
did the memoryregion conversion :-)
I have a half-a-patch to fix that lurking somewhere but it
stalled because at the moment the non-saved flag is required
in order to work around memory.c being unhelpful.
-- PMM
Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState
2011/11/8 Benoît Canet benoit.ca...@gmail.com: flash_mapped reflect the bit 2 of a control register. Peter, does this patch look better ? See my reply to Avi; I'd rather we fixed the MemoryRegion API rather than working around it in devices with postload hooks. thanks -- PMM
Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility
* Pekka Enberg penb...@cs.helsinki.fi wrote: [...] There's an easy fix for this too: improve perf test to cover the cases you're intested in. While ABI spec would be a nice addition, it's not going to make compatibility problems magically go away. Yes, exactly - 'perf test' has been written with that exact purpose. In practice 'perf' will cover almost all parts of the ABI. The one notable thing that isnt being tested in a natural way is the 'group of events' abstraction - which, ironically, has been added on the perfmon guys' insistence. No app beyond the PAPI self-test makes actual use of it though, which results in an obvious lack of testing. Vince: the code is in tools/perf/builtin-test.c and our offer still stands, feel free to extend it. Maybe there's some other volunteer willing to do that? Thanks, Ingo
Re: [Qemu-devel] [Qemu-trivial] [PATCH] arm: Fix CP15 FSR (C5) domain setting
On 8 November 2011 10:44, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Nov 04, 2011 at 09:50:25PM +0100, Jean-Christophe DUBOIS wrote: During Xvisor development, it was noted that qemu did not return the correct domain value in the Cp15 [Data] FSR register (C5). This patch is a proposal to fix it. Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net --- CCed Peter Maydell so this can go through the ARM tree. This is an old and broken version of a patch which I've already reviewed the fixed version of -- you can ignore this one. -- PMM
Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility
On Tue, 2011-11-08 at 13:15 +0100, Ingo Molnar wrote: The one notable thing that isnt being tested in a natural way is the 'group of events' abstraction - which, ironically, has been added on the perfmon guys' insistence. No app beyond the PAPI self-test makes actual use of it though, which results in an obvious lack of testing. Also the self monitor stuff, perf-tool doesn't use that for obvious reasons.
Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState
On 11/08/2011 02:15 PM, Peter Maydell wrote: Avi, ping? I'm still interested in the answer to this question. Sorry, missed this. Yes, you need to ensure the memory region mapping reflects flash_mapped. This needs to be in the MemoryRegion core implementation, please. Right; see the memory/mutators branch. I plan to push this as soon as everything is converted. I don't want to have to redo it for every device that has a remappable region. In particular, at the moment memory.c's add/delete region functions will assert if the region was already added/deleted, which means the device has to keep track in a not-vm-saved state flag whether the memory was mapped so it can resync things on load (by comparing the non-saved flag and the saved-state). Ideally memory.c should just ensure that the memory hierarchy is saved and restored without devices having to do anything. That's a bit far-fetched - I don't want the memory core involved in save/restore. But if/when we integrate the memory core into QOM, then yes, that layer can take care of it. If we have an observable attribute (that fires off a callback when changed), we can link memory API properties into that attribute. btw, is flash_mapped a real device state (corresponds to a real memory bit on the device) or just an artefact? It's usually a bad idea to cast implementation artefacts in vmstate concrete. It's an implementation artefact that you introduced when you did the memoryregion conversion :-) I have a half-a-patch to fix that lurking somewhere but it stalled because at the moment the non-saved flag is required in order to work around memory.c being unhelpful. Ideally we'd have a way to separate implementation state from real state (after working hard to eliminate implementation state). -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] multiprocessor on kvm
On Tue, Nov 8, 2011 at 12:10 PM, 陳韋任 che...@iis.sinica.edu.tw wrote: On Tue, Nov 08, 2011 at 08:04:44PM +0800, 陳韋任 wrote: I am wondering that when one uses qemu with kvm. How many cores are exposed and available to the guest os ( assuming the host has 4 cores ). is this configurable ? QEMU provides -smp option, but those virtual cpus are scheduled in round-robin fashion. In other words, it's not real parallelism. I don't know if there is any difference with kvm enabled. IIRC, kvm uses QEMU for device emulation only. Those virtual cpus are ran on physical cpus simultaneously. Right, qemu -enable-kvm will run a thread for each vCPU. So you get true SMP parallelism. QEMU without KVM mode, on the other hand, does round-robin scheduling of vCPUs and does not take advantage of multiprocessor hosts. Stefan
Re: [Qemu-devel] [PATCH] ui/vnc: Convert sasl.mechlist to g_malloc() friends
On Tue, Nov 8, 2011 at 10:49 AM, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Nov 08, 2011 at 10:55:52AM +0100, Markus Armbruster wrote: Fixes protocol_client_auth_sasl_mechname() not to crash when malloc() fails. Spotted by Coverity. Signed-off-by: Markus Armbruster arm...@redhat.com --- ui/vnc-auth-sasl.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) Thanks, merged into the trivial-patches tree: I'll grab the new version when it comes out. Stefan
Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState
On 8 November 2011 12:21, Avi Kivity a...@redhat.com wrote: On 11/08/2011 02:15 PM, Peter Maydell wrote: This needs to be in the MemoryRegion core implementation, please. Right; see the memory/mutators branch. I plan to push this as soon as everything is converted. OK, then this save/restore patch should wait until that has landed. Ideally memory.c should just ensure that the memory hierarchy is saved and restored without devices having to do anything. That's a bit far-fetched - I don't want the memory core involved in save/restore. But if/when we integrate the memory core into QOM, then yes, that layer can take care of it. If we have an observable attribute (that fires off a callback when changed), we can link memory API properties into that attribute. The memory hierarchy is a visible part of the state which can change as the guest does things -- it has to get saved and restored somehow. I think it would be better done in the core where it will always be done right, rather than relying on each device to handle it correctly (especially since it's not always obvious if it's been missed out from the device.) -- PMM
Re: [Qemu-devel] multiprocessor on kvm
so qemu exposes multiple processors to the guest os by having multiple vCPUs. and it realizes the multiple vCPUs by either using RR on a single host cpu (qemu ) or using multiple host cpus (kvm). Thanks Xin 2011/11/8 Stefan Hajnoczi stefa...@gmail.com: On Tue, Nov 8, 2011 at 12:10 PM, 陳韋任 che...@iis.sinica.edu.tw wrote: On Tue, Nov 08, 2011 at 08:04:44PM +0800, 陳韋任 wrote: I am wondering that when one uses qemu with kvm. How many cores are exposed and available to the guest os ( assuming the host has 4 cores ). is this configurable ? QEMU provides -smp option, but those virtual cpus are scheduled in round-robin fashion. In other words, it's not real parallelism. I don't know if there is any difference with kvm enabled. IIRC, kvm uses QEMU for device emulation only. Those virtual cpus are ran on physical cpus simultaneously. Right, qemu -enable-kvm will run a thread for each vCPU. So you get true SMP parallelism. QEMU without KVM mode, on the other hand, does round-robin scheduling of vCPUs and does not take advantage of multiprocessor hosts. Stefan
Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState
On 11/08/2011 02:30 PM, Peter Maydell wrote: On 8 November 2011 12:21, Avi Kivity a...@redhat.com wrote: On 11/08/2011 02:15 PM, Peter Maydell wrote: This needs to be in the MemoryRegion core implementation, please. Right; see the memory/mutators branch. I plan to push this as soon as everything is converted. OK, then this save/restore patch should wait until that has landed. Please don't add interdependencies, especially as I can't promise a firm date as to when everything is converted (however I'll take this opportunity to remind you that patches, especially for omap, are more welcome than I can possibly articulate). Ideally memory.c should just ensure that the memory hierarchy is saved and restored without devices having to do anything. That's a bit far-fetched - I don't want the memory core involved in save/restore. But if/when we integrate the memory core into QOM, then yes, that layer can take care of it. If we have an observable attribute (that fires off a callback when changed), we can link memory API properties into that attribute. The memory hierarchy is a visible part of the state which can change as the guest does things -- it has to get saved and restored somehow. I think it would be better done in the core where it will always be done right, rather than relying on each device to handle it correctly (especially since it's not always obvious if it's been missed out from the device.) We agree, the only difference is in what core refers to. I don't want memory.c do become intermingled with everything else. It should be in a separate layer. Devices would then talk to this layer, and not to the gluing by themselves as they have to now. Or maybe memory.c will be layered on top of QOM, and then it can take care of everything. I really don't know QOM well enough to say. Copying Anthony for more insight. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH v2] ui/vnc: Convert sasl.mechlist to g_malloc() friends
Fixes protocol_client_auth_sasl_mechname() not to crash when malloc()
fails. Spotted by Coverity.
---
ui/vnc-auth-sasl.c | 19 +--
1 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
index 23b1bf5..e2045fc 100644
--- a/ui/vnc-auth-sasl.c
+++ b/ui/vnc-auth-sasl.c
@@ -35,7 +35,7 @@ void vnc_sasl_client_cleanup(VncState *vs)
vs-sasl.encodedLength = vs-sasl.encodedOffset = 0;
vs-sasl.encoded = NULL;
g_free(vs-sasl.username);
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.username = vs-sasl.mechlist = NULL;
sasl_dispose(vs-sasl.conn);
vs-sasl.conn = NULL;
@@ -430,11 +430,7 @@ static int protocol_client_auth_sasl_start_len(VncState
*vs, uint8_t *data, size
static int protocol_client_auth_sasl_mechname(VncState *vs, uint8_t *data,
size_t len)
{
-char *mechname = malloc(len + 1);
-if (!mechname) {
-VNC_DEBUG(Out of memory reading mechname\n);
-vnc_client_error(vs);
-}
+char *mechname = g_malloc(len + 1);
strncpy(mechname, (char*)data, len);
mechname[len] = '\0';
VNC_DEBUG(Got client mechname '%s' check against '%s'\n,
@@ -460,7 +456,7 @@ static int protocol_client_auth_sasl_mechname(VncState *vs,
uint8_t *data, size_
}
}
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.mechlist = mechname;
VNC_DEBUG(Validated mechname '%s'\n, mechname);
@@ -469,7 +465,7 @@ static int protocol_client_auth_sasl_mechname(VncState *vs,
uint8_t *data, size_
fail:
vnc_client_error(vs);
-free(mechname);
+g_free(mechname);
return -1;
}
@@ -608,12 +604,7 @@ void start_auth_sasl(VncState *vs)
}
VNC_DEBUG(Available mechanisms for client: '%s'\n, mechlist);
-if (!(vs-sasl.mechlist = strdup(mechlist))) {
-VNC_DEBUG(Out of memory);
-sasl_dispose(vs-sasl.conn);
-vs-sasl.conn = NULL;
-goto authabort;
-}
+vs-sasl.mechlist = g_strdup(mechlist);
mechlistlen = strlen(mechlist);
vnc_write_u32(vs, mechlistlen);
vnc_write(vs, mechlist, mechlistlen);
--
1.7.6.4
Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState
On 8 November 2011 12:38, Avi Kivity a...@redhat.com wrote: On 11/08/2011 02:30 PM, Peter Maydell wrote: On 8 November 2011 12:21, Avi Kivity a...@redhat.com wrote: On 11/08/2011 02:15 PM, Peter Maydell wrote: This needs to be in the MemoryRegion core implementation, please. Right; see the memory/mutators branch. I plan to push this as soon as everything is converted. OK, then this save/restore patch should wait until that has landed. Please don't add interdependencies, especially as I can't promise a firm date as to when everything is converted (however I'll take this opportunity to remind you that patches, especially for omap, are more welcome than I can possibly articulate). I'm really not going to add workarounds for API deficiencies. Fortunately these devices (and omap_gpmc) don't have save/load already so nothing's going to be broken by that. -- PMM
Re: [Qemu-devel] [PATCH V3 07/10] Introduce Xen PCI Passthrough, qdevice (1/3)
On Fri, 28 Oct 2011, Anthony PERARD wrote:
From: Allen Kay allen.m@intel.com
Signed-off-by: Allen Kay allen.m@intel.com
Signed-off-by: Guy Zana g...@neocleus.com
Signed-off-by: Anthony PERARD anthony.per...@citrix.com
---
Makefile.target |2 +
hw/xen_pci_passthrough.c | 838
++
hw/xen_pci_passthrough.h | 223 ++
hw/xen_pci_passthrough_helpers.c | 46 ++
4 files changed, 1109 insertions(+), 0 deletions(-)
create mode 100644 hw/xen_pci_passthrough.c
create mode 100644 hw/xen_pci_passthrough.h
create mode 100644 hw/xen_pci_passthrough_helpers.c
diff --git a/Makefile.target b/Makefile.target
index 243f9f2..36ea47d 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -217,6 +217,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
# Xen PCI Passthrough
obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_helpers.o
# Inter-VM PCI shared memory
CONFIG_IVSHMEM =
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
new file mode 100644
index 000..b97c5b6
--- /dev/null
+++ b/hw/xen_pci_passthrough.c
@@ -0,0 +1,838 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik a...@neocleus.com
+ * Allen Kay allen.m@intel.com
+ * Guy Zana g...@neocleus.com
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ * Initialize(register_real_device)
+ * Map INTx(xc_physdev_map_pirq):
+ * fail
+ * - Set real Interrupt Disable bit to '1'.
+ * - Set machine_irq and assigned_device-machine_irq to '0'.
+ * * Don't bind INTx.
+ *
+ * Bind INTx(xc_domain_bind_pt_pci_irq):
+ * fail
+ * - Set real Interrupt Disable bit to '1'.
+ * - Unmap INTx.
+ * - Decrement mapped_machine_irq[machine_irq]
+ * - Set assigned_device-machine_irq to '0'.
+ *
+ * Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ * Write '0'
+ * ptdev-msi_trans_en is false
+ * - Set real bit to '0' if assigned_device-machine_irq isn't '0'.
+ *
+ * Write '1'
+ * ptdev-msi_trans_en is false
+ * - Set real bit to '1'.
+ *
+ * MSI-INTx translation.
+ * Initialize(xc_physdev_map_pirq_msi/pt_msi_setup)
+ * Bind MSI-INTx(xc_domain_bind_pt_irq)
+ * fail
+ * - Unmap MSI.
+ * success
+ * - Set dev-msi-pirq to '-1'.
+ * fail
+ * - Do nothing.
+ *
+ * Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ * Write '0'
+ * ptdev-msi_trans_en is true
+ * - Set MSI Enable bit to '1'.
+ *
+ * Write '1'
+ * ptdev-msi_trans_en is true
+ * - Set MSI Enable bit to '0'.
+ *
+ * MSI interrupt:
+ * Initialize MSI register(pt_msi_setup, pt_msi_update)
+ * Bind MSI(xc_domain_update_msi_irq)
+ * fail
+ * - Unmap MSI.
+ * - Set dev-msi-pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ * Initialize MSI-X register(pt_msix_update_one)
+ * Bind MSI-X(xc_domain_update_msi_irq)
+ * fail
+ * - Unmap MSI-X.
+ * - Set entry-pirq to '-1'.
+ */
+
you should move all the MSI related comments to the MSI patch
+#include sys/ioctl.h
+
+#include pci.h
+#include xen.h
+#include xen_backend.h
+#include xen_pci_passthrough.h
+
+#define PCI_BAR_ENTRIES (6)
+
+#define PT_NR_IRQS (256)
+char mapped_machine_irq[PT_NR_IRQS] = {0};
+
+/* Config Space */
+static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int
len)
+{
+/* check offset range */
+if (address = 0xFF) {
+PT_LOG(Error: Failed to access register with offset exceeding FFh.
+ [%02x:%02x.%x][Offset:%02xh][Length:%d]\n,
+ pci_bus_num(d-bus), PCI_SLOT(d-devfn), PCI_FUNC(d-devfn),
+ address, len);
+return -1;
+}
+
+/* check read size */
+if ((len != 1) (len != 2) (len != 4)) {
+PT_LOG(Error: Failed to access register with invalid access length.
+ [%02x:%02x.%x][Offset:%02xh][Length:%d]\n,
+ pci_bus_num(d-bus), PCI_SLOT(d-devfn), PCI_FUNC(d-devfn),
+ address, len);
+return -1;
+}
+
+/* check offset alignment */
+if (address (len - 1)) {
+PT_LOG(Error: Failed to access register with invalid access size
+alignment. [%02x:%02x.%x][Offset:%02xh][Length:%d]\n,
+pci_bus_num(d-bus), PCI_SLOT(d-devfn),
Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/
Em Tue, Nov 08, 2011 at 05:21:50AM -0500, Theodore Tso escreveu: On Nov 8, 2011, at 4:32 AM, Ingo Molnar wrote: No ifs and when about it, these are the plain facts: - Better features, better ABIs: perf maintainers can enforce clean, functional and usable tooling support *before* committing to an ABI on the kernel side. We don't have to be careful about breaking interface compatibility while we are developing new features. My normal working environment is an MRG PREEMPT_RT kernel (2.6.33.9, test kernels based on 3.0+) running on enterprise distros while I develop the userspace part. So no, at least for me, I don't keep updating the kernel part while developing userspace. The flip side of this is that it's not obvious when an interface is stable, and when it is still subject to change. It makes life much harder for any userspace code that doesn't live in the kernel. And I think we do agree that moving all of userspace into a single git tree makes no sense, right? Right, but that is the extreme as well, right? - We have a shared Git tree with unified, visible version control. I can see kernel feature commits followed by tooling support, in a single flow of related commits: perf probe: Update perf-probe document perf probe: Support --del option trace-kprobe: Support delete probe syntax With two separate Git repositories this kind of connection between the tool and the kernel is inevitably weakened or lost. We don't have to clearly document new interfaces between kernel and userspace, and instead rely on git commit order for people to figure out what's going on with some new interface Indeed, documentation is lacking, I think coming from a kernel standpoint I relied too much in the documentation is source code mantra of old days. But I realize its a necessity and also that regression testing is as well another necessity. I introduced 'perf test' for this later need and rejoice everytime people submit new test cases, like Jiri and Han did in the past, its just that we need more of both, documentation and regression testing. Unfortunately that is not so sexy and I have my hands full not just with perf :-\ - Easier development, easier testing: if you work on a kernel feature and on matching tooling support then it's *much* easier to work in a single tree than working in two or more trees in parallel. I have worked on multi-tree features before, and except special exceptions they are generally a big pain to develop. I've developed in the split tree systems, and it's really not that hard. It does mean you have to be explicit about designing interfaces up front, and then you have to have a good, robust way of negotiating what features are in the kernel, and what features are supposed by the userspace --- but if you don't do that then having good backwards and forwards compatibility between different versions of the tool simply doesn't exist. So at the end of the day it question is whether you want to be able to (for example) update e2fsck to get better ability to fix more file system corruptions, without needing to upgrade the kernel. If you want to be able to use a newer, better e2fsck with an older, enterprise kernel, then you have use certain programming disciplines. That's where the work is, not in whether you have to maintain two git trees or a single git tree. But it can as well be achieved with a single tree, or do you think having a single tree makes that impossible to achieve? As I said I do development basically using the split model at least for testing new tools on older kernels. People using the tools while developing mostly the kernel or both kperf/uperf components do the test on the combined kernel + perf sources. - We are using and enforcing established quality control and coding principles of the kernel project. If we mess up then Linus pushes back on us at the last line of defense - and has pushed back on us in the past. I think many of the currently external kernel utilities could benefit from the resulting rise in quality. I've seen separate tool projects degrade into barely usable tinkerware - that i think cannot happen to perf, regardless of who maintains it in the future. That's basically saying that if you don't have someone competent managing the git tree and providing quality assurance, life gets hard. Sure. But at the same time, does it scale to move all of userspace under one git tree and depending on Linus to push back? 8 or 80 again :-\ I mean, it would have been nice to move all of GNOME 3 under the Linux kernel, so Linus could have pushed back on behalf of all of us power Sheesh, all of gnome? How closely related and used in kernel development is gnome? gnome 3? users, but as much as many of us would have appreciated someone being able to push back against the insanity which is the GNOME design
Re: [Qemu-devel] [PATCH V3 09/10] Introduce apic-msidef.h
On Fri, 28 Oct 2011, Anthony PERARD wrote: This patch move the msi definition from apic.c to apic-msidef.h. So it can be used also by other .c files. you should CC Michael on this one Signed-off-by: Anthony PERARD anthony.per...@citrix.com --- hw/apic-msidef.h | 28 hw/apic.c| 11 +-- 2 files changed, 29 insertions(+), 10 deletions(-) create mode 100644 hw/apic-msidef.h diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h new file mode 100644 index 000..3182f0b --- /dev/null +++ b/hw/apic-msidef.h @@ -0,0 +1,28 @@ +#ifndef HW_APIC_MSIDEF_H +#define HW_APIC_MSIDEF_H + +/* + * Intel APIC constants: from include/asm/msidef.h + */ + +/* + * Shifts for MSI data + */ + +#define MSI_DATA_VECTOR_SHIFT 0 +#define MSI_DATA_VECTOR_MASK 0x00ff + +#define MSI_DATA_DELIVERY_MODE_SHIFT8 +#define MSI_DATA_LEVEL_SHIFT14 +#define MSI_DATA_TRIGGER_SHIFT 15 + +/* + * Shift/mask fields for msi address + */ + +#define MSI_ADDR_DEST_MODE_SHIFT2 + +#define MSI_ADDR_DEST_ID_SHIFT 12 +#define MSI_ADDR_DEST_ID_MASK 0x000 + +#endif /* HW_APIC_MSIDEF_H */ diff --git a/hw/apic.c b/hw/apic.c index 8289eef..18c4a87 100644 --- a/hw/apic.c +++ b/hw/apic.c @@ -24,6 +24,7 @@ #include sysbus.h #include trace.h #include pc.h +#include apic-msidef.h /* APIC Local Vector Table */ #define APIC_LVT_TIMER 0 @@ -65,16 +66,6 @@ #define MAX_APICS 255 #define MAX_APIC_WORDS 8 -/* Intel APIC constants: from include/asm/msidef.h */ -#define MSI_DATA_VECTOR_SHIFT0 -#define MSI_DATA_VECTOR_MASK 0x00ff -#define MSI_DATA_DELIVERY_MODE_SHIFT 8 -#define MSI_DATA_TRIGGER_SHIFT 15 -#define MSI_DATA_LEVEL_SHIFT 14 -#define MSI_ADDR_DEST_MODE_SHIFT 2 -#define MSI_ADDR_DEST_ID_SHIFT 12 -#define MSI_ADDR_DEST_ID_MASK 0x000 - #define MSI_ADDR_SIZE 0x10 typedef struct APICState APICState; -- Anthony PERARD
Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/
* Theodore Tso ty...@mit.edu wrote: On Nov 8, 2011, at 4:32 AM, Ingo Molnar wrote: No ifs and when about it, these are the plain facts: - Better features, better ABIs: perf maintainers can enforce clean, functional and usable tooling support *before* committing to an ABI on the kernel side. We don't have to be careful about breaking interface compatibility while we are developing new features. See my other mail titled: [F.A.Q.] perf ABI backwards and forwards compatibility the compatibility process works surprisingly well, given the complexity and the flux of changes. From the experience i have with other ABI and feature extension efforts, perf ABI compatibility works comparably better, because the changes always go together so people can review and notice any ABI problems a lot easier than with an artificially fragmented tooling/kernel maintenance setup. I guess you can do well with a split project as well - my main claim is that good compatibility comes *naturally* with integration. Btw., this might explain why iOS and Android is surprisingly compatible as well, despite the huge complexity and the huge flux of changes on both platforms - versus modular approaches like Windows or Linux distros. The flip side of this is that it's not obvious when an interface is stable, and when it is still subject to change. [...] ... actual results seem to belie that expectation, right? [...] It makes life much harder for any userspace code that doesn't live in the kernel. [...] So *that* is the real argument? As long as compatibility is good, i don't think why that should be the case. Did you consider it a possibility that out of tree projects that have deep ties to the kernel technically seem to be at a relative disadvantage to in-kernel projects because separation is technically costly with the costs of separation being larger than the advantages of separation? [...] And I think we do agree that moving all of userspace into a single git tree makes no sense, right? I'm inclined to agree that applications that have no connection and affinity to the kernel (technically or socially) should not live in the kernel repo. (In fact i argue that they should be sandboxed but that's another topic .) But note that there are several OS projects that succeeded doing the equivalent of a 'whole world' single Git repo, so i don't think we have the basis to claim that it *cannot* work. - We have a shared Git tree with unified, visible version control. I can see kernel feature commits followed by tooling support, in a single flow of related commits: perf probe: Update perf-probe document perf probe: Support --del option trace-kprobe: Support delete probe syntax With two separate Git repositories this kind of connection between the tool and the kernel is inevitably weakened or lost. We don't have to clearly document new interfaces between kernel and userspace, and instead rely on git commit order for people to figure out what's going on with some new interface It does not prevent the creation of documentation at all - but i argue that the actual *working commits* are more valuable information than the documentation. That inevitably leads to the conclusion that you cannot destroy the more valuable information just to artificially promote the creation of the less valuable piece of information, right? - Easier development, easier testing: if you work on a kernel feature and on matching tooling support then it's *much* easier to work in a single tree than working in two or more trees in parallel. I have worked on multi-tree features before, and except special exceptions they are generally a big pain to develop. I've developed in the split tree systems, and it's really not that hard. It does mean you have to be explicit about designing interfaces up front, and then you have to have a good, robust way of negotiating what features are in the kernel, and what features are supposed by the userspace --- but if you don't do that then having good backwards and forwards compatibility between different versions of the tool simply doesn't exist. I actually think that ext4 is a good example at ABI design - and we borrowed heavily from that positive experience in the perf.data handling code. But i also worked in other projects where the split design worked a lot less smoothly, and arguably ext4 would be *dead* if it had a messy interface design: a persistent filesystem cannot under any circumstance be messy to survive in the long run. Other ABIs, not so much, and we are hurting from that. So at the end of the day it question is whether you want to be able to (for example) update e2fsck to get better ability to fix more file system corruptions, without needing to upgrade the kernel. If you want to be able to use a newer, better e2fsck with an older, enterprise
[Qemu-devel] [PATCH 0/6] Remove libqemu related stuff from QEMU source tree
From: Chen Wei-Ren che...@iis.sinica.edu.tw According to [1], libqemu is not available anymore. Remove libqemu related stuff from QEMU source tree. [1] http://www.mail-archive.com/qemu-devel@nongnu.org/msg49809.html Chen Wen-Ren (6): tests/qruncom.c: Remove libqemu.a example tests/Makefile: Remove qruncom target qemu-tech.texi: Remove libqemu related stuff from the document Makefile.target: Remove libqemu target Makefile.objs: Remove libqemu_common.a target LICENSE: There is no libqemu.a anymore LICENSE |4 +- Makefile.objs | 104 Makefile.target |8 -- qemu-tech.texi |9 -- tests/Makefile |6 - tests/qruncom.c | 284 --- 6 files changed, 1 insertions(+), 414 deletions(-) delete mode 100644 tests/qruncom.c -- 1.7.3.4
Re: [Qemu-devel] [F.A.Q.] perf ABI backwards and forwards compatibility
* Peter Zijlstra a.p.zijls...@chello.nl wrote: On Tue, 2011-11-08 at 13:15 +0100, Ingo Molnar wrote: The one notable thing that isnt being tested in a natural way is the 'group of events' abstraction - which, ironically, has been added on the perfmon guys' insistence. No app beyond the PAPI self-test makes actual use of it though, which results in an obvious lack of testing. Also the self monitor stuff, perf-tool doesn't use that for obvious reasons. Indeed, and that's PAPI's strong point. We could try to utilize it via some clever LD_PRELOAD trickery? Adding a testcase for every bug that can be triggered via tooling would definitely be an improvement as well - those kinds of testcases generally tend to map out the really important bits faster than an attempt at exhaustive testing. Thanks, Ingo
[Qemu-devel] [PATCH 1/6] tests/qruncom.c: Remove libqemu.a example
From: Chen Wei-Ren che...@iis.sinica.edu.tw
Remove libqemu example since libqemu.a is not available anymore.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
tests/qruncom.c | 284 ---
1 files changed, 0 insertions(+), 284 deletions(-)
delete mode 100644 tests/qruncom.c
diff --git a/tests/qruncom.c b/tests/qruncom.c
deleted file mode 100644
index 2e93aaf..000
--- a/tests/qruncom.c
+++ /dev/null
@@ -1,284 +0,0 @@
-/*
- * Example of use of user mode libqemu: launch a basic .com DOS
- * executable
- */
-#include stdlib.h
-#include stdio.h
-#include string.h
-#include inttypes.h
-#include unistd.h
-#include fcntl.h
-#include sys/mman.h
-#include signal.h
-#include malloc.h
-
-#include cpu.h
-
-//#define SIGTEST
-
-int cpu_get_pic_interrupt(CPUState *env)
-{
-return -1;
-}
-
-uint64_t cpu_get_tsc(CPUState *env)
-{
-return 0;
-}
-
-static void set_gate(void *ptr, unsigned int type, unsigned int dpl,
- unsigned long addr, unsigned int sel)
-{
-unsigned int e1, e2;
-e1 = (addr 0x) | (sel 16);
-e2 = (addr 0x) | 0x8000 | (dpl 13) | (type 8);
-stl((uint8_t *)ptr, e1);
-stl((uint8_t *)ptr + 4, e2);
-}
-
-uint64_t idt_table[256];
-
-/* only dpl matters as we do only user space emulation */
-static void set_idt(int n, unsigned int dpl)
-{
-set_gate(idt_table + n, 0, dpl, 0, 0);
-}
-
-void g_free(void *ptr)
-{
-free(ptr);
-}
-
-void *g_malloc(size_t size)
-{
-return malloc(size);
-}
-
-void *g_malloc0(size_t size)
-{
-void *ptr;
-ptr = g_malloc(size);
-if (!ptr)
-return NULL;
-memset(ptr, 0, size);
-return ptr;
-}
-
-void *qemu_vmalloc(size_t size)
-{
-return memalign(4096, size);
-}
-
-void qemu_vfree(void *ptr)
-{
-free(ptr);
-}
-
-void qemu_printf(const char *fmt, ...)
-{
-va_list ap;
-va_start(ap, fmt);
-vprintf(fmt, ap);
-va_end(ap);
-}
-
-/* XXX: this is a bug in helper2.c */
-int errno;
-
-/**/
-
-#define COM_BASE_ADDR0x10100
-
-static void usage(void)
-{
-printf(qruncom version 0.1 (c) 2003 Fabrice Bellard\n
- usage: qruncom file.com\n
- user mode libqemu demo: run simple .com DOS executables\n);
-exit(1);
-}
-
-static inline uint8_t *seg_to_linear(unsigned int seg, unsigned int reg)
-{
-return (uint8_t *)((seg 4) + (reg 0x));
-}
-
-static inline void pushw(CPUState *env, int val)
-{
-env-regs[R_ESP] = (env-regs[R_ESP] ~0x) | ((env-regs[R_ESP] - 2)
0x);
-*(uint16_t *)seg_to_linear(env-segs[R_SS].selector, env-regs[R_ESP]) =
val;
-}
-
-static void host_segv_handler(int host_signum, siginfo_t *info,
- void *puc)
-{
-if (cpu_signal_handler(host_signum, info, puc)) {
-return;
-}
-abort();
-}
-
-int main(int argc, char **argv)
-{
-uint8_t *vm86_mem;
-const char *filename;
-int fd, ret, seg;
-CPUState *env;
-
-if (argc != 2)
-usage();
-filename = argv[1];
-
-vm86_mem = mmap((void *)0x, 0x11,
-PROT_WRITE | PROT_READ | PROT_EXEC,
-MAP_FIXED | MAP_ANON | MAP_PRIVATE, -1, 0);
-if (vm86_mem == MAP_FAILED) {
-perror(mmap);
-exit(1);
-}
-
-/* load the MSDOS .com executable */
-fd = open(filename, O_RDONLY);
-if (fd 0) {
-perror(filename);
-exit(1);
-}
-ret = read(fd, vm86_mem + COM_BASE_ADDR, 65536 - 256);
-if (ret 0) {
-perror(read);
-exit(1);
-}
-close(fd);
-
-/* install exception handler for CPU emulator */
-{
-struct sigaction act;
-
-sigfillset(act.sa_mask);
-act.sa_flags = SA_SIGINFO;
-//act.sa_flags |= SA_ONSTACK;
-
-act.sa_sigaction = host_segv_handler;
-sigaction(SIGSEGV, act, NULL);
-sigaction(SIGBUS, act, NULL);
-}
-
-//cpu_set_log(CPU_LOG_TB_IN_ASM | CPU_LOG_TB_OUT_ASM | CPU_LOG_EXEC);
-
-env = cpu_init(qemu32);
-
-cpu_x86_set_cpl(env, 3);
-
-env-cr[0] = CR0_PG_MASK | CR0_WP_MASK | CR0_PE_MASK;
-/* NOTE: hflags duplicates some of the virtual CPU state */
-env-hflags |= HF_PE_MASK | VM_MASK;
-
-/* flags setup : we activate the IRQs by default as in user
- mode. We also activate the VM86 flag to run DOS code */
-env-eflags |= IF_MASK | VM_MASK;
-
-/* init basic registers */
-env-eip = 0x100;
-env-regs[R_ESP] = 0xfffe;
-seg = (COM_BASE_ADDR - 0x100) 4;
-
-cpu_x86_load_seg_cache(env, R_CS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_SS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_DS, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env, R_ES, seg,
- (seg 4), 0x, 0);
-cpu_x86_load_seg_cache(env,
[Qemu-devel] [PATCH 2/6] tests/Makefile: Remove qruncom target
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove qruncom target from the Makefile file since we have removed libqemu example (qruncom.c). Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- tests/Makefile |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index 430e0c1..15e36a2 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -115,12 +115,6 @@ speed: sha1 sha1-i386 time ./sha1 time $(QEMU) ./sha1-i386 -# broken test -# NOTE: -fomit-frame-pointer is currently needed : this is a bug in libqemu -qruncom: qruncom.c ../ioport-user.c ../i386-user/libqemu.a - $(CC) $(CFLAGS) -fomit-frame-pointer $(LDFLAGS) -I../target-i386 -I.. -I../i386-user -I../fpu \ - -o $@ $(filter %.c, $^) -L../i386-user -lqemu -lm - # arm test hello-arm: hello-arm.o arm-linux-ld -o $@ $ -- 1.7.3.4
[Qemu-devel] [PATCH] target-i386: Fix regression with maxsd SSE2 instruction
The maxsd instruction needs to take into account the sign of the numbers 64 bit numbers. This is a regression that was introduced in 347ac8e356 (target-i386: switch to softfloat). The case that fails is: maxsd %xmm1,%xmm0 When xmm1 = 24 and xmm0 = -100 This was found running the glib2 binding tests where it prints the message: /binding/transform: GLib-GObject-WARNING **: value 24.00 of type `gdouble' is invalid or out of range for property `value' of type `gdouble' aborting... Using a signed comparison fixes the problem. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- target-i386/ops_sse.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/target-i386/ops_sse.h b/target-i386/ops_sse.h index aa41d25..bcc0ed9 100644 --- a/target-i386/ops_sse.h +++ b/target-i386/ops_sse.h @@ -584,8 +584,8 @@ void helper_ ## name ## sd (Reg *d, Reg *s)\ #define FPU_SUB(size, a, b) float ## size ## _sub(a, b, env-sse_status) #define FPU_MUL(size, a, b) float ## size ## _mul(a, b, env-sse_status) #define FPU_DIV(size, a, b) float ## size ## _div(a, b, env-sse_status) -#define FPU_MIN(size, a, b) (a) (b) ? (a) : (b) -#define FPU_MAX(size, a, b) (a) (b) ? (a) : (b) +#define FPU_MIN(size, a, b) (int ## size ## _t)(a) (int ## size ## _t)(b) ? (a) : (b) +#define FPU_MAX(size, a, b) (int ## size ## _t)(a) (int ## size ## _t)(b) ? (a) : (b) #define FPU_SQRT(size, a, b) float ## size ## _sqrt(b, env-sse_status) SSE_HELPER_S(add, FPU_ADD) -- 1.7.1
[Qemu-devel] [PATCH 3/6] qemu-tech.texi: Remove libqemu related stuff from the document
From: Chen Wei-Ren che...@iis.sinica.edu.tw
Remove libqemu related stuff from the document since libqemu.a is not
supported
anymore.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
qemu-tech.texi |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/qemu-tech.texi b/qemu-tech.texi
index 397b070..f307eff 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -96,10 +96,6 @@ Alpha and S390 hosts, but TCG (see below) doesn't support
those yet.
@item Precise exceptions support.
-@item The virtual CPU is a library (@code{libqemu}) which can be used
-in other projects (look at @file{qemu/tests/qruncom.c} to have an
-example of user mode @code{libqemu} usage).
-
@item
Floating point library supporting both full software emulation and
native host FPU instructions.
@@ -711,11 +707,6 @@ This program tests various Linux system calls. It is used
to verify
that the system call parameters are correctly converted between target
and host CPUs.
-@node qruncom.c
-@section @file{qruncom.c}
-
-Example of usage of @code{libqemu} to emulate a user mode i386 CPU.
-
@node Index
@chapter Index
@printindex cp
--
1.7.3.4
[Qemu-devel] [PATCH 4/6] Makefile.target: Remove libqemu target
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove libqemu target from Makefile.target. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- Makefile.target |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/Makefile.target b/Makefile.target index a111521..d1f7993 100644 --- a/Makefile.target +++ b/Makefile.target @@ -92,14 +92,6 @@ tci-dis.o: QEMU_CFLAGS += -I$(SRC_PATH)/tcg -I$(SRC_PATH)/tcg/tci $(libobj-y): $(GENERATED_HEADERS) -# libqemu - -translate.o: translate.c cpu.h - -translate-all.o: translate-all.c cpu.h - -tcg/tcg.o: cpu.h - # HELPER_CFLAGS is used for all the code compiled with static register # variables op_helper.o ldst_helper.o user-exec.o: QEMU_CFLAGS += $(HELPER_CFLAGS) -- 1.7.3.4
Re: [Qemu-devel] multiprocessor on kvm
so qemu exposes multiple processors to the guest os by having multiple vCPUs. and it realizes the multiple vCPUs by either using RR on a single host cpu (qemu ) or using multiple host cpus (kvm). yes. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu: * Vince Weaver vi...@deater.net wrote: as mentioned before I have my own perf_event test suite with 20+ tests. http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html That should probably be moved into perf test. Arnaldo, any objections? I'd gladly take patches, I even have in my TODO list for me to volunteer time to do that at some point. If somebody else than me or Vince wants to do that... Assuming there is no licensing problem and Vince doesn't objects for that to be done. I know that at least the QE team at Red Hat uses it and I hope other QE teams do it. - Arnaldo
[Qemu-devel] [PATCH 5/6] Makefile.objs: Remove libqemu_common.a target
From: Chen Wen-Ren che...@iis.sinica.edu.tw Remove libqemu_common.a target from Makefile.objs. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- Makefile.objs | 104 - 1 files changed, 0 insertions(+), 104 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index d7a6539..ba8879c 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -68,110 +68,6 @@ endif fsdev-obj-$(CONFIG_VIRTFS) += $(addprefix fsdev/, $(fsdev-nested-y)) ## -# libqemu_common.a: Target independent part of system emulation. The -# long term path is to suppress *all* target specific code in case of -# system emulation, i.e. a single QEMU executable should support all -# CPUs and machines. - -common-obj-y = $(block-obj-y) blockdev.o -common-obj-y += $(net-obj-y) -common-obj-y += $(qobject-obj-y) -common-obj-$(CONFIG_LINUX) += $(fsdev-obj-$(CONFIG_LINUX)) -common-obj-y += readline.o console.o cursor.o -common-obj-y += $(oslib-obj-y) -common-obj-$(CONFIG_WIN32) += os-win32.o -common-obj-$(CONFIG_POSIX) += os-posix.o - -common-obj-y += tcg-runtime.o host-utils.o main-loop.o -common-obj-y += irq.o input.o -common-obj-$(CONFIG_PTIMER) += ptimer.o -common-obj-$(CONFIG_MAX7310) += max7310.o -common-obj-$(CONFIG_WM8750) += wm8750.o -common-obj-$(CONFIG_TWL92230) += twl92230.o -common-obj-$(CONFIG_TSC2005) += tsc2005.o -common-obj-$(CONFIG_LM832X) += lm832x.o -common-obj-$(CONFIG_TMP105) += tmp105.o -common-obj-$(CONFIG_STELLARIS_INPUT) += stellaris_input.o -common-obj-$(CONFIG_SSD0303) += ssd0303.o -common-obj-$(CONFIG_SSD0323) += ssd0323.o -common-obj-$(CONFIG_ADS7846) += ads7846.o -common-obj-$(CONFIG_MAX111X) += max111x.o -common-obj-$(CONFIG_DS1338) += ds1338.o -common-obj-y += i2c.o smbus.o smbus_eeprom.o -common-obj-y += eeprom93xx.o -common-obj-y += scsi-disk.o cdrom.o -common-obj-y += scsi-generic.o scsi-bus.o -common-obj-y += hid.o -common-obj-y += usb.o usb-hub.o usb-$(HOST_USB).o usb-hid.o usb-msd.o usb-wacom.o -common-obj-y += usb-serial.o usb-net.o usb-bus.o usb-desc.o -common-obj-$(CONFIG_SSI) += ssi.o -common-obj-$(CONFIG_SSI_SD) += ssi-sd.o -common-obj-$(CONFIG_SD) += sd.o -common-obj-y += bt.o bt-host.o bt-vhci.o bt-l2cap.o bt-sdp.o bt-hci.o bt-hid.o usb-bt.o -common-obj-y += bt-hci-csr.o -common-obj-y += buffered_file.o migration.o migration-tcp.o -common-obj-y += qemu-char.o savevm.o #aio.o -common-obj-y += msmouse.o ps2.o -common-obj-y += qdev.o qdev-properties.o -common-obj-y += block-migration.o iohandler.o -common-obj-y += pflib.o -common-obj-y += bitmap.o bitops.o - -common-obj-$(CONFIG_BRLAPI) += baum.o -common-obj-$(CONFIG_POSIX) += migration-exec.o migration-unix.o migration-fd.o -common-obj-$(CONFIG_WIN32) += version.o - -common-obj-$(CONFIG_SPICE) += ui/spice-core.o ui/spice-input.o ui/spice-display.o spice-qemu-char.o - -audio-obj-y = audio.o noaudio.o wavaudio.o mixeng.o -audio-obj-$(CONFIG_SDL) += sdlaudio.o -audio-obj-$(CONFIG_OSS) += ossaudio.o -audio-obj-$(CONFIG_SPICE) += spiceaudio.o -audio-obj-$(CONFIG_COREAUDIO) += coreaudio.o -audio-obj-$(CONFIG_ALSA) += alsaaudio.o -audio-obj-$(CONFIG_DSOUND) += dsoundaudio.o -audio-obj-$(CONFIG_FMOD) += fmodaudio.o -audio-obj-$(CONFIG_ESD) += esdaudio.o -audio-obj-$(CONFIG_PA) += paaudio.o -audio-obj-$(CONFIG_WINWAVE) += winwaveaudio.o -audio-obj-$(CONFIG_AUDIO_PT_INT) += audio_pt_int.o -audio-obj-$(CONFIG_AUDIO_WIN_INT) += audio_win_int.o -audio-obj-y += wavcapture.o -common-obj-y += $(addprefix audio/, $(audio-obj-y)) - -ui-obj-y += keymaps.o -ui-obj-$(CONFIG_SDL) += sdl.o sdl_zoom.o x_keymap.o -ui-obj-$(CONFIG_COCOA) += cocoa.o -ui-obj-$(CONFIG_CURSES) += curses.o -vnc-obj-y += vnc.o d3des.o -vnc-obj-y += vnc-enc-zlib.o vnc-enc-hextile.o -vnc-obj-y += vnc-enc-tight.o vnc-palette.o -vnc-obj-y += vnc-enc-zrle.o -vnc-obj-$(CONFIG_VNC_TLS) += vnc-tls.o vnc-auth-vencrypt.o -vnc-obj-$(CONFIG_VNC_SASL) += vnc-auth-sasl.o -ifdef CONFIG_VNC_THREAD -vnc-obj-y += vnc-jobs-async.o -else -vnc-obj-y += vnc-jobs-sync.o -endif -common-obj-y += $(addprefix ui/, $(ui-obj-y)) -common-obj-$(CONFIG_VNC) += $(addprefix ui/, $(vnc-obj-y)) - -common-obj-y += iov.o acl.o -common-obj-$(CONFIG_POSIX) += compatfd.o -common-obj-y += notify.o event_notifier.o -common-obj-y += qemu-timer.o qemu-timer-common.o - -slirp-obj-y = cksum.o if.o ip_icmp.o ip_input.o ip_output.o -slirp-obj-y += slirp.o mbuf.o misc.o sbuf.o socket.o tcp_input.o tcp_output.o -slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o arp_table.o -common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y)) - -# xen backend driver support -common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o -common-obj-$(CONFIG_XEN_BACKEND) += xen_console.o xenfb.o xen_disk.o xen_nic.o - -## # libuser user-obj-y = -- 1.7.3.4
[Qemu-devel] [PATCH 6/6] LICENSE: There is no libqemu.a anymore
From: Chen Wei-Ren che...@iis.sinica.edu.tw Remove statement about libqemu.a from LICENSE. Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw --- LICENSE |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/LICENSE b/LICENSE index cbd92c0..acae9a3 100644 --- a/LICENSE +++ b/LICENSE @@ -6,9 +6,7 @@ The following points clarify the QEMU license: GNU General Public License. Hence each source file contains its own licensing information. -In particular, the QEMU virtual CPU core library (libqemu.a) is -released under the GNU Lesser General Public License. Many hardware -device emulation sources are released under the BSD license. +Many hardware device emulation sources are released under the BSD license. 3) The Tiny Code Generator (TCG) is released under the BSD license (see license headers in files). -- 1.7.3.4
Re: [Qemu-devel] [Qemu-trivial] [PATCH v2] ui/vnc: Convert sasl.mechlist to g_malloc() friends
On Tue, Nov 8, 2011 at 12:45 PM, Markus Armbruster arm...@redhat.com wrote: Fixes protocol_client_auth_sasl_mechname() not to crash when malloc() fails. Spotted by Coverity. --- ui/vnc-auth-sasl.c | 19 +-- 1 files changed, 5 insertions(+), 14 deletions(-) Looks good, please add Signed-off-by. Stefan
Re: [Qemu-devel] [PATCH 6/8 v2] block: add eject request callback
Am 07.11.2011 17:50, schrieb Paolo Bonzini: Recent versions of udev always keep the tray locked so that the kernel can observe eject request events (aka tray button presses) even on discs that aren't mounted. Add support for these events in the ATAPI and SCSI cd drive device models. To let management cope with the behavior of udev, an event should also be added for tray opened/closed. This way, after issuing an eject command, management can poll until the guests actually reacts to the command. They can then issue the change command after the tray has been opened, or try with eject -f after a (configurable?) timeout. However, with this patch and the corresponding support in the device models, at least it is possible to do a manual two-step eject+change sequence. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- v1-v2: do not change the behavior of eject -f. Thanks, applied all three eject patches to the block-stable branch (for 1.0) Kevin
Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
On Mon, Nov 07, 2011 at 03:12:28PM +0200, Pekka Enberg wrote: On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o ty...@mit.edu wrote: I don't think perf should be used as a precendent that now argues that any new kernel utility should be moved into the kernel sources. Does it make sense to move all of mount, fsck, login, etc., into the kernel sources? There are far more kernel tools outside of the kernel sources than inside the kernel sources. [...] I don't know if it makes sense to merge the tools you've mentioned above. My gut feeling is that it's probably not reasonable - there's already a community working on it with their own development process and coding style. I don't think there's a simple answer to this but I don't agree with your rather extreme position that all userspace tools should be kept out of the kernel tree. Ted's position is not extreme. He follows the simple and exactly defined border between userspace and kernel. The native userspace feature is variability and substitutability. The util-linux package is really nice example: - you don't have to use it, you can use busybox - we have currently three implementation of login(1), many getty implementations, etc. - it's normal that people use the latest util-linux releases with very old kernels (in year 2008 I had report from person with kernel 2.4:-) - userspace is very often about portability -- it's crazy, but some people use some utils from util-linux on Hurd, Solaris and BSD (including very Linux specific things like mkswap and hwclock) Anyway, I agree that small one-man projects are ineffective for important system tools -- it's usually better to merge things into large projects with reliable infrastructure and alive community (here I agree with Lennart's idea to have 3-5 projects for whole low-level userspace). Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com
Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/
Hi, Indeed, documentation is lacking, I think coming from a kernel standpoint I relied too much in the documentation is source code mantra of old days. Sorry for the shameless plug, but as you are speaking of lacking documentation: Where the heck is the perf config file documented, other than source code? Reading the parser to figure how the config file is supposed to look like really isn't fun :( I'm looking for a way to disable the colors in the perf report tui. Or configure them into something readable. No, light green on light gray which is used by default isn't readable. thanks, Gerd
Re: [Qemu-devel] [PATCH] 9pfs: Stat response from server offset by 2 bytes
On Tue, 8 Nov 2011 16:55:17 +1100, David Gibson da...@gibson.dropbear.id.au
wrote:
From: Timothy Rule tr...@linux.vnet.ibm.com
The 9P spec states that for the stat message the stat[n] structure shall be
encoded at offset 7 in the 9P message (see §13.9 message Rstat).
The existing code is encoding a 2 byte value (hard coded 0 value) at
offset 7 of the 9P message, and then follows with the stat[n] structure
at offset 9 of the 9P message.
This patch removes the encoding of the 2 byte value which has the effect
of moving the stat[n] structure from offset 9 to offset 7 in the 9P
message Rstat.
Signed-off-by: Timothy Rule tr...@linux.vnet.ibm.com
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
hw/9pfs/virtio-9p.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 01cf337..35d8851 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1279,7 +1279,7 @@ static void v9fs_stat(void *opaque)
if (err 0) {
goto out;
}
-offset += pdu_marshal(pdu, offset, wS, 0, v9stat);
+offset += pdu_marshal(pdu, offset, S, v9stat);
err = offset;
trace_v9fs_stat_return(pdu-tag, pdu-id, v9stat.mode,
v9stat.atime, v9stat.mtime, v9stat.length);
The reason for that w is explained in the 9p2000 protocol RFC. Towards
the end of wstat message para we have
BUGS
To make the contents of a directory, such as returned by read(5),
easy to parse, each directory entry begins with a size field. For
consistency, the entries in Twstat and Rstat messages also contain
their size, which means the size appears twice. For example, the
Rstat message is formatted as ``(4+1+2+2+n)[4] Rstat tag[2] n[2]
(n-2)[2] type[2] dev[4]...,'' where n is the value returned by
convD2M.
Also on the client side we do in p9_client_stat
err = p9pdu_readf(req-rc, clnt-proto_version, wS, ignored, ret);
if (err) {
So the above change will break existing client.
Any reason why you need to make the above change ?
-aneesh
[Qemu-devel] x86_64 linux kernel doesn't boot with -icount enabled
Hi.
I'm trying to run stock Debian 6.0 x86_64 kernel using qemu git head.
With the following command line it's ok (getting to rootfs mounting
and panics):
qemu-system-x86_64 -serial stdio -monitor null -nographic -kernel
/boot/vmlinuz-2.6.38-bpo.2-amd64 -append 'console=ttyS0 panic=1'
But once I add -icount option (have tried -icount 1, 2, 16, 256, auto,
the result is the same) qemu loops infinitely in the qemu_run_timers:
for(;;) {
ts = *ptimer_head;
if (!qemu_timer_expired_ns(ts, current_time)) {
break;
}
/* remove timer from the list before calling the callback */
*ptimer_head = ts-next;
ts-next = NULL;
/* run the callback (the timer list can be modified) */
ts-cb(ts-opaque);
}
With ts being hpet timer and inside ts-cb that is hpet_timer, diff =
hpet_calculate_diff(t, cur_tick) is always zero.
The following patch breaks the loop:
diff --git a/hw/hpet.c b/hw/hpet.c
index 12bd64d..eadec7b 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -297,13 +297,17 @@ static void hpet_timer(void *opaque)
}
}
diff = hpet_calculate_diff(t, cur_tick);
-qemu_mod_timer(t-qemu_timer,
- qemu_get_clock_ns(vm_clock) +
(int64_t)ticks_to_ns(diff));
+if (diff) {
+qemu_mod_timer(t-qemu_timer,
+qemu_get_clock_ns(vm_clock) + (int64_t)ticks_to_ns(diff));
+}
} else if (t-config HPET_TN_32BIT !timer_is_periodic(t)) {
if (t-wrap_flag) {
diff = hpet_calculate_diff(t, cur_tick);
-qemu_mod_timer(t-qemu_timer, qemu_get_clock_ns(vm_clock) +
- (int64_t)ticks_to_ns(diff));
+if (diff) {
+qemu_mod_timer(t-qemu_timer, qemu_get_clock_ns(vm_clock) +
+(int64_t)ticks_to_ns(diff));
+}
t-wrap_flag = 0;
}
}
but with this patch applied qemu fails as follows:
[0.00] Console: colour VGA+ 80x25
[0.00] console [ttyS0] enabled
[0.00] Fast TSC calibration using PIT
[0.00] Detected 999.951 MHz processor.
[0.03] Calibrating delay loop (skipped), value calculated
using timer frequency.. 1999.90 BogoMIPS (lpj=3999804)
[0.39] pid_max: default: 32768 minimum: 301
[0.000129] Security Framework initialized
[0.000144] SELinux: Disabled at boot.
[0.000255] Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
[0.000572] Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
[0.000735] Mount-cache hash table entries: 256
[0.001121] Initializing cgroup subsys ns
[0.001136] ns_cgroup deprecated: consider using the
'clone_children' flag without the ns_cgroup.
[0.001161] Initializing cgroup subsys cpuacct
[0.001193] Initializing cgroup subsys devices
[0.001208] Initializing cgroup subsys freezer
[0.001224] Initializing cgroup subsys net_cls
[0.001239] Initializing cgroup subsys blkio
[0.001328] mce: CPU supports 10 MCE banks
[0.001356] SMP alternatives: switching to UP code
[0.008000] Freeing SMP alternatives: 16k freed
[0.008000] ACPI: Core revision 20110112
[0.008000] Setting APIC routing to flat
[0.008000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[0.012000] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[0.012000] ...trying to set up timer (IRQ0) through the 8259A ...
[0.012000] . (found apic 0 pin 2) ...
[0.016000] ... failed.
[0.016000] ...trying to set up timer as Virtual Wire IRQ...
Segmentation fault
b/o the following infinite recursion:
(gdb) bt
#0 0x081b9564 in clz32 (val=0) at
/home/jcmvbkbc/ws/xtensa/qemu-xtensa/host-utils.h:53
#1 0x081b97c2 in fls_bit (value=65536) at
/home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:121
#2 0x081ba16d in get_highest_priority_int (tab=0x89cec54) at
/home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:346
#3 0x081ba275 in apic_irq_pending (s=0x89cdea8) at
/home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:383
#4 0x081ba301 in apic_update_irq (s=0x89cdea8) at
/home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:401
#5 0x081ba492 in apic_set_irq (s=0x89cdea8, vector_num=48,
trigger_mode=0) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:434
#6 0x081b9a77 in apic_local_deliver (s=0x89cdea8, vector=3) at
/home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:182
#7 0x081b9acf in apic_deliver_pic_intr (d=0x89cdea8, level=1) at
/home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:191
#8 0x081ba353 in apic_update_irq (s=0x89cdea8) at
/home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:405
#9 0x081ba492 in apic_set_irq (s=0x89cdea8, vector_num=48,
trigger_mode=0) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:434
#10 0x081b9a77 in apic_local_deliver (s=0x89cdea8, vector=3) at
/home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:182
#11 0x081b9acf in apic_deliver_pic_intr (d=0x89cdea8, level=1) at
Re: [Qemu-devel] [PATCH] target-i386: Fix regression with maxsd SSE2 instruction
On Tue, Nov 8, 2011 at 2:00 PM, Jason Wessel jason.wes...@windriver.com wrote:
The maxsd instruction needs to take into account the sign of the
numbers 64 bit numbers. This is a regression that was introduced in
347ac8e356 (target-i386: switch to softfloat).
The case that fails is:
maxsd %xmm1,%xmm0
When xmm1 = 24 and xmm0 = -100
This was found running the glib2 binding tests where it prints the message:
/binding/transform:
GLib-GObject-WARNING **: value 24.00 of type `gdouble' is invalid or
out of range for property `value' of type `gdouble'
aborting...
Using a signed comparison fixes the problem.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
target-i386/ops_sse.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-i386/ops_sse.h b/target-i386/ops_sse.h
index aa41d25..bcc0ed9 100644
--- a/target-i386/ops_sse.h
+++ b/target-i386/ops_sse.h
@@ -584,8 +584,8 @@ void helper_ ## name ## sd (Reg *d, Reg *s)\
#define FPU_SUB(size, a, b) float ## size ## _sub(a, b, env-sse_status)
#define FPU_MUL(size, a, b) float ## size ## _mul(a, b, env-sse_status)
#define FPU_DIV(size, a, b) float ## size ## _div(a, b, env-sse_status)
-#define FPU_MIN(size, a, b) (a) (b) ? (a) : (b)
-#define FPU_MAX(size, a, b) (a) (b) ? (a) : (b)
Isn't maxsd a floating-point instruction? If so, shouldn't
FPU_{MIN,MAX} use softfloat operations?
Laurent
+#define FPU_MIN(size, a, b) (int ## size ## _t)(a) (int ## size ## _t)(b)
? (a) : (b)
+#define FPU_MAX(size, a, b) (int ## size ## _t)(a) (int ## size ## _t)(b)
? (a) : (b)
#define FPU_SQRT(size, a, b) float ## size ## _sqrt(b, env-sse_status)
SSE_HELPER_S(add, FPU_ADD)
--
1.7.1
Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState
On 11/08/2011 06:38 AM, Avi Kivity wrote: On 11/08/2011 02:30 PM, Peter Maydell wrote: On 8 November 2011 12:21, Avi Kivitya...@redhat.com wrote: On 11/08/2011 02:15 PM, Peter Maydell wrote: This needs to be in the MemoryRegion core implementation, please. Right; see the memory/mutators branch. I plan to push this as soon as everything is converted. OK, then this save/restore patch should wait until that has landed. Please don't add interdependencies, especially as I can't promise a firm date as to when everything is converted (however I'll take this opportunity to remind you that patches, especially for omap, are more welcome than I can possibly articulate). Ideally memory.c should just ensure that the memory hierarchy is saved and restored without devices having to do anything. That's a bit far-fetched - I don't want the memory core involved in save/restore. But if/when we integrate the memory core into QOM, then yes, that layer can take care of it. If we have an observable attribute (that fires off a callback when changed), we can link memory API properties into that attribute. The memory hierarchy is a visible part of the state which can change as the guest does things -- it has to get saved and restored somehow. I think it would be better done in the core where it will always be done right, rather than relying on each device to handle it correctly (especially since it's not always obvious if it's been missed out from the device.) We agree, the only difference is in what core refers to. I don't want memory.c do become intermingled with everything else. It should be in a separate layer. Devices would then talk to this layer, and not to the gluing by themselves as they have to now. Or maybe memory.c will be layered on top of QOM, and then it can take care of everything. I really don't know QOM well enough to say. Copying Anthony for more insight. QOM fixes all problems, but I don't think this has anything to do with QOM :-) We fundamentally should do save/restore using a rigorous, automatically generated mechanism where every field is save/restored[1]. That means we should have a VMSTATE_MEMORY_REGION(). VMSTATE_MEMORY_REGION should save off the state of the memory region, and restore it appropriately. VMSTATE_MEMORY_REGION's implementation does not need to live in memory.c. It can certainly live in savevm.c or somewhere else more appropriate. Where the device is mapped within the address space is no longer a property of the device, so restoring the mapping really should happen at whatever owns the address space (in this case sysbus). In this case, integratorcp is the one mapping things into its own address space so flash_mapped ought to be saved by integratorcp. [1] Deciding that a field doesn't need to be saved should be an exception. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] qmp: add test tool for QMP
On 11/08/2011 02:36 AM, Mark Wu wrote:
When I run this tool, I got two python exceptions. It turned out that both of
them were caused by wrong usage. Do you think we need add validation for input
to handle these cases?
Definitely. Could you just send out a version of the patch with your changes, a
(v2) in the subject, and your Signed-off-by?
Thanks!
Regards,
Anthony Liguori
Thanks.
1. Not using '=' for path:
$ ./QMP/qmp --path monitor-address
Traceback (most recent call last):
File ./QMP/qmp, line 120, in module
sys.exit(main(sys.argv[1:]))
File ./QMP/qmp, line 71, in main
srv.connect()
File /home/mark/work/source/qemu/QMP/qmp.py, line 85, in connect
self.__sock.connect(self.__address)
File string, line 1, in connect
TypeError: argument must be string or read-only character buffer, not bool
Proposed patch:
@@ -48,7 +48,8 @@ def main(args):
arg, value = arg.split('=', 1)
if arg in ['path']:
- path = value
+ if isinstance(value, basestring):
+ path = value
2. No qmp comand given in command line
$ ./QMP/qmp --path=monitor-address
Traceback (most recent call last):
File ./QMP/qmp, line 120, in module
sys.exit(main(sys.argv[1:]))
File ./QMP/qmp, line 65, in main
command, args = args[0], args[1:]
IndexError: list index out of range
@@ -62,11 +63,17 @@ def main(args):
print QMP path isn't set, use --path or set QMP_PATH
return 1
Proposed patch:
- command, args = args[0], args[1:]
+ if len(args):
+ command, args = args[0], args[1:]
+ else:
+ print 'No command found'
+ print 'Usage: qmp [--path=monitor-address] qmp-cmd arguments'
+ return 1
On 11/07/2011 11:11 PM, Anthony Liguori wrote:
I wrote this quickly to aid in testing. It's similar to qmp-shell with a few
important differences:
1) It is not interactive. That makes it useful for scripting.
2) qmp-shell:
(QEMU) set_password protocol=vnc password=foo
3) qmp:
$ qmp set_password --protocol=vnc --password=foo
4) Extensible, git-style interface. If an invalid command name is passed, it
will try to exec qmp-$1.
5) It attempts to pretty print the JSON responses in a shell friendly format
such that tools can work with the output.
Hope others will also find it useful.
Signed-off-by: Anthony Liguorialigu...@us.ibm.com
---
QMP/qmp | 120 +++
1 files changed, 120 insertions(+), 0 deletions(-)
create mode 100755 QMP/qmp
diff --git a/QMP/qmp b/QMP/qmp
new file mode 100755
index 000..7b2a3c7
--- /dev/null
+++ b/QMP/qmp
@@ -0,0 +1,120 @@
+#!/usr/bin/python
+#
+# QMP command line tool
+#
+# Copyright IBM, Corp. 2011
+#
+# Authors:
+# Anthony Liguorialigu...@us.ibm.com
+#
+# This work is licensed under the terms of the GNU GPLv2 or later.
+# See the COPYING file in the top-level directory.
+
+import sys, os
+from qmp import QEMUMonitorProtocol
+
+def print_response(rsp, prefix=[]):
+ if type(rsp) == list:
+ i = 0
+ for item in rsp:
+ if prefix == []:
+ prefix = ['item']
+ print_response(item, prefix[:-1] + ['%s[%d]' % (prefix[-1], i)])
+ i += 1
+ elif type(rsp) == dict:
+ for key in rsp.keys():
+ print_response(rsp[key], prefix + [key])
+ else:
+ if len(prefix):
+ print '%s: %s' % ('.'.join(prefix), rsp)
+ else:
+ print '%s' % (rsp)
+
+def main(args):
+ path = None
+
+ # Use QMP_PATH if it's set
+ if os.environ.has_key('QMP_PATH'):
+ path = os.environ['QMP_PATH']
+
+ while len(args):
+ arg = args[0]
+
+ if arg.startswith('--'):
+ arg = arg[2:]
+ if arg.find('=') == -1:
+ value = True
+ else:
+ arg, value = arg.split('=', 1)
+
+ if arg in ['path']:
+ path = value
+ elif arg in ['help']:
+ os.execlp('man', 'man', 'qmp')
+ else:
+ print 'Unknown argument %s' % arg
+
+ args = args[1:]
+ else:
+ break
+
+ if not path:
+ print QMP path isn't set, use --path or set QMP_PATH
+ return 1
+
+ command, args = args[0], args[1:]
+
+ if command in ['help']:
+ os.execlp('man', 'man', 'qmp')
+
+ srv = QEMUMonitorProtocol(path)
+ srv.connect()
+
+ def do_command(srv, cmd, **kwds):
+ rsp = srv.cmd(cmd, kwds)
+ if rsp.has_key('error'):
+ raise Exception(rsp['error']['desc'])
+ return rsp['return']
+
+ commands = map(lambda x: x['name'], do_command(srv, 'query-commands'))
+
+ srv.close()
+
+ if command not in commands:
+ fullcmd = 'qmp-%s' % command
+ try:
+ os.environ['QMP_PATH'] = path
+ os.execvp(fullcmd, [fullcmd] + args)
+ except OSError, (errno, msg):
+ if errno == 2:
+ print 'Command %s not found.' % (fullcmd)
+ return 1
+ raise
+ return 0
+
+ srv = QEMUMonitorProtocol(path)
+ srv.connect()
+
+ arguments = {}
+ for arg in args:
+ if not arg.startswith('--'):
+ print 'Unknown argument %s' % arg
+ return 1
+
+ arg = arg[2:]
+ if arg.find('=') == -1:
+ value = True
+ else:
+ arg, value = arg.split('=', 1)
+
+ if arg in ['help']:
+ os.execlp('man', 'man', 'qmp-%s' % command)
+ return 1
+
+ arguments[arg] = value
+
+ rsp = do_command(srv, command, **arguments)
+ print_response(rsp)
+
+if __name__ == '__main__':
+ sys.exit(main(sys.argv[1:]))
Re: [Qemu-devel] x86_64 linux kernel doesn't boot with -icount enabled
b/o the following infinite recursion: (gdb) bt #0 0x081b9564 in clz32 (val=0) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/host-utils.h:53 #1 0x081b97c2 in fls_bit (value=65536) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:121 #2 0x081ba16d in get_highest_priority_int (tab=0x89cec54) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:346 #3 0x081ba275 in apic_irq_pending (s=0x89cdea8) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:383 #4 0x081ba301 in apic_update_irq (s=0x89cdea8) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:401 #5 0x081ba492 in apic_set_irq (s=0x89cdea8, vector_num=48, trigger_mode=0) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:434 [...] It ends like this: #131008 0x081ba353 in apic_update_irq (s=0x89cdea8) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:405 #131009 0x081ba492 in apic_set_irq (s=0x89cdea8, vector_num=48, trigger_mode=0) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:434 #131010 0x081b9a77 in apic_local_deliver (s=0x89cdea8, vector=3) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:182 #131011 0x081b9acf in apic_deliver_pic_intr (d=0x89cdea8, level=1) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:191 #131012 0x081ba353 in apic_update_irq (s=0x89cdea8) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:405 #131013 0x081bad5d in apic_get_interrupt (d=0x89cdea8) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/apic.c:620 #131014 0x08271a77 in cpu_get_pic_interrupt (env=0x89c1ce8) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/hw/pc.c:156 #131015 0x081e4cc6 in cpu_x86_exec (env=0x89c1ce8) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/cpu-exec.c:320 #131016 0x081ea7d5 in tcg_cpu_exec (env=0x89c1ce8) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/cpus.c:1007 #131017 0x081ea8e3 in tcg_exec_all () at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/cpus.c:1039 #131018 0x081e9f55 in qemu_tcg_cpu_thread_fn (arg=0x89c1ce8) at /home/jcmvbkbc/ws/xtensa/qemu-xtensa/cpus.c:774 #131019 0xf7b37955 in start_thread (arg=0xf40a2b70) at pthread_create.c:300 #131020 0xf7ab7e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (gdb) -- Thanks. -- Max
Re: [Qemu-devel] x86_64 linux kernel doesn't boot with -icount enabled
On 11/08/2011 02:45 PM, Max Filippov wrote: Hi. I'm trying to run stock Debian 6.0 x86_64 kernel using qemu git head. With the following command line it's ok (getting to rootfs mounting and panics): qemu-system-x86_64 -serial stdio -monitor null -nographic -kernel /boot/vmlinuz-2.6.38-bpo.2-amd64 -append 'console=ttyS0 panic=1' But once I add -icount option (have tried -icount 1, 2, 16, 256, auto, the result is the same) qemu loops infinitely in the qemu_run_timers: Is this a regression, either from 0.15 w/o iothread, or from something recent? Most backends are buggy with icount (with the embedded ones more likely to be reliable). Paolo
Re: [Qemu-devel] multiprocessor on kvm
now question is if one of the cpu vmexits the guest due to trapping instruction ( i.e. PIO), the host linux will have only one physical cpu to run on as the other cpus are still running the guest os ? Am I right ? Thanks Xin 2011/11/8 Xin Tong xerox.time.t...@gmail.com: so qemu exposes multiple processors to the guest os by having multiple vCPUs. and it realizes the multiple vCPUs by either using RR on a single host cpu (qemu ) or using multiple host cpus (kvm). Thanks Xin 2011/11/8 Stefan Hajnoczi stefa...@gmail.com: On Tue, Nov 8, 2011 at 12:10 PM, 陳韋任 che...@iis.sinica.edu.tw wrote: On Tue, Nov 08, 2011 at 08:04:44PM +0800, 陳韋任 wrote: I am wondering that when one uses qemu with kvm. How many cores are exposed and available to the guest os ( assuming the host has 4 cores ). is this configurable ? QEMU provides -smp option, but those virtual cpus are scheduled in round-robin fashion. In other words, it's not real parallelism. I don't know if there is any difference with kvm enabled. IIRC, kvm uses QEMU for device emulation only. Those virtual cpus are ran on physical cpus simultaneously. Right, qemu -enable-kvm will run a thread for each vCPU. So you get true SMP parallelism. QEMU without KVM mode, on the other hand, does round-robin scheduling of vCPUs and does not take advantage of multiprocessor hosts. Stefan
Re: [Qemu-devel] x86_64 linux kernel doesn't boot with -icount enabled
But once I add -icount option (have tried -icount 1, 2, 16, 256, auto, the result is the same) qemu loops infinitely in the qemu_run_timers: Is this a regression, either from 0.15 w/o iothread, or from something recent? Most backends are buggy with icount (with the embedded ones more likely to be reliable). Actually I had it first with qemu-0.13.0-rc0. And I'm trying this to deal with the bug similar to that one: https://bugzilla.redhat.com/show_bug.cgi?id=502440 -- Thanks. -- Max
Re: [Qemu-devel] [PATCH] target-i386: Fix regression with maxsd SSE2 instruction
On 11/08/2011 07:48 AM, Laurent Desnogues wrote:
On Tue, Nov 8, 2011 at 2:00 PM, Jason Wessel jason.wes...@windriver.com
wrote:
The maxsd instruction needs to take into account the sign of the
numbers 64 bit numbers. This is a regression that was introduced in
347ac8e356 (target-i386: switch to softfloat).
The case that fails is:
maxsd %xmm1,%xmm0
When xmm1 = 24 and xmm0 = -100
This was found running the glib2 binding tests where it prints the message:
/binding/transform:
GLib-GObject-WARNING **: value 24.00 of type `gdouble' is invalid or
out of range for property `value' of type `gdouble'
aborting...
Using a signed comparison fixes the problem.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
target-i386/ops_sse.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-i386/ops_sse.h b/target-i386/ops_sse.h
index aa41d25..bcc0ed9 100644
--- a/target-i386/ops_sse.h
+++ b/target-i386/ops_sse.h
@@ -584,8 +584,8 @@ void helper_ ## name ## sd (Reg *d, Reg *s)\
#define FPU_SUB(size, a, b) float ## size ## _sub(a, b, env-sse_status)
#define FPU_MUL(size, a, b) float ## size ## _mul(a, b, env-sse_status)
#define FPU_DIV(size, a, b) float ## size ## _div(a, b, env-sse_status)
-#define FPU_MIN(size, a, b) (a) (b) ? (a) : (b)
-#define FPU_MAX(size, a, b) (a) (b) ? (a) : (b)
Isn't maxsd a floating-point instruction? If so, shouldn't
FPU_{MIN,MAX} use softfloat operations?
You are correct.
It should be:
+#define FPU_MIN(size, a, b) float ## size ## _lt(a, b, env-sse_status) ? (a)
: (b)
+#define FPU_MAX(size, a, b) float ## size ## _lt(b, a, env-sse_status) ? (a)
: (b)
Jason.
Laurent
+#define FPU_MIN(size, a, b) (int ## size ## _t)(a) (int ## size ## _t)(b)
? (a) : (b)
+#define FPU_MAX(size, a, b) (int ## size ## _t)(a) (int ## size ## _t)(b)
? (a) : (b)
#define FPU_SQRT(size, a, b) float ## size ## _sqrt(b, env-sse_status)
SSE_HELPER_S(add, FPU_ADD)
--
1.7.1
[Qemu-devel] [PATCH 1.0] configure: fix detection for xattr.h on modern distributions
Modern distributions place xattr.h in /usr/include/sys, and fold
libattr.so into libc. They also don't have an ENOATTR.
Make configure detect this, and add a qemu-xattr.h file that
directs the #include to the right place.
Signed-off-by: Avi Kivity a...@redhat.com
---
configure |8
hw/9pfs/virtio-9p-handle.c|2 +-
hw/9pfs/virtio-9p-local.c |2 +-
hw/9pfs/virtio-9p-posix-acl.c |2 +-
hw/9pfs/virtio-9p-xattr.h |2 +-
linux-user/syscall.c |2 +-
qemu-xattr.h | 30 ++
7 files changed, 43 insertions(+), 5 deletions(-)
create mode 100644 qemu-xattr.h
diff --git a/configure b/configure
index 9e5da44..5158015 100755
--- a/configure
+++ b/configure
@@ -129,6 +129,7 @@ xen=
xen_ctrl_version=
linux_aio=
attr=
+attr_in_sys=
xfs=
vhost_net=no
@@ -1967,6 +1968,10 @@ EOF
if compile_prog -lattr ; then
attr=yes
LIBS=-lattr $LIBS
+ # On Fedora 15, there is no attr/xattr.h, and no -lattr:
+ elif sed -i s,attr/,sys/, $TMPC compile_prog ; then
+attr=yes
+attr_in_sys=yes
else
if test $attr = yes ; then
feature_not_found ATTR
@@ -3032,6 +3037,9 @@ fi
if test $attr = yes ; then
echo CONFIG_ATTR=y $config_host_mak
fi
+if test $attr_in_sys = yes ; then
+ echo CONFIG_ATTR_IN_SYS=y $config_host_mak
+fi
if test $linux = yes ; then
if test $attr = yes ; then
echo CONFIG_VIRTFS=y $config_host_mak
diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
index c38e0e7..8d53cf0 100644
--- a/hw/9pfs/virtio-9p-handle.c
+++ b/hw/9pfs/virtio-9p-handle.c
@@ -19,7 +19,7 @@
#include grp.h
#include sys/socket.h
#include sys/un.h
-#include attr/xattr.h
+#include qemu-xattr.h
#include unistd.h
#include linux/fs.h
#ifdef CONFIG_LINUX_MAGIC_H
diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
index 782dc0a..740f4e6 100644
--- a/hw/9pfs/virtio-9p-local.c
+++ b/hw/9pfs/virtio-9p-local.c
@@ -19,7 +19,7 @@
#include grp.h
#include sys/socket.h
#include sys/un.h
-#include attr/xattr.h
+#include qemu-xattr.h
#include linux/fs.h
#ifdef CONFIG_LINUX_MAGIC_H
#include linux/magic.h
diff --git a/hw/9pfs/virtio-9p-posix-acl.c b/hw/9pfs/virtio-9p-posix-acl.c
index f5b392e..ff82cf0 100644
--- a/hw/9pfs/virtio-9p-posix-acl.c
+++ b/hw/9pfs/virtio-9p-posix-acl.c
@@ -12,7 +12,7 @@
*/
#include sys/types.h
-#include attr/xattr.h
+#include qemu-xattr.h
#include hw/virtio.h
#include virtio-9p.h
#include fsdev/file-op-9p.h
diff --git a/hw/9pfs/virtio-9p-xattr.h b/hw/9pfs/virtio-9p-xattr.h
index 247e414..9437280 100644
--- a/hw/9pfs/virtio-9p-xattr.h
+++ b/hw/9pfs/virtio-9p-xattr.h
@@ -13,7 +13,7 @@
#ifndef _QEMU_VIRTIO_9P_XATTR_H
#define _QEMU_VIRTIO_9P_XATTR_H
-#include attr/xattr.h
+#include qemu-xattr.h
typedef struct xattr_operations
{
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9f5da36..e9c0566 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -71,7 +71,7 @@ int __clone2(int (*fn)(void *), void *child_stack_base,
#include sys/epoll.h
#endif
#ifdef CONFIG_ATTR
-#include attr/xattr.h
+#include qemu-xattr.h
#endif
#define termios host_termios
diff --git a/qemu-xattr.h b/qemu-xattr.h
new file mode 100644
index 000..a1fb46b
--- /dev/null
+++ b/qemu-xattr.h
@@ -0,0 +1,30 @@
+/*
+ * Host xattr.h abstraction
+ *
+ * Copyright 2011 Red Hat Inc. and/or its affiliates
+ *
+ * Authors:
+ * Avi Kivity a...@redhat.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2, or any
+ * later version. See the COPYING file in the top-level directory.
+ *
+ */
+#ifndef QEMU_XATTR_H
+#define QEMU_XATTR_H
+
+/*
+ * Modern distributions (e.g. Fedora 15, have no libattr.so, place attr.h
+ * in /usr/include/sys, and don't have ENOATTR.
+ */
+
+#include config-host.h
+
+#ifdef CONFIG_ATTR_IN_SYS
+# define ENOATTR ENODATA
+# include sys/xattr.h
+#else
+# include attr/xattr.h
+#endif
+
+#endif
--
1.7.7.1
[Qemu-devel] [PATCH] target-i386: Fix regression with maxsd SSE2 instruction v2
The maxsd instruction needs to take into account the sign of the numbers 64 bit numbers. This is a regression that was introduced in 347ac8e356 (target-i386: switch to softfloat). The case that fails is: maxsd %xmm1,%xmm0 When xmm1 = 24 and xmm0 = -100 This was found running the glib2 binding tests where it prints the message: /binding/transform: GLib-GObject-WARNING **: value 24.00 of type `gdouble' is invalid or out of range for property `value' of type `gdouble' aborting... Using a signed comparison fixes the problem. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- target-i386/ops_sse.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/target-i386/ops_sse.h b/target-i386/ops_sse.h index aa41d25..58f7bf5 100644 --- a/target-i386/ops_sse.h +++ b/target-i386/ops_sse.h @@ -584,8 +584,8 @@ void helper_ ## name ## sd (Reg *d, Reg *s)\ #define FPU_SUB(size, a, b) float ## size ## _sub(a, b, env-sse_status) #define FPU_MUL(size, a, b) float ## size ## _mul(a, b, env-sse_status) #define FPU_DIV(size, a, b) float ## size ## _div(a, b, env-sse_status) -#define FPU_MIN(size, a, b) (a) (b) ? (a) : (b) -#define FPU_MAX(size, a, b) (a) (b) ? (a) : (b) +#define FPU_MIN(size, a, b) float ## size ## _lt(a, b, env-sse_status) ? (a) : (b) +#define FPU_MAX(size, a, b) float ## size ## _lt(b, a, env-sse_status) ? (a) : (b) #define FPU_SQRT(size, a, b) float ## size ## _sqrt(b, env-sse_status) SSE_HELPER_S(add, FPU_ADD) -- 1.7.1
Re: [Qemu-devel] [Qemu-trivial] [PATCH v2] ui/vnc: Convert sasl.mechlist to g_malloc() friends
Stefan Hajnoczi stefa...@gmail.com writes: On Tue, Nov 8, 2011 at 12:45 PM, Markus Armbruster arm...@redhat.com wrote: Fixes protocol_client_auth_sasl_mechname() not to crash when malloc() fails. Spotted by Coverity. --- ui/vnc-auth-sasl.c | 19 +-- 1 files changed, 5 insertions(+), 14 deletions(-) Looks good, please add Signed-off-by. Gaa, too trivial to get it right in less than three tries! There must a curse of brainlessness on this one...
[Qemu-devel] [PATCH v3] ui/vnc: Convert sasl.mechlist to g_malloc() friends
Fixes protocol_client_auth_sasl_mechname() not to crash when malloc()
fails. Spotted by Coverity.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
ui/vnc-auth-sasl.c | 19 +--
1 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
index 23b1bf5..e2045fc 100644
--- a/ui/vnc-auth-sasl.c
+++ b/ui/vnc-auth-sasl.c
@@ -35,7 +35,7 @@ void vnc_sasl_client_cleanup(VncState *vs)
vs-sasl.encodedLength = vs-sasl.encodedOffset = 0;
vs-sasl.encoded = NULL;
g_free(vs-sasl.username);
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.username = vs-sasl.mechlist = NULL;
sasl_dispose(vs-sasl.conn);
vs-sasl.conn = NULL;
@@ -430,11 +430,7 @@ static int protocol_client_auth_sasl_start_len(VncState
*vs, uint8_t *data, size
static int protocol_client_auth_sasl_mechname(VncState *vs, uint8_t *data,
size_t len)
{
-char *mechname = malloc(len + 1);
-if (!mechname) {
-VNC_DEBUG(Out of memory reading mechname\n);
-vnc_client_error(vs);
-}
+char *mechname = g_malloc(len + 1);
strncpy(mechname, (char*)data, len);
mechname[len] = '\0';
VNC_DEBUG(Got client mechname '%s' check against '%s'\n,
@@ -460,7 +456,7 @@ static int protocol_client_auth_sasl_mechname(VncState *vs,
uint8_t *data, size_
}
}
-free(vs-sasl.mechlist);
+g_free(vs-sasl.mechlist);
vs-sasl.mechlist = mechname;
VNC_DEBUG(Validated mechname '%s'\n, mechname);
@@ -469,7 +465,7 @@ static int protocol_client_auth_sasl_mechname(VncState *vs,
uint8_t *data, size_
fail:
vnc_client_error(vs);
-free(mechname);
+g_free(mechname);
return -1;
}
@@ -608,12 +604,7 @@ void start_auth_sasl(VncState *vs)
}
VNC_DEBUG(Available mechanisms for client: '%s'\n, mechlist);
-if (!(vs-sasl.mechlist = strdup(mechlist))) {
-VNC_DEBUG(Out of memory);
-sasl_dispose(vs-sasl.conn);
-vs-sasl.conn = NULL;
-goto authabort;
-}
+vs-sasl.mechlist = g_strdup(mechlist);
mechlistlen = strlen(mechlist);
vnc_write_u32(vs, mechlistlen);
vnc_write(vs, mechlist, mechlistlen);
--
1.7.6.4
