Re: [Qemu-devel] [PATCH qemu 5/6] implement -no-user-config command-line option (v3)
Il 27/05/2012 16:02, Andreas Färber ha scritto: Any suggestion how to fix? Does it work to typedef _Bool __bool before including altivec.h (and in the same #ifdef)? Paolo
Re: [Qemu-devel] [PATCH 1.1] es1370: Fix debug code
Am 28.05.2012 06:11, schrieb Peter Maydell: On 23 May 2012 22:26, Stefan Weils...@weilnetz.de wrote: When DEBUG_ES1370 is defined, the compiler shows these warnings: hw/es1370.c: In function ‘es1370_update_voices’: hw/es1370.c:414: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’ The unicode quotes in this commit message seem to have got smashed to question-mark characters at some point between this email and it hitting git master :-( -- PMM Malc, could you please check your git workflow? Commit 24f50d7ea5896a30b0e78f68884586bb8b40ff97 and other commits also changed Andreas Färber to Andreas F?rber. See also a394aed235d6b3f048eeae83289f4d21eca7023c and lots more. The author is always correct, but UTF-8 characters in the commit message were replaced by ?. Regards, Stefan W.
Re: [Qemu-devel] [PULL 1.1 0/2] SCSI patches for 1.1.0-rc3
Il 26/05/2012 11:18, ronnie sahlberg ha scritto: I have compiled your branch and run through some tests. It all looks good as long as you apply the patch to #include hw/scsi-defs.h Thanks, I updated the scsi-next branch. Paolo
Re: [Qemu-devel] [PATCH qom-next] qom: Introduce object_property_is_{child, link}()
Il 27/05/2012 01:19, Andreas Färber ha scritto:
Avoids hardcoding partial string comparisons.
Signed-off-by: Alexander Barabash alexander_barab...@mentor.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
qom/object.c | 22 --
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index 173835b..00bb3b0 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -305,6 +305,16 @@ void object_initialize(void *data, const char *typename)
object_initialize_with_type(data, type);
}
+static inline bool object_property_is_child(ObjectProperty *prop)
+{
+return strstart(prop-type, child, NULL);
+}
+
+static inline bool object_property_is_link(ObjectProperty *prop)
+{
+return strstart(prop-type, link, NULL);
+}
+
static void object_property_del_all(Object *obj)
{
while (!QTAILQ_EMPTY(obj-properties)) {
@@ -327,7 +337,7 @@ static void object_property_del_child(Object *obj, Object
*child, Error **errp)
ObjectProperty *prop;
QTAILQ_FOREACH(prop, obj-properties, node) {
-if (strstart(prop-type, child, NULL) prop-opaque == child) {
+if (object_property_is_child(prop) prop-opaque == child) {
object_property_del(obj, prop-name, errp);
break;
}
@@ -600,7 +610,7 @@ int object_child_foreach(Object *obj, int (*fn)(Object
*child, void *opaque),
int ret = 0;
QTAILQ_FOREACH(prop, obj-properties, node) {
-if (strstart(prop-type, child, NULL)) {
+if (object_property_is_child(prop)) {
ret = fn(prop-opaque, opaque);
if (ret != 0) {
break;
@@ -1022,7 +1032,7 @@ gchar *object_get_canonical_path(Object *obj)
g_assert(obj-parent != NULL);
QTAILQ_FOREACH(prop, obj-parent-properties, node) {
-if (!strstart(prop-type, child, NULL)) {
+if (!object_property_is_child(prop)) {
continue;
}
@@ -1056,9 +1066,9 @@ Object *object_resolve_path_component(Object *parent,
gchar *part)
return NULL;
}
-if (strstart(prop-type, link, NULL)) {
+if (object_property_is_link(prop)) {
return *(Object **)prop-opaque;
-} else if (strstart(prop-type, child, NULL)) {
+} else if (object_property_is_child(prop)) {
return prop-opaque;
} else {
return NULL;
@@ -1101,7 +,7 @@ static Object *object_resolve_partial_path(Object
*parent,
QTAILQ_FOREACH(prop, parent-properties, node) {
Object *found;
-if (!strstart(prop-type, child, NULL)) {
+if (!object_property_is_child(prop)) {
continue;
}
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Paolo
Re: [Qemu-devel] [PATCH 4/4] ISCSI: If the device we open is a SMC device, then force the use of sg. We dont have any medium changer emulation so only passthrough via real sg or scsi-generic via iscsi
Il 27/05/2012 15:12, Andreas Färber ha scritto: Modified to also do the same for tapes, applied to scsi-next branch for 1.2. Paolo, it seems you haven't pushed scsi-next since then. Yeah, I have a pending push request for scsi-next, so I'm waiting till Anthony applies it before pushing 1.2-only patches (I wasn't expecting parallel 1.1/1.2 development for SCSI). I hope you've also shortened the subject to a humanly bearable length? Yes. :) Paolo
Re: [Qemu-devel] [PATCH for-1.1] arch_init: Fix AltiVec build on Darwin/ppc
Il 27/05/2012 17:37, Andreas Färber ha scritto: GCC's altivec.h may in a !__APPLE_ALTIVEC__ code path redefine bool, leading to type mismatches. altivec.h recommends to #undef for C++ compatibility, but doing so on C leads to bool remaining undefined. Reviewed-by: Paolo Bonzini pbonz...@redhat.com Paolo
Re: [Qemu-devel] [PATCH for-1.1?] slirp: Avoid redefining MAX_TCPOPTLEN
Il 27/05/2012 19:02, Andreas Färber ha scritto:
MAX_TCPOPTLEN is being defined as 32. Darwin has it as 40, causing a
warning. The value is only used to declare an array, into which currently
4 bytes are written at most. It should therefore be acceptable to adopt
the host's definition.
Therefore only define MAX_TCPOPTLEN if not already defined.
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
slirp/tcp_output.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/slirp/tcp_output.c b/slirp/tcp_output.c
index 779314b..9815123 100644
--- a/slirp/tcp_output.c
+++ b/slirp/tcp_output.c
@@ -47,7 +47,9 @@ static const u_char tcp_outflags[TCP_NSTATES] = {
};
+#ifndef MAX_TCPOPTLEN
#define MAX_TCPOPTLEN32 /* max # bytes that go in options */
+#endif
/*
* Tcp output routine: figure out what should be sent and send it.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Paolo
Re: [Qemu-devel] [PATCH for-1.1?] slirp: Avoid redefining MAX_TCPOPTLEN
Am 28.05.2012 08:49, schrieb Paolo Bonzini: Il 27/05/2012 19:02, Andreas Färber ha scritto: MAX_TCPOPTLEN is being defined as 32. Darwin has it as 40, causing a warning. The value is only used to declare an array, into which currently 4 bytes are written at most. It should therefore be acceptable to adopt the host's definition. Can we be sure that there will be never a build environment which defines MAX_TCPOPTLENto a value less than 4? If not, either the preprocessor or an assertion should test that, or we could use QEMU_MAX_TCPOPTLEN or SLIRP_MAX_TCPOPTLEN. Regards, Stefan W.
[Qemu-devel] [PATCH] block: prevent snapshot mode $TMPDIR symlink attack
In snapshot mode, bdrv_open creates an empty temporary file without
checking for mkstemp or close failure, and ignoring the possibility
of a buffer overrun given a surprisingly long $TMPDIR.
Change the get_tmp_filename function to return int (not void),
so that it can inform its two callers of those failures.
Also avoid the risk of buffer overrun and do not ignore mkstemp
or close failure.
Update both callers (in block.c and vvfat.c) to propagate
temp-file-creation failure to their callers.
get_tmp_filename creates and closes an empty file, while its
callers later open that presumed-existing file with O_CREAT.
The problem was that a malicious user could provoke mkstemp failure
and race to create a symlink with the selected temporary file name,
thus causing the qemu process (usually root owned) to open through
the symlink, overwriting an attacker-chosen file.
This addresses CVE-2012-2652.
http://bugzilla.redhat.com/CVE-2012-2652
Signed-off-by: Jim Meyering meyer...@redhat.com
---
Note that I haven't tried to see if the _WIN32 -GetLastError() return
value is properly diagnosed as it is propagated up the call stack.
block.c | 37 -
block/vvfat.c | 7 ++-
block_int.h | 2 +-
3 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/block.c b/block.c
index af2ab4f..7547051 100644
--- a/block.c
+++ b/block.c
@@ -409,28 +409,36 @@ int bdrv_create_file(const char* filename,
QEMUOptionParameter *options)
return bdrv_create(drv, filename, options);
}
-#ifdef _WIN32
-void get_tmp_filename(char *filename, int size)
+/*
+ * Create a uniquely-named empty temporary file.
+ * Return 0 upon success, otherwise a negative errno value.
+ */
+int get_tmp_filename(char *filename, int size)
{
+#ifdef _WIN32
char temp_dir[MAX_PATH];
-
-GetTempPath(MAX_PATH, temp_dir);
-GetTempFileName(temp_dir, qem, 0, filename);
-}
+/* GetTempFileName requires that its output buffer (4th param)
+ have length MAX_PATH or greater. */
+assert(size = MAX_PATH);
+return (GetTempPath(MAX_PATH, temp_dir)
+ GetTempFileName(temp_dir, qem, 0, filename)
+? 0 : -GetLastError());
#else
-void get_tmp_filename(char *filename, int size)
-{
int fd;
const char *tmpdir;
-/* XXX: race condition possible */
tmpdir = getenv(TMPDIR);
if (!tmpdir)
tmpdir = /tmp;
-snprintf(filename, size, %s/vl.XX, tmpdir);
+if (snprintf(filename, size, %s/vl.XX, tmpdir) = size) {
+return -EOVERFLOW;
+}
fd = mkstemp(filename);
-close(fd);
-}
+if (fd 0 || close(fd)) {
+return -errno;
+}
+return 0;
#endif
+}
/*
* Detect host devices. By convention, /dev/cdrom[N] is always
@@ -753,7 +761,10 @@ int bdrv_open(BlockDriverState *bs, const char *filename,
int flags,
bdrv_delete(bs1);
-get_tmp_filename(tmp_filename, sizeof(tmp_filename));
+ret = get_tmp_filename(tmp_filename, sizeof(tmp_filename));
+if (ret 0) {
+return ret;
+}
/* Real path is meaningless for protocols */
if (is_protocol)
diff --git a/block/vvfat.c b/block/vvfat.c
index 2dc9d50..0fd3367 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -2808,7 +2808,12 @@ static int enable_write_target(BDRVVVFATState *s)
array_init((s-commits), sizeof(commit_t));
s-qcow_filename = g_malloc(1024);
-get_tmp_filename(s-qcow_filename, 1024);
+ret = get_tmp_filename(s-qcow_filename, 1024);
+if (ret 0) {
+g_free(s-qcow_filename);
+s-qcow_filename = NULL;
+return ret;
+}
bdrv_qcow = bdrv_find_format(qcow);
options = parse_option_parameters(, bdrv_qcow-create_options, NULL);
diff --git a/block_int.h b/block_int.h
index b80e66d..3d4abc6 100644
--- a/block_int.h
+++ b/block_int.h
@@ -335,7 +335,7 @@ struct BlockDriverState {
BlockJob *job;
};
-void get_tmp_filename(char *filename, int size);
+int get_tmp_filename(char *filename, int size);
void bdrv_set_io_limits(BlockDriverState *bs,
BlockIOLimit *io_limits);
--
1.7.10.2.605.gbefc5ed
Re: [Qemu-devel] [PATCH v2] net: add the support for -netdev socket, listen
On Sun, Feb 26, 2012 at 10:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sat, Feb 18, 2012 at 9:19 AM, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com The -net socket,listen option does not work with the newer -netdev syntax: http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01508.html This patch makes it work now. Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- net.c | 26 + net.h | 2 + net/socket.c | 72 +- 3 files changed, 84 insertions(+), 16 deletions(-) I wanted to understand the problem better so I tried out -net socket,listen=. Here is its behavior: 1. A client can connect to QEMU, this creates a new socket VLANClientState on the VLAN. 2. If another client connects to QEMU, another VLANClientState is created. That means many socket clients can be added to the same VLAN. 3. When a simple TCP client like netcat connects and then disconnects, the VLANClientState remains forever. There seems to be no cleanup. This patch does not handle the -net socket,listen= case where multiple clients connect. Also, the -netdev socket,listen= semantics cannot match -net socket-listen= semantics because there is only one peer at any time. Some options: 1. Do not accept new connections while a client is connected. Once the client disconnects we can accept a new connection. This maintains the 1-1 peer behavior. 2. Integrate with vlan-hub so that multiple clients can connect even with -netdev. Connections will create new NetClientStates and auto-attach to the hub. This mimics -net socket,listen= but requires a hub to be used. 3. Forbid -netdev socket,listen=, only allow -net socket,listen=. I think #1 would be okay, although it no longer allows multiple connections, but I don't have a strong opinion either way. Now i prefer to support #2. Do you think of it? Should the usage -netdev socket,listen also been supported or forbidden? As you said, -netdev only has one peer, so their usage will be a bit different. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On Sat, May 26, 2012 at 01:02:49AM +0530, Amit Shah wrote:
The Linux kernel already has a virtio-rng driver, this is the device
implementation.
When the guest asks for entropy from the virtio hwrng, it puts a buffer
in the vq. We then put entropy into that buffer, and push it back to
the guest.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo /dev/urandom
ACK to this ARGV design from a libvirt POV.
A QMP event is sent for interested apps to monitor activity and send the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
IIUC, there are three ways mgmt apps can use the RNG with the
chardev
- Wire it up to a source that just blindly provides all the
entropy QEMU desires (as you /dev/urandom example above)
- Feed in a fixed amount of entropy every minute, regardless
of how much QEMU desires
- Feed in entropy on demand, in response to the ENTROPY_NEEDED
event notification (possibly throttling)
These options sounds like they should cover all reasonable needs,
so gets my vote. Probably want to include the ENTROPY_NEEDED
event in my patch which adds rate limiting to guest initiated
events.
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 14/14] qapi: convert screendump
On Fri, May 25, 2012 at 04:41:19PM -0300, Luiz Capitulino wrote:
One small note below.
Also activates error reporting from devices.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
console.c| 7 ---
console.h| 1 -
hmp-commands.hx | 5 ++---
hmp.c| 9 +
hmp.h| 1 +
monitor.c| 6 --
qapi-schema.json | 24
qmp-commands.hx | 5 +
8 files changed, 41 insertions(+), 17 deletions(-)
diff --git a/console.c b/console.c
index 4669e62..2bbf104 100644
--- a/console.c
+++ b/console.c
@@ -24,6 +24,7 @@
#include qemu-common.h
#include console.h
#include qemu-timer.h
+#include qmp-commands.h
//#define DEBUG_CONSOLE
#define DEFAULT_BACKSCROLL 512
@@ -173,7 +174,7 @@ void vga_hw_invalidate(void)
active_console-hw_invalidate(active_console-hw);
}
-void vga_hw_screen_dump(const char *filename)
+void qmp_screendump(const char *filename, Error **errp)
{
TextConsole *previous_active_console;
bool cswitch;
@@ -187,9 +188,9 @@ void vga_hw_screen_dump(const char *filename)
console_select(0);
}
if (consoles[0] consoles[0]-hw_screen_dump) {
-consoles[0]-hw_screen_dump(consoles[0]-hw, filename, cswitch,
NULL);
+consoles[0]-hw_screen_dump(consoles[0]-hw, filename, cswitch,
errp);
} else {
-error_report(screen dump not implemented);
+error_set(errp, QERR_NOT_SUPPORTED);
}
if (cswitch) {
diff --git a/console.h b/console.h
index 9caeb43..d72c546 100644
--- a/console.h
+++ b/console.h
@@ -356,7 +356,6 @@ DisplayState *graphic_console_init(vga_hw_update_ptr
update,
void vga_hw_update(void);
void vga_hw_invalidate(void);
-void vga_hw_screen_dump(const char *filename);
void vga_hw_text_update(console_ch_t *chardata);
int is_graphic_console(void);
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 18cb415..74f61bc 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -193,9 +193,8 @@ ETEXI
.name = screendump,
.args_type = filename:F,
.params = filename,
-.help = save screen into PPM image 'filename',
-.user_print = monitor_user_noop,
-.mhandler.cmd_new = do_screen_dump,
+.help = save screen into PPM image 'filepath',
+.mhandler.cmd = hmp_screen_dump,
},
STEXI
diff --git a/hmp.c b/hmp.c
index bb0952e..7e8c0ab 100644
--- a/hmp.c
+++ b/hmp.c
@@ -947,3 +947,12 @@ void hmp_device_del(Monitor *mon, const QDict *qdict)
qmp_device_del(id, err);
hmp_handle_error(mon, err);
}
+
+void hmp_screen_dump(Monitor *mon, const QDict *qdict)
+{
+const char *filename = qdict_get_str(qdict, filename);
+Error *err = NULL;
+
+qmp_screendump(filename, err);
+hmp_handle_error(mon, err);
+}
diff --git a/hmp.h b/hmp.h
index 443b812..fa75ec0 100644
--- a/hmp.h
+++ b/hmp.h
@@ -61,5 +61,6 @@ void hmp_block_job_set_speed(Monitor *mon, const QDict
*qdict);
void hmp_block_job_cancel(Monitor *mon, const QDict *qdict);
void hmp_migrate(Monitor *mon, const QDict *qdict);
void hmp_device_del(Monitor *mon, const QDict *qdict);
+void hmp_screen_dump(Monitor *mon, const QDict *qdict);
#endif
diff --git a/monitor.c b/monitor.c
index 12a6fe2..1160af7 100644
--- a/monitor.c
+++ b/monitor.c
@@ -897,12 +897,6 @@ static int client_migrate_info(Monitor *mon, const QDict
*qdict,
return -1;
}
-static int do_screen_dump(Monitor *mon, const QDict *qdict, QObject
**ret_data)
-{
-vga_hw_screen_dump(qdict_get_str(qdict, filename));
-return 0;
-}
-
static void do_logfile(Monitor *mon, const QDict *qdict)
{
cpu_set_log_filename(qdict_get_str(qdict, filename));
diff --git a/qapi-schema.json b/qapi-schema.json
index 2ca7195..43d4acd 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1755,3 +1755,27 @@
# Since: 0.14.0
##
{ 'command': 'device_del', 'data': {'id': 'str'} }
+
+##
+# @screendump:
+#
+# Write a PPM of the VGA screen to a file.
+#
+# @filename: the path of a new PPM file to store the image
+#
+# Since: 0.14.0
+#
+# Returns: Nothing on success
+# If the underlying device doesn't support screen dump, NotSupported
+# If access to the file is not allowed, InvalidAccess
+# If QEMU has too many open files, TooManyFilesByProcess
+# If the system has too many open files, TooManyFilesInSystem
+# If @filename is too long, NameTooLong
+# If the system doesn't have enough space, NoSpace
+# If the file-system to write the file to is read-only, ReadOnlyFileSystem
+# If opening @filename fails for an uknown reason, OpenFileFailed
+# If @filename becames too big, FileTooBig
+# If an I/O happens while writing @filename, IOError
If an I/O _error_ happens ...
Note: you expect this to be duplicated for other commands writing
creating files, i.e.
Re: [Qemu-devel] [PATCH qmp-next 00/14]: qapi: convert screendump
On Fri, May 25, 2012 at 04:41:05PM -0300, Luiz Capitulino wrote: Converting the screendump command is simple and shouldn't take more than or or two patches, the complicated part is to report all errors correctly. I hope I didn't go too far there, but at least this series does the right thing (or is very near to). Reviewed-by: Alon Levy al...@redhat.com console.c| 7 ++-- console.h| 5 +-- cutils.c | 100 +++ hmp-commands.hx | 5 ++- hmp.c| 9 + hmp.h| 1 + hw/blizzard.c| 4 +-- hw/g364fb.c | 51 hw/omap_lcdc.c | 60 +++-- hw/qxl.c | 7 ++-- hw/tcx.c | 96 hw/vga.c | 38 + hw/vga_int.h | 3 +- hw/vmware_vga.c | 7 ++-- monitor.c| 6 qapi-schema.json | 24 + qemu-common.h| 7 qerror.c | 28 ++-- qerror.h | 22 ++-- qmp-commands.hx | 5 +-- 20 files changed, 390 insertions(+), 95 deletions(-)
Re: [Qemu-devel] [PATCH v2] hmp/qxl: info spice: add qxl info
On Fri, May 25, 2012 at 11:43:11AM -0300, Luiz Capitulino wrote:
On Thu, 24 May 2012 19:22:52 +0300
Alon Levy al...@redhat.com wrote:
For all devices print id, mode and guest_bug status.
Is qxl really tied to spice? In the meaning that it's impossible to use it
without spice? Wouldn't it be better to have 'info display' instead?
Would a patch implementing 'info display' require me to implement it for
all displays?
Known problems: Prints devices from highest id to lowest.
That's because qapi lists usually inserts new items at the head. You could
add them at the tail instead. Requires more code, but works.
Right, I didn't think it was a real enough problem to fix.
Signed-off-by: Alon Levy al...@redhat.com
---
This one builds. Fixed qapi-schema to say additions are for 1.2
hmp.c| 11 +++
hw/qxl.c | 22 ++
qapi-schema.json | 47 +--
ui/qemu-spice.h |5 +
ui/spice-core.c | 48 +++-
5 files changed, 130 insertions(+), 3 deletions(-)
diff --git a/hmp.c b/hmp.c
index bb0952e..5126921 100644
--- a/hmp.c
+++ b/hmp.c
@@ -331,6 +331,7 @@ void hmp_info_spice(Monitor *mon)
{
SpiceChannelList *chan;
SpiceInfo *info;
+QXLInfoList *qxl;
info = qmp_query_spice(NULL);
@@ -353,6 +354,16 @@ void hmp_info_spice(Monitor *mon)
monitor_printf(mon, mouse-mode: %s\n,
SpiceQueryMouseMode_lookup[info-mouse_mode]);
+for (qxl = info-qxl; qxl; qxl = qxl-next) {
+if (qxl-value-guest_bug == -1 || qxl-value-mode == -1) {
+continue;
+}
+monitor_printf(mon, qxl-%PRId64:\n, qxl-value-id);
+monitor_printf(mon, mode: %s\n,
+SpiceQueryQXLMode_lookup[qxl-value-mode]);
+monitor_printf(mon,guest_bug: %PRIu64\n,
qxl-value-guest_bug);
+}
+
if (!info-has_channels || info-channels == NULL) {
monitor_printf(mon, Channels: none\n);
} else {
diff --git a/hw/qxl.c b/hw/qxl.c
index b5e53ce..21c825c 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1711,6 +1711,28 @@ static DisplayChangeListener display_listener = {
.dpy_refresh = display_refresh,
};
+/* helpers for spice_info */
+int qxl_get_guest_bug(DeviceState *dev)
+{
+PCIQXLDevice *qxl = DO_UPCAST(PCIQXLDevice, pci.qdev, dev);
+
+return qxl-guest_bug;
+}
+
+int qxl_get_mode(DeviceState *dev)
+{
+PCIQXLDevice *qxl = DO_UPCAST(PCIQXLDevice, pci.qdev, dev);
+
+return qxl-mode;
+}
+
+int qxl_get_id(DeviceState *dev)
+{
+PCIQXLDevice *qxl = DO_UPCAST(PCIQXLDevice, pci.qdev, dev);
+
+return qxl-id;
+}
+
static void qxl_init_ramsize(PCIQXLDevice *qxl, uint32_t ram_min_mb)
{
/* vga ram (bar 0) */
diff --git a/qapi-schema.json b/qapi-schema.json
index 2ca7195..af1fac2 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -638,7 +638,7 @@
##
# @SpiceQueryMouseMode
#
-# An enumation of Spice mouse states.
+# An enumeration of Spice mouse states.
#
# @client: Mouse cursor position is determined by the client.
#
@@ -655,6 +655,44 @@
'data': [ 'client', 'server', 'unknown' ] }
##
+# @SpiceQueryQXLMode
+#
+# An enumeration of QXL States.
+#
+# @undefined: guest driver in control but no primary device. Reached after
a destroy primary IO
+# from native mode.
+#
+# @vga: no device driver in control. default mode, returns to it after any
vga port access.
+#
+# @compat: No information is available about mouse mode used by
+# the spice server.
+#
+# @native: guest driver in control of device. Reached after a create
primary IO.
+#
+# Note: hw/qxl.h has a qxl_mode enum, name chose to not confuse the two.
+#
+# Since: 1.2
+##
+{ 'enum': 'SpiceQueryQXLMode',
+ 'data': [ 'undefined', 'vga', 'compat', 'native' ] }
+
+##
+# @QXLInfo
+#
+# Information about a QXL device.
+#
+# @id: qxl id, non negative integer, 0 for primary device.
+#
+# @guest_bug: Has a guest error been detected.
+#
+# @mode: Mode of device, based on guest activity.
+#
+# Since: 1.2
+##
+{ 'type': 'QXLInfo',
+ 'data': {'id': 'int', 'guest_bug': 'int', 'mode': 'SpiceQueryQXLMode'} }
+
+##
# @SpiceInfo
#
# Information about the SPICE session.
@@ -683,12 +721,17 @@
#
# @channels: a list of @SpiceChannel for each active spice channel
#
+# @qxl: a list of @QXLInfo for each qxl device
+#
+# Since: 1.2
+#
# Since: 0.14.0
##
{ 'type': 'SpiceInfo',
'data': {'enabled': 'bool', '*host': 'str', '*port': 'int',
'*tls-port': 'int', '*auth': 'str', '*compiled-version': 'str',
- 'mouse-mode': 'SpiceQueryMouseMode', '*channels':
Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On (Mon) 28 May 2012 [09:33:57], Daniel P. Berrange wrote:
On Sat, May 26, 2012 at 01:02:49AM +0530, Amit Shah wrote:
The Linux kernel already has a virtio-rng driver, this is the device
implementation.
When the guest asks for entropy from the virtio hwrng, it puts a buffer
in the vq. We then put entropy into that buffer, and push it back to
the guest.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo /dev/urandom
ACK to this ARGV design from a libvirt POV.
A QMP event is sent for interested apps to monitor activity and send the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
IIUC, there are three ways mgmt apps can use the RNG with the
chardev
- Wire it up to a source that just blindly provides all the
entropy QEMU desires (as you /dev/urandom example above)
- Feed in a fixed amount of entropy every minute, regardless
of how much QEMU desires
This option currently won't do anything -- i.e. till the guest sends
across a buffer to be filled in, nothing will go to the guest, and the
data will just be buffered in the chardev layer till such a buffer
comes along. It can be debatable on feeding entropy by pushing every
particular timeout, or just providing the freshest on-demand.
Advantage could be we have more random bits, disadvantage is this
could be throttled as the host went out of enough entropy.
- Feed in entropy on demand, in response to the ENTROPY_NEEDED
event notification (possibly throttling)
These options sounds like they should cover all reasonable needs,
so gets my vote.
Great!
Probably want to include the ENTROPY_NEEDED
event in my patch which adds rate limiting to guest initiated
events.
Yes, just depends in which order the patches go in.
Thanks,
Amit
Re: [Qemu-devel] [ANNOUNCE] qemu-kvm-1.1-rc3
On 05/25/2012 11:36 AM, Veruca Salt wrote: Avi- would love to test out 1.1, as we are currently using the ehci method which has been frozen at 'experimental' for so long. Is there any user documentation on the xhci methods? Copying qemu-devel, where someone may know the answer. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] TCG: Fix TB invalidation after breakpoint insertion/deletion
On 05/24/2012 10:58 PM, Max Filippov wrote: On Thu, May 24, 2012 at 6:26 PM, Avi Kivity a...@redhat.com wrote: On 05/24/2012 05:11 PM, Max Filippov wrote: Not in breakpoint_invalidate as the missing offset was compensated before your commit (well, starting with c2f07f81a2 in fact). I'd say that compensation that you mention ram_addr = (memory_region_get_ram_addr(section.mr) + section.offset_within_region) TARGET_PAGE_MASK; this ram_addr |= (pc ~TARGET_PAGE_MASK); tb_invalidate_phys_page_range(ram_addr, ram_addr + 1, 0); was removed by f3705d53296d, not by 1e7855a558 Indeed. Note how the |= cleverly accommodates both truncating and non-truncating cpu_get_phys_page_debug(). Right. If the fix is going to be checked in then TeLeMan's original version with '|' is preferable for this reason. I disagree. Whatever we call cpu_get_phys_page_debug() has to either mask out the low bits, or not (I prefer the latter, since it's unambiguous for large pages), but it has to be consistent. Once it's consistent, there's no reason to use clever tricks. -- error compiling committee.c: too many arguments to function
[Qemu-devel] cpsr_write...
Hi!!! 1)How can I use cpsr_write(var, tmp_mask) in qemu- arm(user mode)?? 2)What are var and tmp_mask?? 3)How does QEMU use cpsr register in sigle step mode??
Re: [Qemu-devel] [PATCH v2] net: add the support for -netdev socket, listen
On Mon, May 28, 2012 at 03:49:11PM +0800, Zhi Yong Wu wrote: On Sun, Feb 26, 2012 at 10:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sat, Feb 18, 2012 at 9:19 AM, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com The -net socket,listen option does not work with the newer -netdev syntax: http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01508.html This patch makes it work now. Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- net.c | 26 + net.h | 2 + net/socket.c | 72 +- 3 files changed, 84 insertions(+), 16 deletions(-) I wanted to understand the problem better so I tried out -net socket,listen=. Here is its behavior: 1. A client can connect to QEMU, this creates a new socket VLANClientState on the VLAN. 2. If another client connects to QEMU, another VLANClientState is created. That means many socket clients can be added to the same VLAN. 3. When a simple TCP client like netcat connects and then disconnects, the VLANClientState remains forever. There seems to be no cleanup. This patch does not handle the -net socket,listen= case where multiple clients connect. Also, the -netdev socket,listen= semantics cannot match -net socket-listen= semantics because there is only one peer at any time. Some options: 1. Do not accept new connections while a client is connected. Once the client disconnects we can accept a new connection. This maintains the 1-1 peer behavior. 2. Integrate with vlan-hub so that multiple clients can connect even with -netdev. Connections will create new NetClientStates and auto-attach to the hub. This mimics -net socket,listen= but requires a hub to be used. 3. Forbid -netdev socket,listen=, only allow -net socket,listen=. I think #1 would be okay, although it no longer allows multiple connections, but I don't have a strong opinion either way. Now i prefer to support #2. Do you think of it? Should the usage -netdev socket,listen also been supported or forbidden? As you said, -netdev only has one peer, so their usage will be a bit different. I'm not sure how useful the multiple connections behavior is. Since -netdev socket,listen= has not worked in the past we have the freedom to decide how it should work (without breaking existing users' setups). Several folks have pointed out that vde or other external programs are better for virtual hubs/switches. I would implement #1 because it adds useful behavior but doesn't complicate QEMU much. But if you feel adding #2 would be worthwhile and not a big effort to code, then go ahead. My intuition is that #1 will be easier to get merged and can be extended to support #2 in the future, if necessary. Stefan
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Fri, May 25, 2012 at 10:56:28AM -0300, Luiz Capitulino wrote: On Fri, 25 May 2012 15:47:28 +0200 Paolo Bonzini pbonz...@redhat.com wrote: Il 25/05/2012 15:43, Luiz Capitulino ha scritto: Yeah, VDE probably includes something like an hub. But then we could drop even -net socket, -net udp, -net dump, and only leave in vde+tap+slirp. Or even move slirp into VDE. :) That's a very different thing. Let's start with what is hurting us. But is it? The patch makes it quite clean. vlan is and the cleanest solution is to drop it. For the sake of the argument, here's what we'd need: 1. Patches to remove vlan completely from QEMU. 2. net/dump.c alternative. Packet capture could be done like this: -netdev tap,dump=capture.pcap,... You specify the dump option on a netdev giving a filename to use for the pcap file. The net/dump.c would need to be called from net.c or maybe net/queue.c. What we need to decide is whether it's okay to drop QEMU VLANs completely and change dump command-line syntax? I think vlan-hub doesn't hurt anyone because the code has been isolated and we keep backwards compatibility. So I'd personally still go the vlan-hub route for QEMU 1.x. Stefan
Re: [Qemu-devel] [PATCH for-1.1?] slirp: Avoid redefining MAX_TCPOPTLEN
On 2012-05-27 14:02, Andreas Färber wrote:
MAX_TCPOPTLEN is being defined as 32. Darwin has it as 40, causing a
warning. The value is only used to declare an array, into which currently
4 bytes are written at most. It should therefore be acceptable to adopt
the host's definition.
Therefore only define MAX_TCPOPTLEN if not already defined.
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
slirp/tcp_output.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/slirp/tcp_output.c b/slirp/tcp_output.c
index 779314b..9815123 100644
--- a/slirp/tcp_output.c
+++ b/slirp/tcp_output.c
@@ -47,7 +47,9 @@ static const u_char tcp_outflags[TCP_NSTATES] = {
};
+#ifndef MAX_TCPOPTLEN
#define MAX_TCPOPTLEN32 /* max # bytes that go in options */
+#endif
/*
* Tcp output routine: figure out what should be sent and send it.
Let's be conservative for 1.1 and do #undef MAX_TCPOPTLEN instead. Does
this work as well?
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH for-1.1] slirp: Untangle TCPOLEN_* from TCPOPT_*
On 2012-05-27 19:43, Andreas Färber wrote: Am 28.04.2012 00:29, schrieb Andreas Färber: From: Andreas Färber andreas.faer...@web.de Commit b72210568ef0c0fb141a01cffb71a09c4efa0364 (slirp: clean up conflicts with system headers) enclosed TCPOLEN_MAXSEG with an #ifdef TCPOPT_EOL. This broke the build on illumos, which has TCPOPT_* but not TCPOLEN_*. Move them to their own #ifdef TCPOLEN_MAXSEG section to remedy this. Cc: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Andreas Färber andreas.faer...@web.de Ping! It seems this patch has not been applied yet despite agreement between Blue and Jan that we should apply this least-invasive version for 1.1. Please apply / include in a PULL for rc4. Thanks, queued for 1.1. I'll send a pull as soon as the other small build fixes are available. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH for-1.1? v2] slirp: Avoid statements without effect on Big Endian host
On 2012-05-28 00:10, Peter Maydell wrote:
On 27 May 2012 17:42, Andreas Färber andreas.faer...@web.de wrote:
+# if defined(__APPLE__)
+# undef NTOHL
+# undef NTOHS
+# undef HTONL
+# undef HTONS
+# define NTOHL(d) do { } while (0)
+# define NTOHS(d) do { } while (0)
+# define HTONL(d) do { } while (0)
+# define HTONS(d) do { } while (0)
+# else
We could just use this for everything, not just if __APPLE__,
right? For big-endian the semantics we want are always do
nothing so it's always OK to undef and redefine...
That would save having a special case.
Yes, please.
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] TCG: Fix TB invalidation after breakpoint insertion/deletion
On Mon, May 28, 2012 at 1:34 PM, Avi Kivity a...@redhat.com wrote: On 05/24/2012 10:58 PM, Max Filippov wrote: On Thu, May 24, 2012 at 6:26 PM, Avi Kivity a...@redhat.com wrote: On 05/24/2012 05:11 PM, Max Filippov wrote: Not in breakpoint_invalidate as the missing offset was compensated before your commit (well, starting with c2f07f81a2 in fact). I'd say that compensation that you mention ram_addr = (memory_region_get_ram_addr(section.mr) + section.offset_within_region) TARGET_PAGE_MASK; this ram_addr |= (pc ~TARGET_PAGE_MASK); tb_invalidate_phys_page_range(ram_addr, ram_addr + 1, 0); was removed by f3705d53296d, not by 1e7855a558 Indeed. Note how the |= cleverly accommodates both truncating and non-truncating cpu_get_phys_page_debug(). Right. If the fix is going to be checked in then TeLeMan's original version with '|' is preferable for this reason. I disagree. Whatever we call cpu_get_phys_page_debug() has to either mask out the low bits, or not (I prefer the latter, since it's unambiguous for large pages), but it has to be consistent. Once it's consistent, there's no reason to use clever tricks. I meant a one line fix for the 1.1. I suspect that fixing entire cpu_get_phys_page_debug thing for 1.1 is too risky. -- Thanks. -- Max
Re: [Qemu-devel] [PATCH 4/4] ISCSI: If the device we open is a SMC device, then force the use of sg. We dont have any medium changer emulation so only passthrough via real sg or scsi-generic via iscsi
Paolo
I think I have seen a problem inside libiscsi that could be triggered
by the shortcut.
Can you remove this shortcut completely :
-/* Try to write as much as we can to the socket
- * without setting up an event.
- * Only do this if we are completely logged in, so we know that
- * the socket is in connected state.
- */
-if (iscsi_is_logged_in(iscsi)) {
-if (iscsi_which_events(iscsi) POLLOUT) {
-iscsi_process_write(iscsilun);
-}
-}
I think there is a problem inside libiscsi if the socket becomes full
and is no longer writeable and we try to write via this shortcurcuit.
It will take a while until I can verify or fix that issue and before a
new version of libiscsi can be available
so I would feel most comfortable with if we just remove this
optimization from QEMU for now.
It can be added back later once libiscsi is fixed.
regards
ronnie sahlberg
On Mon, May 28, 2012 at 4:48 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 27/05/2012 15:12, Andreas Färber ha scritto:
Modified to also do the same for tapes, applied to scsi-next branch for
1.2.
Paolo, it seems you haven't pushed scsi-next since then.
Yeah, I have a pending push request for scsi-next, so I'm waiting till
Anthony applies it before pushing 1.2-only patches (I wasn't expecting
parallel 1.1/1.2 development for SCSI).
I hope you've
also shortened the subject to a humanly bearable length?
Yes. :)
Paolo
Re: [Qemu-devel] [PATCH for-1.1? v2] slirp: Avoid statements without effect on Big Endian host
On 28 May 2012 12:47, Jan Kiszka jan.kis...@web.de wrote:
On 2012-05-28 00:10, Peter Maydell wrote:
On 27 May 2012 17:42, Andreas Färber andreas.faer...@web.de wrote:
+# if defined(__APPLE__)
+# undef NTOHL
+# undef NTOHS
+# undef HTONL
+# undef HTONS
+# define NTOHL(d) do { } while (0)
+# define NTOHS(d) do { } while (0)
+# define HTONL(d) do { } while (0)
+# define HTONS(d) do { } while (0)
+# else
We could just use this for everything, not just if __APPLE__,
right? For big-endian the semantics we want are always do
nothing so it's always OK to undef and redefine...
That would save having a special case.
Yes, please.
It occurred to me that you could also have the unconditional
#undefs outside the #ifdef HOST_WORDS_BIGENDIAN, but that
is starting to stray outside of the simple fix for 1.1
territory.
-- PMM
Re: [Qemu-devel] [PATCH] TCG: Fix TB invalidation after breakpoint insertion/deletion
On 05/28/2012 02:54 PM, Max Filippov wrote: Right. If the fix is going to be checked in then TeLeMan's original version with '|' is preferable for this reason. I disagree. Whatever we call cpu_get_phys_page_debug() has to either mask out the low bits, or not (I prefer the latter, since it's unambiguous for large pages), but it has to be consistent. Once it's consistent, there's no reason to use clever tricks. I meant a one line fix for the 1.1. I suspect that fixing entire cpu_get_phys_page_debug thing for 1.1 is too risky. Agree for 1.1. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 4/4] ISCSI: If the device we open is a SMC device, then force the use of sg. We dont have any medium changer emulation so only passthrough via real sg or scsi-generic via iscsi
Il 28/05/2012 13:55, ronnie sahlberg ha scritto:
Paolo
I think I have seen a problem inside libiscsi that could be triggered
by the shortcut.
Can you remove this shortcut completely :
-/* Try to write as much as we can to the socket
- * without setting up an event.
- * Only do this if we are completely logged in, so we know that
- * the socket is in connected state.
- */
-if (iscsi_is_logged_in(iscsi)) {
-if (iscsi_which_events(iscsi) POLLOUT) {
-iscsi_process_write(iscsilun);
-}
-}
I think there is a problem inside libiscsi if the socket becomes full
and is no longer writeable and we try to write via this shortcurcuit.
It will take a while until I can verify or fix that issue and before a
new version of libiscsi can be available
so I would feel most comfortable with if we just remove this
optimization from QEMU for now.
It can be added back later once libiscsi is fixed.
Done. Rebased scsi-next, new commit is
f4dfa67f04037c1b1a8f4e4ddc944c5ab308f35b.
Paolo
Re: [Qemu-devel] [PATCH] block: prevent snapshot mode $TMPDIR symlink attack
On Mon, May 28, 2012 at 8:27 AM, Jim Meyering j...@meyering.net wrote:
diff --git a/block/vvfat.c b/block/vvfat.c
index 2dc9d50..0fd3367 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -2808,7 +2808,12 @@ static int enable_write_target(BDRVVVFATState *s)
array_init((s-commits), sizeof(commit_t));
s-qcow_filename = g_malloc(1024);
- get_tmp_filename(s-qcow_filename, 1024);
+ ret = get_tmp_filename(s-qcow_filename, 1024);
+ if (ret 0) {
+ g_free(s-qcow_filename);
+ s-qcow_filename = NULL;
+ return ret;
+ }
It appears that s-used_clusters gets leaked in vvfat. This can be
addressed in a separate patch since other codepaths also leak it.
Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Re: [Qemu-devel] [PATCH for-1.1] virtio-blk: Fix unused variables in virtio_blk_handle_scsi()
On Sun, May 27, 2012 at 3:41 PM, Andreas Färber andreas.faer...@web.de wrote: Commit f34e73cd69bdbdb9b1d56b288c5e14d6fff58165 (virtio-blk: report non-zero status when failing SG_IO requests) exposed the function to non-Linux guests. Move all Linux-only variable declarations into an #ifdef in the variable declaration block. Signed-off-by: Andreas Färber andreas.faer...@web.de Cc: Paolo Bonzini pbonz...@redhat.com --- hw/virtio-blk.c | 6 -- 1 files changed, 4 insertions(+), 2 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Re: [Qemu-devel] Android Goldfish on QEMU
On Sat, May 26, 2012 at 2:25 PM, 陳韋任 che...@iis.sinica.edu.tw wrote: On Sat, May 26, 2012 at 02:51:29PM +0200, Andreas Färber wrote: Am 26.05.2012 07:55, schrieb 陳韋任: On Fri, May 25, 2012 at 06:13:25PM -0400, Ira Ray Jenkins wrote: I found a GSOC11 project that attempted to port the Android Goldfish platform to mainline QEMU. Was this project successful, or is this currently being worked on? The author sent the patchset last year [1], but apparently it not get merged into trunk. I don't know why. :) Presumably because the student didn't react to any of the review comments and never sent a fixed v2. It would be great if we can bring it back. ;) Is goldfish still a relevant Android dev platform? In other words - would goldfish be useful to Android developers or just cool for QEMU hackers and old-school Android enthusiasts? Stefan
Re: [Qemu-devel] Tracing message for mu
On Sat, May 26, 2012 at 7:50 AM, Charles.Tsai-蔡清海-研究發展部 charles.t...@cloudena.com wrote: Hans replied me back and he suggested me to use strace. Hopefully, this issue can be resolved. Additionally, we encountered a tough issue right now. When we ran a 64-bit Windows 7 VM overnight, the kvm process was killed for some reasons. Here is the qemu version I copied from the screen QEMU emulator version 1.0 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The Qemu source is from Hans. Any suggestion to attack this issue? Next time ensure that core dumps are enabled: $ ulimit -c unlimited # enable core dumps $ qemu-kvm ... If it crashes you'll have a core file that the gdb debugger can process. It's also worth checking dmesg(1) output to see if your system ran out of memory and the kernel killed the qemu-kvm process to free memory. Hope this helps, Stefan
Re: [Qemu-devel] Virtio-pci issue
On Thu, May 24, 2012 at 4:18 AM, Evgeny Voevodin e.voevo...@samsung.com wrote: And also there is another problem that I've faced with. It is the ability to plug as many pci back-ends as board wants. I mean that if for each back-end board should create a transport, then user have to know maximum number of transport instances created by board. In the case of mmio transport I think that it's a correct behaviour, but for pci transport seems not. Not sure I understand the problem. Can you rephrase it? Stefan
Re: [Qemu-devel] [PATCH 1.1] virtio: Fix compiler warning for non Linux hosts
On Wed, May 23, 2012 at 5:03 PM, Stefan Weil s...@weilnetz.de wrote: Am 23.05.2012 17:32, schrieb Kevin Wolf: Am 23.05.2012 17:29, schrieb Stefan Weil: Am 23.05.2012 10:09, schrieb Stefan Hajnoczi: On Tue, May 22, 2012 at 10:23 PM, Stefan Weils...@weilnetz.de wrote: The local variables ret, i are only used if __linux__ is defined. Signed-off-by: Stefan Weils...@weilnetz.de --- hw/virtio-blk.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) The #ifdef __linux__ further down in the function declares the local hdr variable. We could move ret and i down into the #ifdef instead of adding a new one. I noticed that, but declaring variables anywhere is C++, not C code. It's called C99. Kevin Maybe, but I already had patches rejected because of that style. Did this policy change? I'd appreciate that! Agreed, people have been asked to declare variables at the beginning of the scope. I don't understand why, C99 allows them to be declared anywhere and it usually makes the code more readable IMO (you don't have to jump to the definition to check a variable's type). What's the problem with C99-style variable declarations anywhere in a function? Stefan
Re: [Qemu-devel] [RFC PATCH] vfio: add fixup for broken PCI devices
On Fri, May 25, 2012 at 05:35:03PM +1000, Alexey Kardashevskiy wrote:
Some adapters (like NEC PCI USB controller) do not flush their config
on a sioftware reset and remember DMA config, etc.
If we use such an adapter with QEMU, then crash QEMU (stop it with
ctrl-A ctrl-X), and try to use it in QEMU again, it may start working
immediately with previous config when pci_enable_device() is called
on that PCI function.
To eliminate such effect, some quirk should be called. The proposed
pci_fixup_final does its job well for mentioned NEC PCI USB but not
sure if it is 100% correct.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
Won't current kvm device assignment be affected by this?
If yes need to address that not just vfio.
---
drivers/vfio/pci/vfio_pci.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 1e5315c..6e7c12d 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -88,6 +88,8 @@ static void vfio_pci_disable(struct vfio_pci_device *vdev)
{
int bar;
+ pci_fixup_device(pci_fixup_final, vdev-pdev);
+
pci_disable_device(vdev-pdev);
vfio_pci_set_irqs_ioctl(vdev, VFIO_IRQ_SET_DATA_NONE |
--
1.7.7.3
Re: [Qemu-devel] [PATCH 1.1] virtio: Fix compiler warning for non Linux hosts
On Mon, May 28, 2012 at 01:39:58PM +0100, Stefan Hajnoczi wrote:
On Wed, May 23, 2012 at 5:03 PM, Stefan Weil s...@weilnetz.de wrote:
Am 23.05.2012 17:32, schrieb Kevin Wolf:
Am 23.05.2012 17:29, schrieb Stefan Weil:
Am 23.05.2012 10:09, schrieb Stefan Hajnoczi:
On Tue, May 22, 2012 at 10:23 PM, Stefan Weils...@weilnetz.de wrote:
The local variables ret, i are only used if __linux__ is defined.
Signed-off-by: Stefan Weils...@weilnetz.de
---
hw/virtio-blk.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
The #ifdef __linux__ further down in the function declares the local
hdr variable. We could move ret and i down into the #ifdef instead of
adding a new one.
I noticed that, but declaring variables anywhere is C++, not C code.
It's called C99.
Kevin
Maybe, but I already had patches rejected because of that style.
Did this policy change? I'd appreciate that!
Agreed, people have been asked to declare variables at the beginning
of the scope. I don't understand why, C99 allows them to be declared
anywhere and it usually makes the code more readable IMO (you don't
have to jump to the definition to check a variable's type).
What's the problem with C99-style variable declarations anywhere in a
function?
Not an issue in this particular patch, but declaration at point of
first use can cause you problems if the code uses 'goto' alot (eg
for return cleanup).
eg
void somefunc(void) {
...some code...
if (...something bad...)
goto cleanup;
... some code...
char *bar = NULL;
bar = strdup(Hello World);
...some code...
cleanup:
free(bar);
}
In that 'cleanup' label 'bar' will potentially be uninitialized,
because it is in scope, but the line where initialization takes
place may never been reached.
So if you do decide to make use of C99 style decl at first use,
then be sure to turn on the GCC warnings to detect these variable
initialization problems.
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] [RFC PATCH] vfio: add fixup for broken PCI devices
On 2012-05-28 14:44, Michael S. Tsirkin wrote: On Fri, May 25, 2012 at 05:35:03PM +1000, Alexey Kardashevskiy wrote: Some adapters (like NEC PCI USB controller) do not flush their config on a sioftware reset and remember DMA config, etc. If we use such an adapter with QEMU, then crash QEMU (stop it with ctrl-A ctrl-X), and try to use it in QEMU again, it may start working immediately with previous config when pci_enable_device() is called on that PCI function. To eliminate such effect, some quirk should be called. The proposed pci_fixup_final does its job well for mentioned NEC PCI USB but not sure if it is 100% correct. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Won't current kvm device assignment be affected by this? Would be surprising if not. If yes need to address that not just vfio. A reason to solve this at PCI level? Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 1.1] virtio: Fix compiler warning for non Linux hosts
On 28 May 2012 13:39, Stefan Hajnoczi stefa...@gmail.com wrote: Agreed, people have been asked to declare variables at the beginning of the scope. I don't understand why, C99 allows them to be declared anywhere and it usually makes the code more readable IMO (you don't have to jump to the definition to check a variable's type). If the definition is that far away from the use it's probably a sign that your function is too large anyway and you should be looking for a smaller scope within which to declare the variable... What's the problem with C99-style variable declarations anywhere in a function? I think they look slightly uglier but that's purely a personal prejudice which I don't think I can justify imposing on anybody else :-) -- PMM
Re: [Qemu-devel] [PATCH 14/14] qapi: convert screendump
On Mon, 28 May 2012 11:56:31 +0300
Alon Levy al...@redhat.com wrote:
On Fri, May 25, 2012 at 04:41:19PM -0300, Luiz Capitulino wrote:
One small note below.
Also activates error reporting from devices.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
console.c| 7 ---
console.h| 1 -
hmp-commands.hx | 5 ++---
hmp.c| 9 +
hmp.h| 1 +
monitor.c| 6 --
qapi-schema.json | 24
qmp-commands.hx | 5 +
8 files changed, 41 insertions(+), 17 deletions(-)
diff --git a/console.c b/console.c
index 4669e62..2bbf104 100644
--- a/console.c
+++ b/console.c
@@ -24,6 +24,7 @@
#include qemu-common.h
#include console.h
#include qemu-timer.h
+#include qmp-commands.h
//#define DEBUG_CONSOLE
#define DEFAULT_BACKSCROLL 512
@@ -173,7 +174,7 @@ void vga_hw_invalidate(void)
active_console-hw_invalidate(active_console-hw);
}
-void vga_hw_screen_dump(const char *filename)
+void qmp_screendump(const char *filename, Error **errp)
{
TextConsole *previous_active_console;
bool cswitch;
@@ -187,9 +188,9 @@ void vga_hw_screen_dump(const char *filename)
console_select(0);
}
if (consoles[0] consoles[0]-hw_screen_dump) {
-consoles[0]-hw_screen_dump(consoles[0]-hw, filename, cswitch,
NULL);
+consoles[0]-hw_screen_dump(consoles[0]-hw, filename, cswitch,
errp);
} else {
-error_report(screen dump not implemented);
+error_set(errp, QERR_NOT_SUPPORTED);
}
if (cswitch) {
diff --git a/console.h b/console.h
index 9caeb43..d72c546 100644
--- a/console.h
+++ b/console.h
@@ -356,7 +356,6 @@ DisplayState *graphic_console_init(vga_hw_update_ptr
update,
void vga_hw_update(void);
void vga_hw_invalidate(void);
-void vga_hw_screen_dump(const char *filename);
void vga_hw_text_update(console_ch_t *chardata);
int is_graphic_console(void);
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 18cb415..74f61bc 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -193,9 +193,8 @@ ETEXI
.name = screendump,
.args_type = filename:F,
.params = filename,
-.help = save screen into PPM image 'filename',
-.user_print = monitor_user_noop,
-.mhandler.cmd_new = do_screen_dump,
+.help = save screen into PPM image 'filepath',
+.mhandler.cmd = hmp_screen_dump,
},
STEXI
diff --git a/hmp.c b/hmp.c
index bb0952e..7e8c0ab 100644
--- a/hmp.c
+++ b/hmp.c
@@ -947,3 +947,12 @@ void hmp_device_del(Monitor *mon, const QDict *qdict)
qmp_device_del(id, err);
hmp_handle_error(mon, err);
}
+
+void hmp_screen_dump(Monitor *mon, const QDict *qdict)
+{
+const char *filename = qdict_get_str(qdict, filename);
+Error *err = NULL;
+
+qmp_screendump(filename, err);
+hmp_handle_error(mon, err);
+}
diff --git a/hmp.h b/hmp.h
index 443b812..fa75ec0 100644
--- a/hmp.h
+++ b/hmp.h
@@ -61,5 +61,6 @@ void hmp_block_job_set_speed(Monitor *mon, const QDict
*qdict);
void hmp_block_job_cancel(Monitor *mon, const QDict *qdict);
void hmp_migrate(Monitor *mon, const QDict *qdict);
void hmp_device_del(Monitor *mon, const QDict *qdict);
+void hmp_screen_dump(Monitor *mon, const QDict *qdict);
#endif
diff --git a/monitor.c b/monitor.c
index 12a6fe2..1160af7 100644
--- a/monitor.c
+++ b/monitor.c
@@ -897,12 +897,6 @@ static int client_migrate_info(Monitor *mon, const
QDict *qdict,
return -1;
}
-static int do_screen_dump(Monitor *mon, const QDict *qdict, QObject
**ret_data)
-{
-vga_hw_screen_dump(qdict_get_str(qdict, filename));
-return 0;
-}
-
static void do_logfile(Monitor *mon, const QDict *qdict)
{
cpu_set_log_filename(qdict_get_str(qdict, filename));
diff --git a/qapi-schema.json b/qapi-schema.json
index 2ca7195..43d4acd 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1755,3 +1755,27 @@
# Since: 0.14.0
##
{ 'command': 'device_del', 'data': {'id': 'str'} }
+
+##
+# @screendump:
+#
+# Write a PPM of the VGA screen to a file.
+#
+# @filename: the path of a new PPM file to store the image
+#
+# Since: 0.14.0
+#
+# Returns: Nothing on success
+# If the underlying device doesn't support screen dump, NotSupported
+# If access to the file is not allowed, InvalidAccess
+# If QEMU has too many open files, TooManyFilesByProcess
+# If the system has too many open files, TooManyFilesInSystem
+# If @filename is too long, NameTooLong
+# If the system doesn't have enough space, NoSpace
+# If the file-system to write the file to is read-only,
ReadOnlyFileSystem
+# If opening @filename fails for an uknown reason,
Re: [Qemu-devel] [PATCH v2] hmp/qxl: info spice: add qxl info
On Mon, 28 May 2012 12:08:13 +0300 Alon Levy al...@redhat.com wrote: On Fri, May 25, 2012 at 11:43:11AM -0300, Luiz Capitulino wrote: On Thu, 24 May 2012 19:22:52 +0300 Alon Levy al...@redhat.com wrote: For all devices print id, mode and guest_bug status. Is qxl really tied to spice? In the meaning that it's impossible to use it without spice? Wouldn't it be better to have 'info display' instead? Would a patch implementing 'info display' require me to implement it for all displays? Would be nice, even if we start with very basic information.
Re: [Qemu-devel] [PATCH v2] net: add the support for -netdev socket, listen
On Mon, May 28, 2012 at 6:51 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Mon, May 28, 2012 at 03:49:11PM +0800, Zhi Yong Wu wrote: On Sun, Feb 26, 2012 at 10:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sat, Feb 18, 2012 at 9:19 AM, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com The -net socket,listen option does not work with the newer -netdev syntax: http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01508.html This patch makes it work now. Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- net.c | 26 + net.h | 2 + net/socket.c | 72 +- 3 files changed, 84 insertions(+), 16 deletions(-) I wanted to understand the problem better so I tried out -net socket,listen=. Here is its behavior: 1. A client can connect to QEMU, this creates a new socket VLANClientState on the VLAN. 2. If another client connects to QEMU, another VLANClientState is created. That means many socket clients can be added to the same VLAN. 3. When a simple TCP client like netcat connects and then disconnects, the VLANClientState remains forever. There seems to be no cleanup. This patch does not handle the -net socket,listen= case where multiple clients connect. Also, the -netdev socket,listen= semantics cannot match -net socket-listen= semantics because there is only one peer at any time. Some options: 1. Do not accept new connections while a client is connected. Once the client disconnects we can accept a new connection. This maintains the 1-1 peer behavior. 2. Integrate with vlan-hub so that multiple clients can connect even with -netdev. Connections will create new NetClientStates and auto-attach to the hub. This mimics -net socket,listen= but requires a hub to be used. 3. Forbid -netdev socket,listen=, only allow -net socket,listen=. I think #1 would be okay, although it no longer allows multiple connections, but I don't have a strong opinion either way. Now i prefer to support #2. Do you think of it? Should the usage -netdev socket,listen also been supported or forbidden? As you said, -netdev only has one peer, so their usage will be a bit different. I'm not sure how useful the multiple connections behavior is. Since -netdev socket,listen= has not worked in the past we have the freedom to decide how it should work (without breaking existing users' setups). Several folks have pointed out that vde or other external programs are better for virtual hubs/switches. I would implement #1 because it adds useful behavior but doesn't complicate QEMU much. But if you feel adding #2 would be worthwhile and not a big effort to code, then go ahead. My intuition is that #1 will be easier to get merged and can be extended to support #2 in the future, if necessary. OK. i will try. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH 5/9] unicore32-softmmu: initialize ucv2 cpu
Am 28.05.2012 11:43, schrieb guanxue...@mprc.pku.edu.cn: Am 25.05.2012 13:29, schrieb Guan Xuetao: Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn --- target-unicore32/cpu.c | 17 + target-unicore32/cpu.h |2 +- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c index de63f58..62c0a22 100644 --- a/target-unicore32/cpu.c +++ b/target-unicore32/cpu.c @@ -32,13 +32,16 @@ static void unicore_ii_cpu_initfn(Object *obj) UniCore32CPU *cpu = UNICORE32_CPU(obj); CPUUniCore32State *env = cpu-env; -env-cp0.c0_cpuid = 0x40010863; +env-cp0.c0_cpuid = UC32_CPUID_UCV2; Please don't revert this change. I'll send you the patch to drop the CPUID #defines instead. But, the kernel need this CPUID to check whether it is a unicore32 processor, and if check fail, the kernel will halt. I'm not discussing about a guest kernel but about your source change above: The UC32_CPUID_UC32 #define should go away, i.e. please ack (today, if we want it in 1.1) and prepend my patch, and if the value is wrong here it should be changed *here* and not in UC32_CPUID_UCV2. If you're introducing new uses of UC32_CPUID_UCV2 elsewhere (e.g., for register behavior) then that is a design fault and needs to be fixed. Compare the copro series for target-arm, which gets rid of the CPUID-based switches there. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [RFC PATCH] vfio: add fixup for broken PCI devices
On Mon, May 28, 2012 at 02:48:10PM +0200, Jan Kiszka wrote: On 2012-05-28 14:44, Michael S. Tsirkin wrote: On Fri, May 25, 2012 at 05:35:03PM +1000, Alexey Kardashevskiy wrote: Some adapters (like NEC PCI USB controller) do not flush their config on a sioftware reset and remember DMA config, etc. If we use such an adapter with QEMU, then crash QEMU (stop it with ctrl-A ctrl-X), and try to use it in QEMU again, it may start working immediately with previous config when pci_enable_device() is called on that PCI function. To eliminate such effect, some quirk should be called. The proposed pci_fixup_final does its job well for mentioned NEC PCI USB but not sure if it is 100% correct. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Won't current kvm device assignment be affected by this? Would be surprising if not. If yes need to address that not just vfio. A reason to solve this at PCI level? Jan Sure, and I think this is what Benjamin Herren was suggesting. I just wanted to add another reason. -- MST
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
On Mon, 28 May 2012 12:17:04 +0100 Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: What we need to decide is whether it's okay to drop QEMU VLANs completely and change dump command-line syntax? I'd vote for dropping it. I think vlan-hub doesn't hurt anyone because the code has been isolated and we keep backwards compatibility. So I'd personally still go the vlan-hub route for QEMU 1.x. Just to make it clear: I'm not against this series. I'm against having the functionality in qemu. If we want to keep the functionality, then I completely agree that this series is the way to go. Having glanced at this series I think it's beyond comparison with the current code...
Re: [Qemu-devel] [PATCH v2] hmp/qxl: info spice: add qxl info
On Mon, May 28, 2012 at 10:13:28AM -0300, Luiz Capitulino wrote: On Mon, 28 May 2012 12:08:13 +0300 Alon Levy al...@redhat.com wrote: On Fri, May 25, 2012 at 11:43:11AM -0300, Luiz Capitulino wrote: On Thu, 24 May 2012 19:22:52 +0300 Alon Levy al...@redhat.com wrote: For all devices print id, mode and guest_bug status. Is qxl really tied to spice? In the meaning that it's impossible to use it without spice? Wouldn't it be better to have 'info display' instead? Would a patch implementing 'info display' require me to implement it for all displays? Would be nice, even if we start with very basic information. How would that work? I have QXLInfo that only makes sense when the information is about a qxl device. Can't have opaque data in a QMP response, so would this be a info display qxl info display cirrus etc. or info qxl?
Re: [Qemu-devel] [PATCH 8/9] unicore32-softmmu: add config and makefile support
Am 28.05.2012 12:08, schrieb guanxue...@mprc.pku.edu.cn: Am 25.05.2012 13:29, schrieb Guan Xuetao: This patch adds configure and makefile support for unicore32-softmmu. All puv3-soc devices are put into hw/pkunity directory, so this dir will be added when unicore32-softmmu is selected. Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn --- Makefile.target |5 + arch_init.c |2 ++ arch_init.h |1 + configure |4 default-configs/unicore32-softmmu.mak |4 5 files changed, 16 insertions(+), 0 deletions(-) create mode 100644 default-configs/unicore32-softmmu.mak diff --git a/Makefile.target b/Makefile.target index 1582904..2f850d3 100644 --- a/Makefile.target +++ b/Makefile.target @@ -387,6 +387,11 @@ obj-xtensa-y += core-dc232b.o obj-xtensa-y += core-dc233c.o obj-xtensa-y += core-fsf.o +obj-unicore32-y += uc32_softmmu.o +obj-unicore32-y += pkunity/puv3.o +obj-unicore32-y += pkunity/puv3_intc.o pkunity/puv3_ost.o pkunity/puv3_gpio.o +obj-unicore32-y += pkunity/puv3_pm.o pkunity/puv3_dma.o [snip] You need to put the Makefile/configure changes into the patches that introduce the files please, otherwise they cannot be checked for compiler warnings/errors. I think the patch series is considered as a whole, and only compiling/building one device sim-code doesn't make sense. In fact, when unicore32-softmmu not enabled, the device sim-code isn't going to be compiled at all. Well, we expect each patch in a series to build warning-free for bisectability (even if applied in one PULL), and only compiling things in the final patch does not help. The series should be ordered so that we can either manually enable it with --target-list=unicore32-softmmu until it finally gets enabled by default, or like the openrisc target enables itself by default with some stubs and refines itself over the next patches. The other aspect is to make it easy for humans to review your patches before they can get applied, and personally I find it easier to review small patches. But opinions are divided on that. The criteria for acceptance is not just whether your kernel works in the end [*], my concern is more about how its design aligns with upstream trends like QOM awareness. Another thing: It is advisable to place SoC devices (as opposed to the machine) into Makefile.objs (hw-unicore32-y) so that they get compiled into libhw32 rather than into the target's directory. That avoids duplicates when a second endianness or a 64-bit version is introduced. (Yes, some existing targets violate that principle. I am working towards fixing it.) Andreas [*] It would be helpful if you could share linux-user and softmmu binaries on the Wiki for us to avoid regressions. http://wiki.qemu.org/Testing -- 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 qemu 5/6] implement -no-user-config command-line option (v3)
Am 28.05.2012 08:35, schrieb Paolo Bonzini: Il 27/05/2012 16:02, Andreas Färber ha scritto: Any suggestion how to fix? Sorry, I forgot to reply here that I've sent a patch. Does it work to typedef _Bool __bool before including altivec.h (and in the same #ifdef)? Haven't tried but I'm afraid of what side effects that may have... I feel more comfortable sticking to the POSIX #define bool _Bool rule. Andreas
Re: [Qemu-devel] [PATCH qom-next] qom: Introduce object_property_is_{child, link}()
Am 28.05.2012 08:47, schrieb Paolo Bonzini: Il 27/05/2012 01:19, Andreas Färber ha scritto: Avoids hardcoding partial string comparisons. Signed-off-by: Alexander Barabash alexander_barab...@mentor.com Signed-off-by: Andreas Färber afaer...@suse.de [...] Reviewed-by: Paolo Bonzini pbonz...@redhat.com Thanks, applied to qom-next: http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-next /-F -- 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 for-1.1? v2] slirp: Avoid statements without effect on Big Endian host
Am 28.05.2012 14:00, schrieb Peter Maydell:
On 28 May 2012 12:47, Jan Kiszka jan.kis...@web.de wrote:
On 2012-05-28 00:10, Peter Maydell wrote:
On 27 May 2012 17:42, Andreas Färber andreas.faer...@web.de wrote:
+# if defined(__APPLE__)
+# undef NTOHL
+# undef NTOHS
+# undef HTONL
+# undef HTONS
+# define NTOHL(d) do { } while (0)
+# define NTOHS(d) do { } while (0)
+# define HTONL(d) do { } while (0)
+# define HTONS(d) do { } while (0)
+# else
We could just use this for everything, not just if __APPLE__,
right? For big-endian the semantics we want are always do
nothing so it's always OK to undef and redefine...
That would save having a special case.
Yes, please.
It occurred to me that you could also have the unconditional
#undefs outside the #ifdef HOST_WORDS_BIGENDIAN, but that
is starting to stray outside of the simple fix for 1.1
territory.
For 1.2 I would suggest to go even further and drop these SLIRP-specific
macros in favor of QEMU-wide available ones. static inline functions
would've avoided the problem in the first place.
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 1.1] virtio: Fix compiler warning for non Linux hosts
Am 23.05.2012 10:09, schrieb Stefan Hajnoczi: On Tue, May 22, 2012 at 10:23 PM, Stefan Weil s...@weilnetz.de wrote: The local variables ret, i are only used if __linux__ is defined. Signed-off-by: Stefan Weil s...@weilnetz.de --- hw/virtio-blk.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) The #ifdef __linux__ further down in the function declares the local hdr variable. We could move ret and i down into the #ifdef instead of adding a new one. Sorry, this patch seems to have passed me by: I posted a patch moving all Linux variables into an #ifdef at the top. http://patchwork.ozlabs.org/patch/161546/ 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 for-1.1?] slirp: Avoid redefining MAX_TCPOPTLEN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 28.05.2012 13:40, schrieb Jan Kiszka:
On 2012-05-27 14:02, Andreas Färber wrote:
MAX_TCPOPTLEN is being defined as 32. Darwin has it as 40,
causing a warning. The value is only used to declare an array,
into which currently 4 bytes are written at most. It should
therefore be acceptable to adopt the host's definition.
Therefore only define MAX_TCPOPTLEN if not already defined.
Signed-off-by: Andreas Färber andreas.faer...@web.de ---
slirp/tcp_output.c |2 ++ 1 files changed, 2 insertions(+), 0
deletions(-)
diff --git a/slirp/tcp_output.c b/slirp/tcp_output.c index
779314b..9815123 100644 --- a/slirp/tcp_output.c +++
b/slirp/tcp_output.c @@ -47,7 +47,9 @@ static const u_char
tcp_outflags[TCP_NSTATES] = { };
+#ifndef MAX_TCPOPTLEN #define MAX_TCPOPTLEN 32 /* max # bytes
that go in options */ +#endif
/* * Tcp output routine: figure out what should be sent and send
it.
Let's be conservative for 1.1 and do #undef MAX_TCPOPTLEN instead.
Does this work as well?
For Leopard I'd guess so.
What I had in mind here was that it was suggested earlier by one of
you to use host defines for 1.2 wherever possible, and this seemed
like low-hanging fruit. I do see Stefan's point though.
An alternative, host-overriding version would be:
#if !defined(MAX_TCPOPTLEN) || MAX_TCPOPTLEN 4
#undef MAX_TCPOPTLEN
...
#endif
Stefan's point in turn means that defining MAX_TCPOPTLEN to something
larger than the host supports could in theory cause trouble when used
with host functions (which we currently don't seem to).
A safe host-adopting version would be:
#if defined(MAX_TCPOPTLEN) MAX_TCPOPTLEN = 4
#define SLIRP_MAX_TCPOPTLEN MAX_TCPOPTLEN
#else
#define SLIRP_MAX_TCPOPTLEN 32
#endif
and use opt[SLIRP_MAX_TCPOPTLEN]. In that case we could probably just
rename MAX_TCPOPTLEN - SLIRP_MAX_TCPOPTLEN in the first place.
Yet another option would be to drop MAX_TCPOPTLEN and to hardcode the
actually used opt[4].
Which do you prefer? :-)
Andreas
- --
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAEBAgAGBQJPw49tAAoJEPou0S0+fgE/o5cP+gKOS0NJVOWl+XOIB1Pb+xgs
WZ7f5Uiv0zAuzzcb4VLsB4XcWrxdkKdE2X284OFQyZIeya6IWuHuh35XCDDo1IG7
NwoV/rlZVRG3ttFEG1+6H49dgx/UeveyCs8kKsUQahO2teq423M4fStWhxky8SsQ
sxPoJZTw5gOAyQLzGPO8kZ+3jXwxm9wgsEYvjhqKz7HVHuxcy2EHbYDxYeuRtJnf
orwaUEVrGfwOwjDZF4E3R+x8z6YFjQ6a2/zsNnzeSzyXe67Mtmwfq/HSBmYpl6pY
YQSAxLrrOUL5jCXzckL8GoW4YKfNgsz8rcqK5RRBI27JPVQj+bdVJSbR0N6E4EAT
50u6uFSWV/uJFMu0f83fC2uiEt8c0i3dYDNmWZXKytdl9KfHu2SQiVqV7GfxcszT
Q4x0S9qnjB1P+Sh8Gtz61r8OQEAd9HssEaEbruzddvjXwuMJizcQKUZunO7PPx8V
EkWKIDwg/hAcIVody1j3T6llShc+LVfwDmaajFhLPK9lqm6sw15HwZ9V9E7ww0GD
DxRvVYud/XL4Zn6XpJVfozgQyAwWYKDduEZNIxA6YlIgtignXA8X+0wpRGKAJhea
ttIO9PBpeOMTGhw5rpvo1MtyPrQXyk0XKNpL/vpseQfnt3x9Asfww0qYrTLlejuW
X1ukGz9cleIqZyog5IHQ
=qYtt
-END PGP SIGNATURE-
Re: [Qemu-devel] [PATCH for-1.1? v2] slirp: Avoid statements without effect on Big Endian host
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 28.05.2012 13:47, schrieb Jan Kiszka:
On 2012-05-28 00:10, Peter Maydell wrote:
On 27 May 2012 17:42, Andreas Färber andreas.faer...@web.de
wrote:
+# if defined(__APPLE__) +# undef NTOHL +# undef NTOHS +#
undef HTONL +# undef HTONS +# define NTOHL(d) do { } while
(0) +# define NTOHS(d) do { } while (0) +# define HTONL(d) do
{ } while (0) +# define HTONS(d) do { } while (0) +# else
We could just use this for everything, not just if __APPLE__,
right? For big-endian the semantics we want are always do
nothing so it's always OK to undef and redefine... That would
save having a special case.
Yes, please.
On second thoughts my v2 was totally unnecessary and the solution
flawed: The HTONS(x); warning is stemming from Apple's
#define HTONS(d) (d)
not from our
#define HTONS(d)
so we can just unconditionally #undef the existing definitions.
That'll lead to unnecessary semicolons but not to warnings.
Andreas
- --
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAEBAgAGBQJPw5dgAAoJEPou0S0+fgE/wIkP/iu4ZQMR22nukCvtXANu2G7b
QfnsM7w28zRS2y+RkpoQ4pdldD5o2PMVowUA8uGtscvO4o5wVn7/h+1z768NFMht
KeOAic2h1cDUMQZp5DIhuMwXNHtzrYKejxyJSWzVFdpT+Za8tecQ4ge+iDXObdL0
u2a5RAfZU5oPSLZYdUWHkQhf6GayXRvkr/o6rBHKi0Y6S/Du9vlNUpMcANg1O85E
LtraZbfikfKAtWxX+3+yTaNmpfylbYTnUQqHGEXcwMSr7TIDstoyf1kmQcrOacQa
KwOGfW0psRsLQHSb9c3msezo4bFM/S+hyLj3Qg/Cr6Va/jENiyHUNALSymRCvlNw
nVTZOPoNfYOYHnu7yR7xTjpIxngCL7vtdjw4RhJASVKZXQo1TzeAgi9Wx/LFGuFa
Kifqr1wQwSUm+BESMAtJMKixobMscm1rkcwsITuAxTR+l6Cp6X3FcOG9xuHWbT52
IBToxsapwkRNdrb5HZxRIufOvTUq6j/zRfpODqiYe5IoHhF25w4Cvx5+eJ8X7Up6
2RrWRwtj6lmkBhezp2yiBZ/nIUVDcD8jywllla3PS52rjwJoFvRfAU9551yZPMkP
sVhSdID9f9KzwzzUE8YfcCGaVFnOriJG5LikxqcRztp7nlKSPFQNA0DvTK3xTuez
TzrCEwLr6wtBcdvG+6CK
=0bsI
-END PGP SIGNATURE-
Re: [Qemu-devel] [PATCH 1.1] es1370: Fix debug code
On Mon, 28 May 2012, Stefan Weil wrote: Am 28.05.2012 06:11, schrieb Peter Maydell: On 23 May 2012 22:26, Stefan Weils...@weilnetz.de wrote: When DEBUG_ES1370 is defined, the compiler shows these warnings: hw/es1370.c: In function ?es1370_update_voices?: hw/es1370.c:414: warning: format ?%d? expects type ?int?, but argument 3 has type ?size_t? The unicode quotes in this commit message seem to have got smashed to question-mark characters at some point between this email and it hitting git master :-( -- PMM Malc, could you please check your git workflow? Pine's '|' does that with my LC_CTYPE it seems, have to either ctrl-w after '|' or export, either way - can do. Commit 24f50d7ea5896a30b0e78f68884586bb8b40ff97 and other commits also changed Andreas F?rber to Andreas F?rber. See also a394aed235d6b3f048eeae83289f4d21eca7023c and lots more. The author is always correct, but UTF-8 characters in the commit message were replaced by ?. Regards, Stefan W. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 1.1] es1370: Fix debug code
Am 28.05.2012 17:18, schrieb malc: On Mon, 28 May 2012, Stefan Weil wrote: Am 28.05.2012 06:11, schrieb Peter Maydell: On 23 May 2012 22:26, Stefan Weils...@weilnetz.de wrote: When DEBUG_ES1370 is defined, the compiler shows these warnings: hw/es1370.c: In function ?es1370_update_voices?: hw/es1370.c:414: warning: format ?%d? expects type ?int?, but argument 3 has type ?size_t? The unicode quotes in this commit message seem to have got smashed to question-mark characters at some point between this email and it hitting git master :-( -- PMM Malc, could you please check your git workflow? Pine's '|' does that with my LC_CTYPE it seems, have to either ctrl-w after '|' or export, either way - can do. Recently I suspected your mailer and on one of the TCG threads suggested to download from Patchwork instead. But Patchwork also has its flaws: It tries to add *-bys from the replies, in the order it receives them rather than where they were placed and, like Anthony's mailbox script, it might pick up false positives. And when there's line-wrapping in the original mail it might silently drop part of the patch or in the combination of line-wrapping and patch attachment drop and duplicate parts. So if you can fix by some clever scripting that'll be safest. :) Thanks, 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 7/9] unicore32-softmmu: add puv3 soc support
Am 25.05.2012 13:29, schrieb Guan Xuetao: This patch only add minimal necessary system-control modules simulation for successfully kernel booting and busybox running. Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn --- hw/pkunity/puv3.c | 130 + hw/pkunity/puv3.h | 49 hw/pkunity/puv3_dma.c | 109 ++ hw/pkunity/puv3_gpio.c | 141 hw/pkunity/puv3_intc.c | 135 ++ hw/pkunity/puv3_ost.c | 151 hw/pkunity/puv3_pm.c | 148 +++ 7 files changed, 863 insertions(+), 0 deletions(-) create mode 100644 hw/pkunity/puv3.c create mode 100644 hw/pkunity/puv3.h create mode 100644 hw/pkunity/puv3_dma.c create mode 100644 hw/pkunity/puv3_gpio.c create mode 100644 hw/pkunity/puv3_intc.c create mode 100644 hw/pkunity/puv3_ost.c create mode 100644 hw/pkunity/puv3_pm.c Added a subdirectory without adapting configure and possibly Makefiles will break out-of-tree builds. Can't you just name the files puv3_something.[ch] as done for other SoCs? Andreas Every time, when I 'ls' the source tree of qemu or qemu/hw, it will generate a terrible and over-one-screen output. So, I think a new subdirectory makes it more clear (well-organized) and effective. Guan Xuetao
Re: [Qemu-devel] [PATCH 8/9] unicore32-softmmu: add config and makefile support
Am 25.05.2012 13:29, schrieb Guan Xuetao: This patch adds configure and makefile support for unicore32-softmmu. All puv3-soc devices are put into hw/pkunity directory, so this dir will be added when unicore32-softmmu is selected. Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn --- Makefile.target |5 + arch_init.c |2 ++ arch_init.h |1 + configure |4 default-configs/unicore32-softmmu.mak |4 5 files changed, 16 insertions(+), 0 deletions(-) create mode 100644 default-configs/unicore32-softmmu.mak diff --git a/Makefile.target b/Makefile.target index 1582904..2f850d3 100644 --- a/Makefile.target +++ b/Makefile.target @@ -387,6 +387,11 @@ obj-xtensa-y += core-dc232b.o obj-xtensa-y += core-dc233c.o obj-xtensa-y += core-fsf.o +obj-unicore32-y += uc32_softmmu.o +obj-unicore32-y += pkunity/puv3.o +obj-unicore32-y += pkunity/puv3_intc.o pkunity/puv3_ost.o pkunity/puv3_gpio.o +obj-unicore32-y += pkunity/puv3_pm.o pkunity/puv3_dma.o [snip] You need to put the Makefile/configure changes into the patches that introduce the files please, otherwise they cannot be checked for compiler warnings/errors. Andreas I think the patch series is considered as a whole, and only compiling/building one device sim-code doesn't make sense. In fact, when unicore32-softmmu not enabled, the device sim-code isn't going to be compiled at all. Guan Xuetao
Re: [Qemu-devel] [PATCH 6/9] unicore32-softmmu: add generic cpu state save/load functions
Am 25.05.2012 13:29, schrieb Guan Xuetao:
This patch adds generic cpu state save/load functions for UniCore32 ISA.
All architecture related registers are saved or loaded, and no
optimization.
Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn
---
target-unicore32/machine.c | 99
1 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 target-unicore32/machine.c
diff --git a/target-unicore32/machine.c b/target-unicore32/machine.c
new file mode 100644
index 000..e8c52cd
--- /dev/null
+++ b/target-unicore32/machine.c
@@ -0,0 +1,99 @@
+/*
+ * Generic machine functions for UniCore32 ISA
+ *
+ * Copyright (C) 2010-2012 Guan Xuetao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or any later version.
+ * See the COPYING file in the top-level directory.
+ */
+#include hw/hw.h
+
+void cpu_save(QEMUFile *f, void *opaque)
+{
+int i;
+CPUUniCore32State *env = (CPUUniCore32State *)opaque;
+
+for (i = 0; i 32; i++) {
+qemu_put_be32(f, env-regs[i]);
+}
+qemu_put_be32(f, cpu_asr_read(env));
+qemu_put_be32(f, env-bsr);
[snip]
Please use VMState instead.
Andreas
Thanks, I will try it.
Guan Xuetao
Re: [Qemu-devel] [PATCH 6/9] unicore32-softmmu: add generic cpu state save/load functions
Hi Guan,
+void cpu_save(QEMUFile *f, void *opaque)
+{
+int i;
+CPUUniCore32State *env = (CPUUniCore32State *)opaque;
+
+for (i = 0; i 32; i++) {
+qemu_put_be32(f, env-regs[i]);
+}
+qemu_put_be32(f, cpu_asr_read(env));
+qemu_put_be32(f, env-bsr);
+for (i = 0; i 6; i++) {
+qemu_put_be32(f, env-banked_bsr[i]);
+qemu_put_be32(f, env-banked_r29[i]);
+qemu_put_be32(f, env-banked_r30[i]);
+}
+
+qemu_put_be32(f, env-cp0.c0_cpuid);
+qemu_put_be32(f, env-cp0.c0_cachetype);
+qemu_put_be32(f, env-cp0.c1_sys);
+qemu_put_be32(f, env-cp0.c2_base);
+qemu_put_be32(f, env-cp0.c3_faultstatus);
+qemu_put_be32(f, env-cp0.c4_faultaddr);
+qemu_put_be32(f, env-cp0.c5_cacheop);
+qemu_put_be32(f, env-cp0.c6_tlbop);
+
+qemu_put_be32(f, env-features);
+
+if (env-features UC32_HWCAP_UCF64) {
+for (i = 0; i 16; i++) {
+CPU_DoubleU u;
+u.d = env-ucf64.regs[i];
+qemu_put_be32(f, u.l.upper);
+qemu_put_be32(f, u.l.lower);
+}
+for (i = 0; i 32; i++) {
+qemu_put_be32(f, env-ucf64.xregs[i]);
+}
+}
+}
Do you think use VMState rather then QEMUFile is a good idea?
I saw OpenRISC target got this kind of feedback before [1].
Regards,
chenwj
[1] http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg02457.html
Yes, the similar problems occured in both openrisc and unicore32.
Thanks for your guidence.
Guan Xuetao
Re: [Qemu-devel] [PATCH 7/9] unicore32-softmmu: add puv3 soc support
Am 25.05.2012 13:29, schrieb Guan Xuetao: This patch only add minimal necessary system-control modules simulation for successfully kernel booting and busybox running. Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn --- hw/pkunity/puv3.c | 130 + hw/pkunity/puv3.h | 49 hw/pkunity/puv3_dma.c | 109 ++ hw/pkunity/puv3_gpio.c | 141 hw/pkunity/puv3_intc.c | 135 ++ hw/pkunity/puv3_ost.c | 151 hw/pkunity/puv3_pm.c | 148 +++ 7 files changed, 863 insertions(+), 0 deletions(-) create mode 100644 hw/pkunity/puv3.c create mode 100644 hw/pkunity/puv3.h create mode 100644 hw/pkunity/puv3_dma.c create mode 100644 hw/pkunity/puv3_gpio.c create mode 100644 hw/pkunity/puv3_intc.c create mode 100644 hw/pkunity/puv3_ost.c create mode 100644 hw/pkunity/puv3_pm.c Added a subdirectory without adapting configure and possibly Makefiles will break out-of-tree builds. Can't you just name the files puv3_something.[ch] as done for other SoCs? Andreas Every time, when I 'ls' the source tree of qemu or qemu/hw, it will generate a terrible and over-one-screen output. So, I think a new subdirectory makes it more clear (well-organized) and effective. Guan Xuetao
Re: [Qemu-devel] [PATCH 5/9] unicore32-softmmu: initialize ucv2 cpu
Am 25.05.2012 13:29, schrieb Guan Xuetao: Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn --- target-unicore32/cpu.c | 17 + target-unicore32/cpu.h |2 +- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c index de63f58..62c0a22 100644 --- a/target-unicore32/cpu.c +++ b/target-unicore32/cpu.c @@ -32,13 +32,16 @@ static void unicore_ii_cpu_initfn(Object *obj) UniCore32CPU *cpu = UNICORE32_CPU(obj); CPUUniCore32State *env = cpu-env; -env-cp0.c0_cpuid = 0x40010863; +env-cp0.c0_cpuid = UC32_CPUID_UCV2; Please don't revert this change. I'll send you the patch to drop the CPUID #defines instead. But, the kernel need this CPUID to check whether it is a unicore32 processor, and if check fail, the kernel will halt. Guan Xuetao
[Qemu-devel] [PATCH for-1.1 v3] slirp: Avoid statements without effect on Big Endian host
Darwin has HTON*/NTOH* macros that on BE simply return the argument. This is incompatible with SLIRP's use of these macros as a statement. Undefine the macros in the HOST_WORDS_BIGENDIAN code path to redefine these macros as no-op, as already done when they were undefined. Suggested-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Andreas Färber andreas.faer...@web.de --- slirp/ip.h | 20 1 files changed, 8 insertions(+), 12 deletions(-) diff --git a/slirp/ip.h b/slirp/ip.h index 88c903f..e2ee5e3 100644 --- a/slirp/ip.h +++ b/slirp/ip.h @@ -34,18 +34,14 @@ #define _IP_H_ #ifdef HOST_WORDS_BIGENDIAN -# ifndef NTOHL -# define NTOHL(d) -# endif -# ifndef NTOHS -# define NTOHS(d) -# endif -# ifndef HTONL -# define HTONL(d) -# endif -# ifndef HTONS -# define HTONS(d) -# endif +# undef NTOHL +# undef NTOHS +# undef HTONL +# undef HTONS +# define NTOHL(d) +# define NTOHS(d) +# define HTONL(d) +# define HTONS(d) #else # ifndef NTOHL # define NTOHL(d) ((d) = ntohl((d))) -- 1.7.5.3
[Qemu-devel] [PATCH for-1.1 v2] slirp: Avoid redefining MAX_TCPOPTLEN
MAX_TCPOPTLEN is being defined as 32. Darwin already has it as 40,
causing a warning. The value is only used to declare an array,
into which currently 4 bytes are written at most.
Therefore always override MAX_TCPOPTLEN for now.
Suggested-by: Jan Kiszka jan.kis...@web.de
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
slirp/tcp_output.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/slirp/tcp_output.c b/slirp/tcp_output.c
index 779314b..8aa3d90 100644
--- a/slirp/tcp_output.c
+++ b/slirp/tcp_output.c
@@ -47,6 +47,7 @@ static const u_char tcp_outflags[TCP_NSTATES] = {
};
+#undef MAX_TCPOPTLEN
#define MAX_TCPOPTLEN 32 /* max # bytes that go in options */
/*
--
1.7.5.3
[Qemu-devel] [PATCH for-1.1] cocoa: Suppress Cocoa frontend for -qtest
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
ui/cocoa.m |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index e7d6e89..4724d2c 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -879,7 +879,8 @@ int main (int argc, const char * argv[]) {
!strcmp(opt, -vnc) ||
!strcmp(opt, -nographic) ||
!strcmp(opt, -version) ||
-!strcmp(opt, -curses)) {
+!strcmp(opt, -curses)||
+!strcmp(opt, -qtest)) {
return qemu_main(gArgc, gArgv, *_NSGetEnviron());
}
}
--
1.7.5.3
[Qemu-devel] [RFC next] ui: Split main() in two to not have Cocoa hijack it
Only call into cocoa.m when determined necessary by QEMU's option
handling. Avoids redoing all option parsing in ui/cocoa.m:main()
and constantly missing new options like -machine accel=qtest.
Move function declarations to a new ui.h header to avoid recompiling
everything when the new UI-internal function interface changes.
Handle the -psn option properly in vl.c.
Replace the faking of command line options for user-selected disk
image with proper API usage.
TODO: Clean up the main() vs. main2() split, including the naming.
This RFC simply takes the least intrusive approach by cutting
before the main loop initialization. The initialization of SPICE/VNC
may need to be moved up into main() for DT_DEFAULT handling.
RFC: Should we rather pass an opaque struct around, private to vl.c?
TODO: Eliminate remaining argv/argv checking in cocoa.m.
Signed-off-by: Andreas Färber andreas.faer...@web.de
Cc: Anthony Liguori anth...@codemonkey.ws
---
qemu-common.h |5
qemu-options.hx |5
ui/cocoa.m | 71 +-
ui/ui.h | 39 ++
vl.c| 56 ---
5 files changed, 119 insertions(+), 57 deletions(-)
create mode 100644 ui/ui.h
diff --git a/qemu-common.h b/qemu-common.h
index cccfb42..f6f1a84 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -127,11 +127,6 @@ extern int use_icount;
#endif /* !defined(NEED_CPU_H) */
-/* main function, renamed */
-#if defined(CONFIG_COCOA)
-int qemu_main(int argc, char **argv, char **envp);
-#endif
-
void qemu_get_timedate(struct tm *tm, int offset);
int qemu_timedate_diff(struct tm *tm);
diff --git a/qemu-options.hx b/qemu-options.hx
index 8b66264..fc1caa3 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2743,6 +2743,11 @@ DEF(qtest-log, HAS_ARG, QEMU_OPTION_qtest_log,
-qtest-log LOG specify tracing options\n,
QEMU_ARCH_ALL)
+#ifdef CONFIG_COCOA
+DEF(psn, 0, QEMU_OPTION_psn,
+-psnsupplied by Finder, QEMU_ARCH_ALL)
+#endif
+
HXCOMM This is the last statement. Insert new options before this line!
STEXI
@end table
diff --git a/ui/cocoa.m b/ui/cocoa.m
index 4724d2c..6e97b7e 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -26,8 +26,10 @@
#include crt_externs.h
#include qemu-common.h
+#include ui.h
#include console.h
#include sysemu.h
+#include blockdev.h
#ifndef MAC_OS_X_VERSION_10_4
#define MAC_OS_X_VERSION_10_4 1040
@@ -67,6 +69,13 @@ static DisplayChangeListener *dcl;
int gArgc;
char **gArgv;
+static void *gMachine;
+static int gSnapshot;
+static const char *gCPUModel, *gVGAModel;
+static char *gBootDevices;
+static const char *gICountOption;
+static const char *gLoadVM, *gIncoming;
+static bool gPSN;
// keymap conversion
int keymap[] =
@@ -708,7 +717,7 @@ QemuCocoaView *cocoaView;
@interface QemuCocoaAppController : NSObject
{
}
-- (void)startEmulationWithArgc:(int)argc argv:(char**)argv;
+- (void)startEmulation;
- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(int)returnCode
contextInfo:(void *)contextInfo;
- (void)toggleFullScreen:(id)sender;
- (void)showQEMUDoc:(id)sender;
@@ -764,16 +773,16 @@ QemuCocoaView *cocoaView;
// Display an open dialog box if no argument were passed or
// if qemu was launched from the finder ( the Finder passes -psn )
-if( gArgc = 1 || strncmp ((char *)gArgv[1], -psn, 4) == 0) {
+if (gArgc = 1 || gPSN) {
NSOpenPanel *op = [[NSOpenPanel alloc] init];
[op setPrompt:@Boot image];
[op setMessage:@Select the disk image you want to boot.\n\nHit the
\Cancel\ button to quit];
-[op beginSheetForDirectory:nil file:nil types:[NSArray
arrayWithObjects:@img,@iso,@dmg,@qcow,@cow,@cloop,@vmdk,nil]
+[op beginSheetForDirectory:nil file:nil types:[NSArray
arrayWithObjects:@img,@image,@iso,@dmg,@qcow,@cow,@cloop,@vmdk,nil]
modalForWindow:normalWindow modalDelegate:self
didEndSelector:@selector(openPanelDidEnd:returnCode:contextInfo:)
contextInfo:NULL];
} else {
-// or launch QEMU, with the global args
-[self startEmulationWithArgc:gArgc argv:(char **)gArgv];
+// or start the emulation
+[self startEmulation];
}
}
@@ -790,12 +799,13 @@ QemuCocoaView *cocoaView;
return YES;
}
-- (void)startEmulationWithArgc:(int)argc argv:(char**)argv
+- (void)startEmulation
{
COCOA_DEBUG(QemuCocoaAppController: startEmulationWithArgc\n);
int status;
-status = qemu_main(argc, argv, *_NSGetEnviron());
+status = main2(gMachine, gSnapshot, gCPUModel, gVGAModel, gBootDevices,
+ gICountOption, gLoadVM, gIncoming);
exit(status);
}
@@ -806,20 +816,13 @@ QemuCocoaView *cocoaView;
if(returnCode == NSCancelButton) {
exit(0);
} else if(returnCode == NSOKButton) {
-const char *bin = qemu;
char *img = (char*)[ [ sheet filename ]
Re: [Qemu-devel] [PATCH v2] hmp/qxl: info spice: add qxl info
On Mon, 28 May 2012 16:36:16 +0300 Alon Levy al...@redhat.com wrote: On Mon, May 28, 2012 at 10:13:28AM -0300, Luiz Capitulino wrote: On Mon, 28 May 2012 12:08:13 +0300 Alon Levy al...@redhat.com wrote: On Fri, May 25, 2012 at 11:43:11AM -0300, Luiz Capitulino wrote: On Thu, 24 May 2012 19:22:52 +0300 Alon Levy al...@redhat.com wrote: For all devices print id, mode and guest_bug status. Is qxl really tied to spice? In the meaning that it's impossible to use it without spice? Wouldn't it be better to have 'info display' instead? Would a patch implementing 'info display' require me to implement it for all displays? Would be nice, even if we start with very basic information. How would that work? I have QXLInfo that only makes sense when the information is about a qxl device. Can't have opaque data in a QMP response, so would this be a info display qxl info display cirrus etc. or info qxl? You could show what's available and/or being used currently. To be honest, I'm not very familiar with any of those drivers and don't know if/how management would use that information. I suggested 'info display' because it seemed more natural to me (vs. having this info tied to 'info spice').
Re: [Qemu-devel] How to compile the source code to get the images and executable to run the QEMU?
Hello Daniel, I really thank you for the answer to my question.. I was following the steps that are shown in the link that you point out, but when I get into the step: - Install the MinGW version of zlib and make sure zlib.h and libz.dll.a are in MinGW's default header and linker search paths. I don't know where to get the zlib, when I try to get it from the website where I got the MinGW it only shows a *.xml file, and can't find the way to install those libraries to paste them into the default header and linker search paths. If am missing something or didn't understand something regarding this compilation steps let me know. Thanks again for your time and help, Regards, Arturo Corrales V. From: Daniel P. Berrange berra...@redhat.com Date: May 25, 2012 1:27 AM Subject: Re: [Qemu-devel] How to compile the source code to get the images and executable to run the QEMU? To: Arturo CV arttak1...@gmail.com Cc: qemu-devel@nongnu.org On Thu, May 24, 2012 at 04:08:30PM -0600, Arturo CV wrote: Hello, Am new around here and am working with the QEMU in a project. I would like to ask if there is anyone that can let me know how to compile or build the images to be used to run the QEMU from the source code. I already got the source code from the wiki.qemu.org and I have the version 1.0.1. Now I would like to build it from there to start doing some test with my project. At the beginning I was working with the version 0.14.50 but it was already build with all the executable and everything and am having issues when I try to put the system into an Idle state using the wait so I was looking to use the newest version and go from there. I appreciate all the help and guidance you can give me since am kind of newbie with this :) Ordinarily I'd suggest that for any open source project you can just read the INSTALL file or README file for instructions, but having just checked I see QEMU does not have an INSTALL file and the README is mostly useless. Sigh. About the only docs I can find on building QEMU are these: http://qemu.weilnetz.de/qemu-doc.html#compilation If you only want to build one particular architecture (eg x86_64), then my recommendation is: ./configure --target-list=x86_64-softmmu --prefix=$HOME/usr/qemu-1.0.1 make make install Then you can run it $HOME/usr/qemu-1.0.1/bin/qemu-system-x86_64 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 :|
[Qemu-devel] qtest: setitimer() failures on Darwin and illumos
Hello, I'm seeing qemu-timer.c:unix_rearm_timer()'s setitimer() abort with EINVAL during `make check` on both platforms. The value of nearest_delta_ns appears to be INT64_MAX. Is this expected? Is it possible that this value is too large for it_value on some platforms? Apple's man page mentions that as possible reason for EINVAL but doesn't describe how to obtain such an upper value, nor of course where in the QEMU code base we would need to make adaptions. ;) Any suggestions? Thanks, Andreas
Re: [Qemu-devel] qtest: setitimer() failures on Darwin and illumos
Il 28/05/2012 21:40, Andreas Färber ha scritto: I'm seeing qemu-timer.c:unix_rearm_timer()'s setitimer() abort with EINVAL during `make check` on both platforms. The value of nearest_delta_ns appears to be INT64_MAX. Is this expected? Is it possible that this value is too large for it_value on some platforms? Apple's man page mentions that as possible reason for EINVAL but doesn't describe how to obtain such an upper value, nor of course where in the QEMU code base we would need to make adaptions. ;) Any suggestions? You shouldn't call the rearm function at all if you get INT64_MAX. This applies to all timers. We probably never had the problem because until recently the delta was capped to INT32_MAX instead. Paolo
Re: [Qemu-devel] [PATCH for-1.1 v2] slirp: Avoid redefining MAX_TCPOPTLEN
Am 28.05.2012 19:52, schrieb Andreas Färber:
MAX_TCPOPTLEN is being defined as 32. Darwin already has it as 40,
causing a warning. The value is only used to declare an array,
into which currently 4 bytes are written at most.
Therefore always override MAX_TCPOPTLEN for now.
Suggested-by: Jan Kiszkajan.kis...@web.de
Signed-off-by: Andreas Färberandreas.faer...@web.de
---
slirp/tcp_output.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/slirp/tcp_output.c b/slirp/tcp_output.c
index 779314b..8aa3d90 100644
--- a/slirp/tcp_output.c
+++ b/slirp/tcp_output.c
@@ -47,6 +47,7 @@ static const u_char tcp_outflags[TCP_NSTATES] = {
};
+#undef MAX_TCPOPTLEN
#define MAX_TCPOPTLEN 32 /* max # bytes that go in options */
/*
Reviewed-by: Stefan Weil s...@weilnetz.de
Re: [Qemu-devel] [PATCH for-1.1 v3] slirp: Avoid statements without effect on Big Endian host
On 2012-05-28 19:34, Andreas Färber wrote: Darwin has HTON*/NTOH* macros that on BE simply return the argument. This is incompatible with SLIRP's use of these macros as a statement. Undefine the macros in the HOST_WORDS_BIGENDIAN code path to redefine these macros as no-op, as already done when they were undefined. Suggested-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Andreas Färber andreas.faer...@web.de --- slirp/ip.h | 20 1 files changed, 8 insertions(+), 12 deletions(-) diff --git a/slirp/ip.h b/slirp/ip.h index 88c903f..e2ee5e3 100644 --- a/slirp/ip.h +++ b/slirp/ip.h @@ -34,18 +34,14 @@ #define _IP_H_ #ifdef HOST_WORDS_BIGENDIAN -# ifndef NTOHL -# define NTOHL(d) -# endif -# ifndef NTOHS -# define NTOHS(d) -# endif -# ifndef HTONL -# define HTONL(d) -# endif -# ifndef HTONS -# define HTONS(d) -# endif +# undef NTOHL +# undef NTOHS +# undef HTONL +# undef HTONS +# define NTOHL(d) +# define NTOHS(d) +# define HTONL(d) +# define HTONS(d) #else # ifndef NTOHL # define NTOHL(d) ((d) = ntohl((d))) Thanks, queued for 1.1. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH for-1.1 v2] slirp: Avoid redefining MAX_TCPOPTLEN
On 2012-05-28 19:52, Andreas Färber wrote:
MAX_TCPOPTLEN is being defined as 32. Darwin already has it as 40,
causing a warning. The value is only used to declare an array,
into which currently 4 bytes are written at most.
Therefore always override MAX_TCPOPTLEN for now.
Suggested-by: Jan Kiszka jan.kis...@web.de
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
slirp/tcp_output.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/slirp/tcp_output.c b/slirp/tcp_output.c
index 779314b..8aa3d90 100644
--- a/slirp/tcp_output.c
+++ b/slirp/tcp_output.c
@@ -47,6 +47,7 @@ static const u_char tcp_outflags[TCP_NSTATES] = {
};
+#undef MAX_TCPOPTLEN
#define MAX_TCPOPTLEN32 /* max # bytes that go in options */
/*
Thanks, queued for 1.1.
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] KVM call agenda for Tuesday, May 29th
Hi Please send in any agenda items you are interested in covering. Thanks, Juan.
[Qemu-devel] [PATCH V1] cadence_ttc: changed master clock frequency
Change the timer clock frequency to 133MHz which is correct. the old 2.5MHz
value was for the pre-silicon emulation platform.
Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
---
hw/cadence_ttc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/cadence_ttc.c b/hw/cadence_ttc.c
index 2b5477b..dd02f86 100644
--- a/hw/cadence_ttc.c
+++ b/hw/cadence_ttc.c
@@ -405,7 +405,7 @@ static int cadence_ttc_init(SysBusDevice *dev)
int i;
for (i = 0; i 3; ++i) {
-cadence_timer_init(250, s-timer[i]);
+cadence_timer_init(13300, s-timer[i]);
sysbus_init_irq(dev, s-timer[i].irq);
}
--
1.7.3.2
Re: [Qemu-devel] [PATCH V1] cadence_ttc: changed master clock frequency
On 29 May 2012 04:16, Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com wrote: Change the timer clock frequency to 133MHz which is correct. the old 2.5MHz value was for the pre-silicon emulation platform. Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com Thanks; queued in arm-devs.next (I plan to do a pullreq when master reopens). -- PMM
Re: [Qemu-devel] Virtio-pci issue
On 28.05.2012 16:37, Stefan Hajnoczi wrote: On Thu, May 24, 2012 at 4:18 AM, Evgeny Voevodine.voevo...@samsung.com wrote: And also there is another problem that I've faced with. It is the ability to plug as many pci back-ends as board wants. I mean that if for each back-end board should create a transport, then user have to know maximum number of transport instances created by board. In the case of mmio transport I think that it's a correct behaviour, but for pci transport seems not. Not sure I understand the problem. Can you rephrase it? Stefan Ok, I'll try ) As I see, to connect a pci device to board it should be enough to specify -device ... on command line. And in the way virtio refactoring is moving, board should create transport pci device to correspond each back-end created by -device ... command. So, if we create more back-ends with -device option then transports created by board then there would be back-ends that will not have corresponding transport device. As result user should know maximum number of transport instances created by board to not overrun it. In the case of mmio I think it's normal, but not in the pci case. Am I right? -- Kind regards, Evgeny Voevodin, Leading Software Engineer, ASWG, Moscow RD center, Samsung Electronics e-mail: e.voevo...@samsung.com
Re: [Qemu-devel] Lack of codes in logging
Do you know how to use that? When I use* log(-d) exec and log(-d) pcall*, the qemu.log is always empty. On Mon, May 28, 2012 at 10:47 PM, 陳韋任 (Wei-Ren Chen) che...@iis.sinica.edu.tw wrote: On Mon, May 28, 2012 at 10:37:47PM -0400, Yue Chen wrote: What's the helper function? Thanks. How QEMU translation works is as below, guest binary - TCG IR - host binary To express complicated operations is not easy for TCG IR. Therefore, you can write normal C function (helper_function), then use TCG IR call to call that C function (call helper_function). But I note what you are talking about is in_asm, not op, so Peter should be right. Try -d exec instead. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
