Re: [Qemu-devel] [PATCH 02/18] block: add error parameter to bdrv_snapshot_create() and related functions
Luiz Capitulino writes:
> On Wed, 15 Aug 2012 09:41:43 +0200
> Pavel Hrdina wrote:
>
>> Signed-off-by: Pavel Hrdina
>> ---
>> block.c| 25 +
>> block.h| 3 ++-
>> block/qcow2-snapshot.c | 9 -
>> block/qcow2.h | 4 +++-
>> block/rbd.c| 20 ++--
>> block/sheepdog.c | 17 +
>> block_int.h| 3 ++-
>> qemu-img.c | 2 +-
>> savevm.c | 2 +-
>> 9 files changed, 57 insertions(+), 28 deletions(-)
>>
>> diff --git a/block.c b/block.c
>> index 016858b..8bc49b7 100644
>> --- a/block.c
>> +++ b/block.c
>> @@ -2661,16 +2661,25 @@ BlockDriverState *bdrv_snapshots(void)
>> }
>>
>> int bdrv_snapshot_create(BlockDriverState *bs,
>> - QEMUSnapshotInfo *sn_info)
>> + QEMUSnapshotInfo *sn_info,
>> + Error **errp)
>> {
>> BlockDriver *drv = bs->drv;
>> -if (!drv)
>> -return -ENOMEDIUM;
>> -if (drv->bdrv_snapshot_create)
>> -return drv->bdrv_snapshot_create(bs, sn_info);
>> -if (bs->file)
>> -return bdrv_snapshot_create(bs->file, sn_info);
>> -return -ENOTSUP;
>> +int ret;
>> +
>> +if (!drv) {
>> +error_set(errp, QERR_DEVICE_HAS_NO_MEDIUM,
>> bdrv_get_device_name(bs));
>
> We should only use QERR_ macros for the errors listed in the ErrorClass enum
> (except GenericError), all other errors should generally use error_setg(),
> like
> this:
>
> error_setg(errp, "device '%s' has no medium);
>
>> +ret = -ENOMEDIUM;
>
> And, usually, we should get rid of errno propagation. There are two cases
> here:
The block layer consistently[*] uses -errno return values. Its
consistency is valuable, and I'm a bit reluctant to break it. Maybe a
new rule "returns -errno, except when it has an Error ** argument" could
work. I'd like to hear Kevin's advice on this.
>
> 1. errno is propagated up so that upper layers can print a decent error
> message to the user.
>
> In this case, it's safe to eliminate errno. error_setg() will store a
> decent message already and the Error object can be propagated up.
>
> 2. errno is propagated up so that upper layers can distinguish among
> error causes and take different actions accordingly.
>
> Doesn't seem to be the case of bdrv_snapshot_create() (ie. errno is only
> used to communicate the error to the user). However, I'm pretty sure that
> such usage exists in qemu and the error API will break it, as most of our
> errors are generic.
>
> I see two solutions to this problem:
>
>A. Add specific errors to ErrorClass. I don't like this very much,
> as it's possible that such errors are going to be useful only
> internally.
Let's not reinvent errno, poorly.
>B. Add two new functions:
>
> void error_sete(Error **err, ErrorClass err_class, int errno,
> const char *fmt, ...);
> int error_get_errno(const Error **err);
>
> So that we can maintain errno when it's used to communicate
> error cause among functions.
Better.
What's ErrorClass doing there?
[...]
[*] Almost; it's still QEMU after all.
Re: [Qemu-devel] macvlan/macvtap: guest/host cannot communicate when network cable is unplugged
On Thu, Aug 30, 2012 at 11:32 PM, ching wrote: > >>> I also perform an additional test: the guests (macvtap bridge mode) CAN >>> communicate each other no matter network cable is plugged or not. >> Strange. I thought the original problem was that the macvtap guests >> cannot communicate with each other when the network cable is >> unplugged? >> >> Hopefully someone else can help you, I'm not familiar enough with >> macvlan/macvtap. >> >> Stefan >> > > My word may be a little bit confusing, it should be > > I also perform an additional test: I created two qemu guests (macvtap bridge > mode on eth0), they CAN communicate each other no matter network cable of the > host is unplugged or not. > > and my problem is specified in the subject already: guest/host cannot > communicate when network cable is unplugged > > > if my configuration seems correct, i may file a kernel bugzilla and seek for > their advice. Yes. If no one else responds then it's worth filing a bug. Stefan
Re: [Qemu-devel] [PATCH v2] Fix buffer run out in eepro100.
On Fri, Aug 31, 2012 at 4:40 AM, Bo Yang wrote:
>
>
Stefan Hajnoczi 08/30/12 7:42 PM >>>
> On Thu, Aug 30, 2012 at 9:38 AM, Bo Yang wrote:
>> On 08/30/2012 04:04 PM, Stefan Hajnoczi wrote:
>>> On Wed, Aug 29, 2012 at 09:17:43PM +0200, Stefan Weil wrote:
Am 29.08.2012 13:26, schrieb Bo Yang:
> This is reported by QA. When installing os with pxe, after the initial
> kernel and initrd are loaded, the procedure tries to copy files from
> install
> server to local harddisk, the network becomes stall because of running
> out of
> receive descriptor.
>
> Signed-off-by: Bo Yang
> ---
> hw/eepro100.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/hw/eepro100.c b/hw/eepro100.c
> index 50d117e..52a18ad 100644
> --- a/hw/eepro100.c
> +++ b/hw/eepro100.c
> @@ -1036,6 +1036,8 @@ static void eepro100_ru_command(EEPRO100State * s,
> uint8_t val)
> }
> set_ru_state(s, ru_ready);
> s->ru_offset = e100_read_reg4(s, SCBPointer);
> + qemu_flush_queued_packets(&s->nic->nc);
> + qemu_notify_event();
What would happen if the above changes were omitted?
>>>
>>> In the worst case the guest code would be unable to make progress since
>>> packet reception is disabled.
>>>
>>> The QEMU net subsystem needs to be kicked when rx buffers become
>>> available again so that any queued packets can be delivered and we can
>>> restart the event loop.
>>>
>>> The event loop needs to be restarted because net clients (like tap) use
>>> qemu_set_fd_handler2() with a read_poll() handler that returns false
>>> when the NIC is unable to receive. Imagine this scenario:
>>>
>>> 1. NIC runs out of rx buffers.
>>> 2. Event loop iteration starts and calls tap's read_poll() handler,
>>>which sees the NIC cannot receive and therefore does not add the tap
>>>file descriptor to select(2).
>>> 3. NIC gets new rx buffers but does not kick net subsystem/event loop.
>>> 4. Event loop still sitting in select(2) without the tap file
>>>descriptor. Therefore incoming packets are not picked up by QEMU!
>>>
>>> In practice the event loop tends to iterate due to timers, etc. But in
>>> the worst case we can go completely starved here.
>>
>> Yes. The fd will be added to read set in the next iteration. The delay
>> depends on the select timeout. it is possible to go starved here.
>>
>>>
Would the network show less performance? How much
would the test scenario (Linux installation) take longer?
>>>
>>> Yes, the lack of kicks causes reduced network performance. This is
>>> especially true with -netdev tap and a guest driver that runs out of rx
>>> buffers. If you're lucky you might not hit this depending on the
>>> -netdev and availability of rx buffers.
>>>
What about the other nic emulations in QEMU?
I observe hanging network rather often with the
ARM versatilepb emulation.
>>>
>>> virtio-net has been correct for some time.
>>>
>>> e1000, xen, usb, and eepro100 are now fixed in the net tree:
>>> http://github.com/stefanha/qemu/commits/net
>>>
>>> Other NICs may or may not be okay. Really all of them need to be
>>> audited.
>>>
> TRACE(OTHER, logout("val=0x%02x (rx start)\n", val));
> break;
> case RX_RESUME:
> @@ -1770,7 +1772,8 @@ static ssize_t nic_receive(NetClientState *nc,
> const uint8_t * buf, size_t size)
> if (rfd_command& COMMAND_EL) {
> /* EL bit is set, so this was the last frame. */
> logout("receive: Running out of frames\n");
> -set_ru_state(s, ru_suspended);
> +set_ru_state(s, ru_no_resources);
> + eepro100_rnr_interrupt(s);
Adding the interrupt here is correct (I have similar code in
http://repo.or.cz/w/qemu/ar7.git/blob/HEAD:/hw/eepro100.c
which is an improved version of hw/eepro100.c).
Setting ru_no_resources looks also good, but I am not
sure whether removing ru_suspended is ok. Maybe it should
be ru_no_resources | ru_suspended.
>>>
>>> I think the datasheet talks about setting the RU to no resources and the
>>> CU to suspended. So there are two state machines and we only track one
>>> here.
>>
>> I don't think I understand this. If we run out of rx descriptor, why do
>> we suspend tx unit too? maybe there are reasons I am unaware of.. I
>> don't know.
>
> I was wrong. The datasheet "Table 55. CU Activities Performed at the
> End of Execution" shows that the EL and S bit cause the CU to enter
> the Idle State.
>
> In terms of hw/eepro100.c I don't think we care about the CU state.
> RU state No Resources is correct.
>
> I think we've done here, do we? sorry for the format of the mail, it is
> sent from web.. Thanks for reviewing and suggestions.
I'm happy with this patch. I have merged it into the net tree:
https://github.com/stefanha/qemu/commit/363ed8f3012462d409de8f
[Qemu-devel] [PATCH v8 7/7] qapi: convert sendkey
Convert 'sendkey' to use QAPI.
QAPI passes key's index of mapping table to qmp_send_key(),
not keycode. So we use help functions to convert key/code to
index of key_defs, and 'index' will be converted to 'keycode'
inside qmp_send_key().
For qmp, QAPI would check invalid key and raise error.
For hmp, invalid key is checked in hmp_send_key().
'send-key' of QMP doesn't support key in hexadecimal format.
Signed-off-by: Amos Kong
---
console.h|1 -
hmp-commands.hx |2 +-
hmp.c| 55 ++
hmp.h|1 +
input.c | 67 +-
monitor.c| 87 --
qapi-schema.json | 20
qmp-commands.hx | 28 +
8 files changed, 171 insertions(+), 90 deletions(-)
diff --git a/console.h b/console.h
index 7934b11..c702b23 100644
--- a/console.h
+++ b/console.h
@@ -399,7 +399,6 @@ static inline int vnc_display_pw_expire(DisplayState *ds,
time_t expires)
void curses_display_init(DisplayState *ds, int full_screen);
/* input.c */
-extern const int key_defs[];
int index_from_key(const char *key);
int index_from_keycode(int code);
diff --git a/hmp-commands.hx b/hmp-commands.hx
index bd0c6c9..5cee131 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -505,7 +505,7 @@ ETEXI
.args_type = "keys:s,hold-time:i?",
.params = "keys [hold_ms]",
.help = "send keys to the VM (e.g. 'sendkey ctrl-alt-f1',
default hold time=100 ms)",
-.mhandler.cmd = do_sendkey,
+.mhandler.cmd = hmp_send_key,
},
STEXI
diff --git a/hmp.c b/hmp.c
index 81c8acb..ba99b2f 100644
--- a/hmp.c
+++ b/hmp.c
@@ -19,6 +19,7 @@
#include "qemu-timer.h"
#include "qmp-commands.h"
#include "monitor.h"
+#include "console.h"
static void hmp_handle_error(Monitor *mon, Error **errp)
{
@@ -1102,3 +1103,57 @@ void hmp_closefd(Monitor *mon, const QDict *qdict)
qmp_closefd(fdname, &errp);
hmp_handle_error(mon, &errp);
}
+
+void hmp_send_key(Monitor *mon, const QDict *qdict)
+{
+const char *keys = qdict_get_str(qdict, "keys");
+QKeyCodeList *keylist, *head = NULL, *tmp = NULL;
+int has_hold_time = qdict_haskey(qdict, "hold-time");
+int hold_time = qdict_get_try_int(qdict, "hold-time", -1);
+Error *err = NULL;
+char keyname_buf[16];
+char *separator;
+int keyname_len, idx;
+
+while (1) {
+separator = strchr(keys, '-');
+keyname_len = separator ? separator - keys : strlen(keys);
+pstrcpy(keyname_buf, sizeof(keyname_buf), keys);
+
+/* Be compatible with old interface, convert user inputted "<" */
+if (!strncmp(keyname_buf, "<", 1) && keyname_len == 1) {
+pstrcpy(keyname_buf, sizeof(keyname_buf), "less");
+keyname_len = 4;
+}
+keyname_buf[keyname_len] = 0;
+
+idx = index_from_key(keyname_buf);
+if (idx == Q_KEY_CODE_MAX) {
+monitor_printf(mon, "invalid parameter: %s\n", keyname_buf);
+break;
+}
+
+keylist = g_malloc0(sizeof(*keylist));
+keylist->value = idx;
+keylist->next = NULL;
+
+if (!head) {
+head = keylist;
+}
+if (tmp) {
+tmp->next = keylist;
+}
+tmp = keylist;
+
+if (!separator) {
+break;
+}
+keys = separator + 1;
+}
+
+if (idx != Q_KEY_CODE_MAX) {
+qmp_send_key(head, has_hold_time, hold_time, &err);
+}
+hmp_handle_error(mon, &err);
+qapi_free_QKeyCodeList(head);
+}
diff --git a/hmp.h b/hmp.h
index 7dd93bf..8e7838c 100644
--- a/hmp.h
+++ b/hmp.h
@@ -71,5 +71,6 @@ void hmp_netdev_add(Monitor *mon, const QDict *qdict);
void hmp_netdev_del(Monitor *mon, const QDict *qdict);
void hmp_getfd(Monitor *mon, const QDict *qdict);
void hmp_closefd(Monitor *mon, const QDict *qdict);
+void hmp_send_key(Monitor *mon, const QDict *qdict);
#endif
diff --git a/input.c b/input.c
index 5630cb1..c4b0619 100644
--- a/input.c
+++ b/input.c
@@ -28,6 +28,7 @@
#include "console.h"
#include "error.h"
#include "qmp-commands.h"
+#include "qapi-types.h"
static QEMUPutKBDEvent *qemu_put_kbd_event;
static void *qemu_put_kbd_event_opaque;
@@ -37,7 +38,7 @@ static QTAILQ_HEAD(, QEMUPutMouseEntry) mouse_handlers =
static NotifierList mouse_mode_notifiers =
NOTIFIER_LIST_INITIALIZER(mouse_mode_notifiers);
-const int key_defs[] = {
+static const int key_defs[] = {
[Q_KEY_CODE_SHIFT] = 0x2a,
[Q_KEY_CODE_SHIFT_R] = 0x36,
@@ -223,6 +224,70 @@ int index_from_keycode(int code)
return i;
}
+static QKeyCodeList *keycodes;
+static QEMUTimer *key_timer;
+
+static void release_keys(void *opaque)
+{
+int keycode;
+QKeyCodeList *p;
+
+for (p = keycodes; p != NULL; p = p->next) {
+keycode = key_defs[p->value];
+if (keycode & 0x80) {
+kbd_put_keyc
[Qemu-devel] [PATCH v8 5/7] qapi: add the QKeyCode enum
key_defs[] in monitor.c is a mapping table of keys and keycodes,
this patch added a QKeyCode enum. Key's index in the enmu is same
as keycode's index in key_defs[].
Signed-off-by: Amos Kong
---
qapi-schema.json | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index bd8ad74..856e11a 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2493,3 +2493,29 @@
# Since: 1.2.0
##
{ 'command': 'query-target', 'returns': 'TargetInfo' }
+
+##
+# @QKeyCode:
+#
+# An enumeration of key name.
+#
+# This is used by the send-key command.
+#
+# Since: 1.3.0
+##
+{ 'enum': 'QKeyCode',
+ 'data': [ 'shift', 'shift_r', 'alt', 'alt_r', 'altgr', 'altgr_r', 'ctrl',
+'ctrl_r', 'menu', 'esc', '1', '2', '3', '4', '5', '6', '7', '8',
+'9', '0', 'minus', 'equal', 'backspace', 'tab', 'q', 'w', 'e',
+'r', 't', 'y', 'u', 'i', 'o', 'p', 'bracket_left', 'bracket_right',
+'ret', 'a', 's', 'd', 'f', 'g', 'h', 'j', 'k', 'l', 'semicolon',
+'apostrophe', 'grave_accent', 'backslash', 'z', 'x', 'c', 'v', 'b',
+'n', 'm', 'comma', 'dot', 'slash', 'asterisk', 'spc', 'caps_lock',
+'f1', 'f2', 'f3', 'f4', 'f5', 'f6', 'f7', 'f8', 'f9', 'f10',
+'num_lock', 'scroll_lock', 'kp_divide', 'kp_multiply',
+'kp_subtract', 'kp_add', 'kp_enter', 'kp_decimal', 'sysrq', 'kp_0',
+'kp_1', 'kp_2', 'kp_3', 'kp_4', 'kp_5', 'kp_6', 'kp_7', 'kp_8',
+'kp_9', 'less', 'f11', 'f12', 'print', 'home', 'pgup', 'pgdn',
'end',
+'left', 'up', 'down', 'right', 'insert', 'delete', 'stop', 'again',
+'props', 'undo', 'front', 'copy', 'open', 'paste', 'find', 'cut',
+ 'lf', 'help', 'meta_l', 'meta_r', 'compose' ] }
--
1.7.1
[Qemu-devel] [PATCH v8 1/7] fix doc of using raw values with sendkey
(qemu) sendkey a
(qemu) sendkey 0x1e
(qemu) sendkey #0x1e
unknown key: '#0x1e'
The last command doesn't work, '#' is not requested before
raw values, and the raw value in decimal format is not supported.
Signed-off-by: Amos Kong
---
hmp-commands.hx |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index f6104b0..6a70a9c 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -512,9 +512,9 @@ STEXI
@item sendkey @var{keys}
@findex sendkey
-Send @var{keys} to the emulator. @var{keys} could be the name of the
-key or @code{#} followed by the raw value in either decimal or hexadecimal
-format. Use @code{-} to press several keys simultaneously. Example:
+Send @var{keys} to the guest. @var{keys} could be the name of the
+key or the raw value in hexadecimal format. Use @code{-} to press
+several keys simultaneously. Example:
@example
sendkey ctrl-alt-f1
@end example
--
1.7.1
[Qemu-devel] [PATCH v8 3/7] hmp: rename arguments
Rename 'string' to 'keys', rename 'hold_time' to 'hold-time'.
Signed-off-by: Amos Kong
---
hmp-commands.hx |2 +-
monitor.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 6a70a9c..bd0c6c9 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -502,7 +502,7 @@ ETEXI
{
.name = "sendkey",
-.args_type = "string:s,hold_time:i?",
+.args_type = "keys:s,hold-time:i?",
.params = "keys [hold_ms]",
.help = "send keys to the VM (e.g. 'sendkey ctrl-alt-f1',
default hold time=100 ms)",
.mhandler.cmd = do_sendkey,
diff --git a/monitor.c b/monitor.c
index c97c120..84176eb 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1480,9 +1480,9 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
char keyname_buf[16];
char *separator;
int keyname_len, keycode, i;
-const char *string = qdict_get_str(qdict, "string");
-int has_hold_time = qdict_haskey(qdict, "hold_time");
-int hold_time = qdict_get_try_int(qdict, "hold_time", -1);
+const char *keys = qdict_get_str(qdict, "keys");
+int has_hold_time = qdict_haskey(qdict, "hold-time");
+int hold_time = qdict_get_try_int(qdict, "hold-time", -1);
if (nb_pending_keycodes > 0) {
qemu_del_timer(key_timer);
@@ -1492,10 +1492,10 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
hold_time = 100;
i = 0;
while (1) {
-separator = strchr(string, '-');
-keyname_len = separator ? separator - string : strlen(string);
+separator = strchr(keys, '-');
+keyname_len = separator ? separator - keys : strlen(keys);
if (keyname_len > 0) {
-pstrcpy(keyname_buf, sizeof(keyname_buf), string);
+pstrcpy(keyname_buf, sizeof(keyname_buf), keys);
if (keyname_len > sizeof(keyname_buf) - 1) {
monitor_printf(mon, "invalid key: '%s...'\n", keyname_buf);
return;
@@ -1521,7 +1521,7 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
}
if (!separator)
break;
-string = separator + 1;
+keys = separator + 1;
}
nb_pending_keycodes = i;
/* key down events */
--
1.7.1
[Qemu-devel] [PATCH v8 2/7] monitor: rename keyname '<' to 'less'
There are many maps of keycode 0x56 in pc-bios/keymaps/*
pc-bios/keymaps/common:less 0x56
pc-bios/keymaps/common:greater 0x56 shift
pc-bios/keymaps/common:bar 0x56 altgr
pc-bios/keymaps/common:brokenbar 0x56 shift altgr
This patch just renamed '<' to 'less', QAPI might add new
variable by adding a prefix to keyname, '$PREFIX_<' is not
available, '$PREFIX_less' is ok.
For compatibility, convert user inputted '<' to 'less'.
Signed-off-by: Amos Kong
---
monitor.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/monitor.c b/monitor.c
index b17b1bb..c97c120 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1400,7 +1400,7 @@ static const KeyDef key_defs[] = {
{ 0x48, "kp_8" },
{ 0x49, "kp_9" },
-{ 0x56, "<" },
+{ 0x56, "less" },
{ 0x57, "f11" },
{ 0x58, "f12" },
@@ -1504,6 +1504,13 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
monitor_printf(mon, "too many keys\n");
return;
}
+
+/* Be compatible with old interface, convert user inputted "<" */
+if (!strncmp(keyname_buf, "<", 1) && keyname_len == 1) {
+pstrcpy(keyname_buf, sizeof(keyname_buf), "less");
+keyname_len = 4;
+}
+
keyname_buf[keyname_len] = 0;
keycode = get_keycode(keyname_buf);
if (keycode < 0) {
--
1.7.1
[Qemu-devel] [PATCH v8 4/7] qapi: generate list struct and visit_list for enum
Currently, if we define an 'enum' and use it in one command's
data, list struct for enum could not be generated, but it's
used in qmp function.
For example: KeyCodesList could not be generated.
>>> qapi-schema.json:
{ 'enum': 'KeyCodes',
'data': [ 'shift', 'alt' ... ] }
{ 'command': 'sendkey',
'data': { 'keys': ['KeyCodes'], '*hold-time': 'int' } }
>>> qmp-command.h:
void qmp_sendkey(KeyCodesList * keys, bool has_hold_time, int64_t
hold_time, Error **errp);
This patch lets qapi generate list struct and visit_list for enum.
Signed-off-by: Amos Kong
---
scripts/qapi-types.py | 16 +++-
scripts/qapi-visit.py | 14 +-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index cf601ae..49ef569 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -28,6 +28,16 @@ typedef struct %(name)sList
''',
name=name)
+def generate_fwd_enum_struct(name, members):
+return mcgen('''
+typedef struct %(name)sList
+{
+%(name)s value;
+struct %(name)sList *next;
+} %(name)sList;
+''',
+ name=name)
+
def generate_struct(structname, fieldname, members):
ret = mcgen('''
struct %(name)s
@@ -276,7 +286,8 @@ for expr in exprs:
if expr.has_key('type'):
ret += generate_fwd_struct(expr['type'], expr['data'])
elif expr.has_key('enum'):
-ret += generate_enum(expr['enum'], expr['data'])
+ret += generate_enum(expr['enum'], expr['data']) + "\n"
+ret += generate_fwd_enum_struct(expr['enum'], expr['data'])
fdef.write(generate_enum_lookup(expr['enum'], expr['data']))
elif expr.has_key('union'):
ret += generate_fwd_struct(expr['union'], expr['data']) + "\n"
@@ -300,6 +311,9 @@ for expr in exprs:
fdef.write(generate_type_cleanup(expr['union'] + "List") + "\n")
ret += generate_type_cleanup_decl(expr['union'])
fdef.write(generate_type_cleanup(expr['union']) + "\n")
+elif expr.has_key('enum'):
+ret += generate_type_cleanup_decl(expr['enum'] + "List")
+fdef.write(generate_type_cleanup(expr['enum'] + "List") + "\n")
else:
continue
fdecl.write(ret)
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index 04ef7c4..cbec24d 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -217,6 +217,16 @@ void visit_type_%(name)sList(Visitor *m, %(name)sList **
obj, const char *name,
return ret
+def generate_enum_declaration(name, members, genlist=True):
+ret = ""
+if genlist:
+ret += mcgen('''
+void visit_type_%(name)sList(Visitor *m, %(name)sList ** obj, const char
*name, Error **errp);
+''',
+ name=name)
+
+return ret
+
def generate_decl_enum(name, members, genlist=True):
return mcgen('''
@@ -335,10 +345,12 @@ for expr in exprs:
ret += generate_declaration(expr['union'], expr['data'])
fdecl.write(ret)
elif expr.has_key('enum'):
-ret = generate_visit_enum(expr['enum'], expr['data'])
+ret = generate_visit_list(expr['enum'], expr['data'])
+ret += generate_visit_enum(expr['enum'], expr['data'])
fdef.write(ret)
ret = generate_decl_enum(expr['enum'], expr['data'])
+ret += generate_enum_declaration(expr['enum'], expr['data'])
fdecl.write(ret)
fdecl.write('''
--
1.7.1
[Qemu-devel] [PATCH v8 6/7] monitor: move key_defs[] table and introduce two help functions
This patch added two help functions to convert key/code to index of
mapping table, those functions will return Q_KEY_CODE_MAX if the
code/key is invalid.
Patch also moved key_defs[] to input.c, and removed useless KeyDef struct.
Key's index in QKeyCode enmu is same as keycode's index in new key_defs[].
Monitor functions were changed to access key_defs[] directly.
key_defs[] is used in do_send_key(), so export key_defs[]. It will be
changed to static in next patch.
Signed-off-by: Amos Kong
---
console.h |6 ++
input.c | 186 +
monitor.c | 183
3 files changed, 203 insertions(+), 172 deletions(-)
diff --git a/console.h b/console.h
index 4334db5..7934b11 100644
--- a/console.h
+++ b/console.h
@@ -6,6 +6,7 @@
#include "notify.h"
#include "monitor.h"
#include "trace.h"
+#include "qapi-types.h"
/* keyboard/mouse support */
@@ -397,4 +398,9 @@ static inline int vnc_display_pw_expire(DisplayState *ds,
time_t expires)
/* curses.c */
void curses_display_init(DisplayState *ds, int full_screen);
+/* input.c */
+extern const int key_defs[];
+int index_from_key(const char *key);
+int index_from_keycode(int code);
+
#endif
diff --git a/input.c b/input.c
index 6968b31..5630cb1 100644
--- a/input.c
+++ b/input.c
@@ -37,6 +37,192 @@ static QTAILQ_HEAD(, QEMUPutMouseEntry) mouse_handlers =
static NotifierList mouse_mode_notifiers =
NOTIFIER_LIST_INITIALIZER(mouse_mode_notifiers);
+const int key_defs[] = {
+[Q_KEY_CODE_SHIFT] = 0x2a,
+[Q_KEY_CODE_SHIFT_R] = 0x36,
+
+[Q_KEY_CODE_ALT] = 0x38,
+[Q_KEY_CODE_ALT_R] = 0xb8,
+[Q_KEY_CODE_ALTGR] = 0x64,
+[Q_KEY_CODE_ALTGR_R] = 0xe4,
+[Q_KEY_CODE_CTRL] = 0x1d,
+[Q_KEY_CODE_CTRL_R] = 0x9d,
+
+[Q_KEY_CODE_MENU] = 0xdd,
+
+[Q_KEY_CODE_ESC] = 0x01,
+
+[Q_KEY_CODE_1] = 0x02,
+[Q_KEY_CODE_2] = 0x03,
+[Q_KEY_CODE_3] = 0x04,
+[Q_KEY_CODE_4] = 0x05,
+[Q_KEY_CODE_5] = 0x06,
+[Q_KEY_CODE_6] = 0x07,
+[Q_KEY_CODE_7] = 0x08,
+[Q_KEY_CODE_8] = 0x09,
+[Q_KEY_CODE_9] = 0x0a,
+[Q_KEY_CODE_0] = 0x0b,
+[Q_KEY_CODE_MINUS] = 0x0c,
+[Q_KEY_CODE_EQUAL] = 0x0d,
+[Q_KEY_CODE_BACKSPACE] = 0x0e,
+
+[Q_KEY_CODE_TAB] = 0x0f,
+[Q_KEY_CODE_Q] = 0x10,
+[Q_KEY_CODE_W] = 0x11,
+[Q_KEY_CODE_E] = 0x12,
+[Q_KEY_CODE_R] = 0x13,
+[Q_KEY_CODE_T] = 0x14,
+[Q_KEY_CODE_Y] = 0x15,
+[Q_KEY_CODE_U] = 0x16,
+[Q_KEY_CODE_I] = 0x17,
+[Q_KEY_CODE_O] = 0x18,
+[Q_KEY_CODE_P] = 0x19,
+[Q_KEY_CODE_BRACKET_LEFT] = 0x1a,
+[Q_KEY_CODE_BRACKET_RIGHT] = 0x1b,
+[Q_KEY_CODE_RET] = 0x1c,
+
+[Q_KEY_CODE_A] = 0x1e,
+[Q_KEY_CODE_S] = 0x1f,
+[Q_KEY_CODE_D] = 0x20,
+[Q_KEY_CODE_F] = 0x21,
+[Q_KEY_CODE_G] = 0x22,
+[Q_KEY_CODE_H] = 0x23,
+[Q_KEY_CODE_J] = 0x24,
+[Q_KEY_CODE_K] = 0x25,
+[Q_KEY_CODE_L] = 0x26,
+[Q_KEY_CODE_SEMICOLON] = 0x27,
+[Q_KEY_CODE_APOSTROPHE] = 0x28,
+[Q_KEY_CODE_GRAVE_ACCENT] = 0x29,
+
+[Q_KEY_CODE_BACKSLASH] = 0x2b,
+[Q_KEY_CODE_Z] = 0x2c,
+[Q_KEY_CODE_X] = 0x2d,
+[Q_KEY_CODE_C] = 0x2e,
+[Q_KEY_CODE_V] = 0x2f,
+[Q_KEY_CODE_B] = 0x30,
+[Q_KEY_CODE_N] = 0x31,
+[Q_KEY_CODE_M] = 0x32,
+[Q_KEY_CODE_COMMA] = 0x33,
+[Q_KEY_CODE_DOT] = 0x34,
+[Q_KEY_CODE_SLASH] = 0x35,
+
+[Q_KEY_CODE_ASTERISK] = 0x37,
+
+[Q_KEY_CODE_SPC] = 0x39,
+[Q_KEY_CODE_CAPS_LOCK] = 0x3a,
+[Q_KEY_CODE_F1] = 0x3b,
+[Q_KEY_CODE_F2] = 0x3c,
+[Q_KEY_CODE_F3] = 0x3d,
+[Q_KEY_CODE_F4] = 0x3e,
+[Q_KEY_CODE_F5] = 0x3f,
+[Q_KEY_CODE_F6] = 0x40,
+[Q_KEY_CODE_F7] = 0x41,
+[Q_KEY_CODE_F8] = 0x42,
+[Q_KEY_CODE_F9] = 0x43,
+[Q_KEY_CODE_F10] = 0x44,
+[Q_KEY_CODE_NUM_LOCK] = 0x45,
+[Q_KEY_CODE_SCROLL_LOCK] = 0x46,
+
+[Q_KEY_CODE_KP_DIVIDE] = 0xb5,
+[Q_KEY_CODE_KP_MULTIPLY] = 0x37,
+[Q_KEY_CODE_KP_SUBTRACT] = 0x4a,
+[Q_KEY_CODE_KP_ADD] = 0x4e,
+[Q_KEY_CODE_KP_ENTER] = 0x9c,
+[Q_KEY_CODE_KP_DECIMAL] = 0x53,
+[Q_KEY_CODE_SYSRQ] = 0x54,
+
+[Q_KEY_CODE_KP_0] = 0x52,
+[Q_KEY_CODE_KP_1] = 0x4f,
+[Q_KEY_CODE_KP_2] = 0x50,
+[Q_KEY_CODE_KP_3] = 0x51,
+[Q_KEY_CODE_KP_4] = 0x4b,
+[Q_KEY_CODE_KP_5] = 0x4c,
+[Q_KEY_CODE_KP_6] = 0x4d,
+[Q_KEY_CODE_KP_7] = 0x47,
+[Q_KEY_CODE_KP_8] = 0x48,
+[Q_KEY_CODE_KP_9] = 0x49,
+
+[Q_KEY_CODE_LESS] = 0x56,
+
+[Q_KEY_CODE_F11] = 0x57,
+[Q_KEY_CODE_F12] = 0x58,
+
+[Q_KEY_CODE_PRINT] = 0xb7,
+
+[Q_KEY_CODE_HOME] = 0xc7,
+[Q_KEY_CODE_PGUP] = 0xc9,
+[Q_KEY_CODE_PGDN] = 0xd1,
+[Q_KEY_CODE_END] = 0xcf,
+
+[Q_KEY_CODE_LEFT] = 0xcb,
+[Q_KEY_CODE_UP] = 0xc8,
+[Q_KEY_CODE_DOWN] = 0xd0,
+[Q_KEY_CODE_RIGHT] = 0xcd,
+
+[Q_KEY_CODE_INSERT] = 0xd2,
+[Q_KEY_CODE_DELETE] = 0xd3,
+#ifdef NEED_CPU_H
+#if defined(TARGET_SPARC) && !defined(TARGET_SPARC64)
+[Q_KEY_CODE_STOP] = 0xf0,
+[Q_KEY_CODE_AGAIN] =
[Qemu-devel] [PATCH v8 0/7] convert sendkey to qapi
This series converted 'sendkey' command to qapi. The raw value in hexadecimal format is not supported by 'send-key' of qmp. Amos Kong (7): fix doc of using raw values with sendkey monitor: rename keyname '<' to 'less' hmp: rename arguments qapi: generate list struct and visit_list for enum qapi: add the QKeyCode enum monitor: move key_defs[] table and introduce two help functions qapi: convert sendkey console.h |5 + hmp-commands.hx | 10 +- hmp.c | 55 +++ hmp.h |1 + input.c | 251 + monitor.c | 245 +--- qapi-schema.json | 46 + qmp-commands.hx | 28 ++ scripts/qapi-types.py | 16 +++- scripts/qapi-visit.py | 14 +++- 10 files changed, 421 insertions(+), 250 deletions(-) --- Changes from v1: - using a JSON array for the key names - rename new error to 'QERR_OVERFLOW' - fix command descriptions - qapi: generate list struct for enum - add '<' fixing Changes from v2: - fix support of raw value in hexadecimal format - fix bug in processing of '<-x' - don't generate useless cleanup functions for enum - introduced two functions for enum in qapi scripts - fix command description - drop keys number limitation in sendkey - drop patch: qerror: add QERR_OVERFLOW Changes from v3: - move key_defs[] to console.h - link mapping tables by enum values - rename 'sendkey' to 'send-key' for qmp Changes from v4: - rename 'KeyCodes' to 'QKeyCode' - fix default hold-time - move qmp_send_key(), key_defs to input.c - duplicate the keylist in qmp_send_key() - drop struct KeyDef - handle invalid key/index in hmp_send_key() Changes from v5: - split the addition of the QKeyCode enum and the key_defs table - split help functions definition - fix cmd completion and make key_defs static - drop ps2 trival fix, will post it by another thread Changes from v6: - split convert patch to two patches, and do the refactorings in first patch. Changes from v7: - rebase patchset to latest upstream/master - move the addition of QKeyCode out of patch5 - update version to 1.3.0
Re: [Qemu-devel] [PATCH v7 5/6] add the QKeyCode enum and the key_defs table
On 31/08/12 01:46, Luiz Capitulino wrote: On Mon, 20 Aug 2012 12:39:28 +0800 Amos Kong wrote: key_defs[] in monitor.c is a mapping table of keys and keycodes, this patch added a QKeyCode enum and a new key_defs table, key's index in the enmu is same as keycode's index in new key_defs[]. And added two help functions to convert key/code to index of mapping table, those functions will return Q_KEY_CODE_MAX if the code/key is invalid. 'key_defs' was dropped from the monitor, monitor functions were changed to access key_defs directly. Signed-off-by: Amos Kong This patch (and probably the next one too) doesn't apply on master, could you rebase please? Will send V8 later. As you'll have to respin, please change versions to 1.3.0. I also have comments below (minor, but as you'll respin anyway). Ok. --- console.h|6 ++ input.c | 186 ++ monitor.c| 183 +++- qapi-schema.json | 26 4 files changed, 229 insertions(+), 172 deletions(-) diff --git a/console.h b/console.h index 4334db5..7934b11 100644 --- a/console.h +++ b/console.h @@ -6,6 +6,7 @@ #include "notify.h" #include "monitor.h" #include "trace.h" +#include "qapi-types.h" /* keyboard/mouse support */ @@ -397,4 +398,9 @@ static inline int vnc_display_pw_expire(DisplayState *ds, time_t expires) /* curses.c */ void curses_display_init(DisplayState *ds, int full_screen); +/* input.c */ +extern const int key_defs[]; Why are you exporting key_defs[]? It should be static. key_defs[] is used in do_send_key() after applying this patch, so export key_defs[]. It will be changed to static in next patch. Also, it would be better to move the addition of QKeyCode out of this patch (ie. you first add it and then move the table). Will do it. -- Amos.
Re: [Qemu-devel] [PATCH v3 2/5] [RFC] libqblock, user example
于 2012-8-30 15:46, Paolo Bonzini 写道: Il 30/08/2012 03:59, Wenchao Xia ha scritto: Busy waiting is not acceptable, and this is the reason why I had suggested to keep AIO out of the design for now. You need to provide an implementation of AIO for either glib or something else, but this is best done within QEMU first (and only later moved to libqblock). It is similar to qemu's "select" type of AIO, while (true == qb_aio_check(broker) is not neccessary but an example here to ensure write i/o is executed first. Do you mean qemu's aio should be improved to another type of AIO API instead of select type? which kind of AIO api is preferred? Using GSource to integrate with the QEMU main loop would be an idea. qemu_aio_wait would remain. However, this is not relevant to libqblock. My point is that APIs are hard to get right, and even harder if you try to do too many things in the first iteration. Paolo OK, I got your point, will focus on a small set of API in the first version, then bring AIO with GSource in next step. -- Best Regards Wenchao Xia
Re: [Qemu-devel] QEMU emulation per CPU
On Fri, Aug 31, 2012 at 01:50:05AM +0700, Mulyadi Santosa wrote: > On Thu, Aug 30, 2012 at 7:27 PM, Naresh Bhat wrote: > > Hi Santosa, > > > > Can you please forward a link of that discussion thread ?? > > try: > http://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg05037.html I also think multithread support in qemu user mode is buggy, not only the issue mentioned on above thread. 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
[Qemu-devel] [PATCH] iSCSI: We need to support SG_IO also from iscsi_ioctl()
We need to support SG_IO from the synchronous iscsi_ioctl() since
scsi-block uses this to do an INQ to the device to discover its properties
This patch makes scsi-block work with iscsi.
Signed-off-by: Ronnie Sahlberg
---
block/iscsi.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 355ce65..189ab6f 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -537,7 +537,8 @@ iscsi_aio_ioctl_cb(struct iscsi_context *iscsi, int status,
#define SG_ERR_DRIVER_SENSE0x08
-if (status == SCSI_STATUS_CHECK_CONDITION && acb->task->datain.size >= 2) {
+if (status == SCSI_STATUS_CHECK_CONDITION
+&& acb->task->datain.size >= 2) {
int ss;
acb->ioh->driver_status |= SG_ERR_DRIVER_SENSE;
@@ -622,9 +623,17 @@ static BlockDriverAIOCB *iscsi_aio_ioctl(BlockDriverState
*bs,
return &acb->common;
}
+
+static void ioctl_cb(void *opaque, int status)
+{
+int *p_status = opaque;
+*p_status = status;
+}
+
static int iscsi_ioctl(BlockDriverState *bs, unsigned long int req, void *buf)
{
IscsiLun *iscsilun = bs->opaque;
+int status;
switch (req) {
case SG_GET_VERSION_NUM:
@@ -633,6 +642,15 @@ static int iscsi_ioctl(BlockDriverState *bs, unsigned long
int req, void *buf)
case SG_GET_SCSI_ID:
((struct sg_scsi_id *)buf)->scsi_type = iscsilun->type;
break;
+case SG_IO:
+status = -EINPROGRESS;
+iscsi_aio_ioctl(bs, req, buf, ioctl_cb, &status);
+
+while (status == -EINPROGRESS) {
+qemu_aio_wait();
+}
+
+return 0;
default:
return -1;
}
--
1.7.3.1
[Qemu-devel] [PATCH] iSCSI: Add support for SG_IO to iscsi_ioctl()
Paolo, List Please find a small patch that adds support for SG_IO to the synchronous iscsi_ioctl() function. This is needed to make scsi-block work with iscsi. regards ronnie sahlberg
[Qemu-devel] [PATCH] iSCSI: We dont need to explicitely call qemu_notify_event() any more
We no longer need to explicitely call qemu_notify_event() any more since this
is now done automatically any time the filehandles we listen to change.
Signed-off-by: Ronnie Sahlberg
---
block/iscsi.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 0b96165..355ce65 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -167,12 +167,6 @@ iscsi_set_events(IscsiLun *iscsilun)
}
-/* If we just added an event, the callback might be delayed
- * unless we call qemu_notify_event().
- */
-if (ev & ~iscsilun->events) {
-qemu_notify_event();
-}
iscsilun->events = ev;
}
--
1.7.3.1
[Qemu-devel] [PATCH] iSCSI: remove the now obsolete call to qemu_notify_event()
Paolo, List Please find a trivial patch to iscsi that removes the call to qemu_notify_event() We do not need to call this any more since a recent patch that made qemu_aio_set_fd_handler() and friends invoke this call automatically when required. regards ronnie sahlberg
Re: [Qemu-devel] [RFC v2 PATCH 6/6] QAPI: add command for live block commit, 'block-commit'
On 08/30/2012 11:47 AM, Jeff Cody wrote:
> The command for live block commit is added, which has the following
> arguments:
>
> device: the block device to perform the commit on (mandatory)
> base: the base image to commit into; optional (if not specified,
> it is the underlying original image)
> top:the top image of the commit - all data from inside top down
> to base will be committed into base. optional (if not specified,
> it is the active image) - see note below
> speed: maximum speed, in bytes/sec
>
> note: eventually this will support merging down the active layer,
> but that code is not yet complete. If the active layer is passed
> in currently as top, or top is left to the default, then the error
> QERR_TOP_NOT_FOUND will be returned.
>
> The is done as a block job, so upon completion a BLOCK_JOB_COMPLETED will
> be emitted.
Likewise, the job can be canceled, and it is possible to track progress
of the job or change the speed on the fly, using existing block job
commands.
Will the BLOCK_JOB_COMPLETED event have a new category listing that it
was a commit job instead of a stream job that completed? That is, I
think this patch is incomplete, and that you also need to modify
QMP/qmp-events.txt to modify the 'type' field of
BLOCK_JOB_{CANCELLED,COMPLETED} to distinguish this new sub-type of event.
>
> ##
> +# @block-commit
> +#
> +# Live commit of data from child image nodes into parent nodes - i.e.,
> +# writes data between 'top' and 'base' into 'base'.
> +#
> +# @device: the name of the device
> +#
> +# @base: #optional The parent image of the device to write data into.
> +#If not specified, this is the original parent image.
> +#
> +# @top:#optional The child image, above which data will not be committed
> +#down. If not specified, this is the active layer.
> +#
> +# @speed: #optional the maximum speed, in bytes per second
> +#
> +# Returns: Nothing on success
> +# If commit or stream is already active on this device, DeviceInUse
> +# If @device does not exist, DeviceNotFound
> +# If image commit is not supported by this device, NotSupported
> +# If @base does not exist, BaseNotFound
> +# If @top does not exist, TopNotFound
> +# If @speed is invalid, InvalidParameter
> +#
> +# Since: 1.2
1.3
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC v2 PATCH 4/6] qerror: new error for live block commit, QERR_TOP_NOT_FOUND
On 08/30/2012 11:47 AM, Jeff Cody wrote: > Signed-off-by: Jeff Cody > --- > qerror.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/qerror.h b/qerror.h > index d0a76a4..7396184 100644 > --- a/qerror.h > +++ b/qerror.h > @@ -219,6 +219,9 @@ void assert_no_error(Error *err); > #define QERR_TOO_MANY_FILES \ > ERROR_CLASS_GENERIC_ERROR, "Too many open files" > > +#define QERR_TOP_NOT_FOUND \ > +ERROR_CLASS_GENERIC_ERROR, "Top image file %s not found" > + Are you sure this patch is needed, or should you be using error_setg()? http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg04980.html -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] macvlan/macvtap: guest/host cannot communicate when network cable is unplugged
>> I also perform an additional test: the guests (macvtap bridge mode) CAN >> communicate each other no matter network cable is plugged or not. > Strange. I thought the original problem was that the macvtap guests > cannot communicate with each other when the network cable is > unplugged? > > Hopefully someone else can help you, I'm not familiar enough with > macvlan/macvtap. > > Stefan > My word may be a little bit confusing, it should be I also perform an additional test: I created two qemu guests (macvtap bridge mode on eth0), they CAN communicate each other no matter network cable of the host is unplugged or not. and my problem is specified in the subject already: guest/host cannot communicate when network cable is unplugged if my configuration seems correct, i may file a kernel bugzilla and seek for their advice. ching
Re: [Qemu-devel] [PATCH 3/7] block: raw-posix image file reopen
On 08/30/2012 11:47 AM, Jeff Cody wrote:
> This is derived from the Supriya Kannery's reopen patches.
>
> This contains the raw-posix driver changes for the bdrv_reopen_*
> functions. All changes are staged into a temporary scratch buffer
> during the prepare() stage, and copied over to the live structure
> during commit(). Upon abort(), all changes are abandoned, and the
> live structures are unmodified.
>
> The _prepare() will create an extra fd - either by means of a dup,
> if possible, or opening a new fd if not (for instance, access
> control changes). Upon _commit(), the original fd is closed and
> the new fd is used. Upon _abort(), the duplicate/new fd is closed.
>
> +if ((raw_s->open_flags & ~fcntl_flags) == (s->open_flags &
> ~fcntl_flags)) {
> +/* dup the original fd */
> +/* TODO: use qemu fcntl wrapper */
> +raw_s->fd = fcntl(s->fd, F_DUPFD_CLOEXEC, 0);
I assume this TODO has to be fixed to allow compilation on systems that
lack F_DUPFD_CLOEXEC.
> +if (raw_s->fd == -1) {
> +ret = -1;
> +goto error;
> +}
> +ret = fcntl_setfl(raw_s->fd, raw_s->open_flags);
> +} else {
> +raw_s->fd = qemu_open(state->bs->filename, raw_s->open_flags, 0644);
Is raw_s->open_flags every going to contain O_CREAT, or is the 0644 mode
argument spurious?
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] Adding support for Stateless Static NAT for TAP devices
I have a setup that requires to run virtual machines using QEMU. All these machines will be executed from the same snapshot thus giving them the save same state when they come to life, this is why they all will have the same source IP, the only difference between them is that each one is connected to a different TAP device. I have tried using iptables to NAT the connections based on the TAP interface and make it change the source IP of the connection to an IP that upon return will go back to the correct TAP device, but alas, the problem of state fullness of the iptables caused the problem with the second instance of the virtual machine that sent the same packet that was did pass the rule base as it was matched on an already opened connection that thus was NATed to the first virtual machine source IP. -Original Message- From: Dennis Jacobfeuerborn [mailto:denni...@conversis.de] Sent: Thursday, August 30, 2012 3:38 PM To: John Basila Cc: Stefan Hajnoczi; qemu-devel@nongnu.org; Anthony Liguori; Rusty Russell; netfil...@vger.kernel.org Subject: Re: Adding support for Stateless Static NAT for TAP devices On 08/30/2012 12:58 PM, John Basila wrote: > Please allow me to add a few comments: > > The problem here is related to the fact that QEMU is executed with multiple > instances and all instances start from the same snapshot, thus if they all > send a UDP DNS query, they will all create a packet - for example - > 10.0.0.2:2345 -> DNSERVER:53. The source port is the same. The first packet > that reaches the ipfilter will result in going over the iptables rules and > get NATed properly, the second QEMU instance that will send the same UDP > packet will not get to run over the iptables rules as the ipfilter already > saw this packet and the packet should be "RELATED" to a different connection > and thus will cause the response packets of machine B to be received via > machine A as the NAT rule will de-NAT the return packet to to the relevant > connection which is related to machine A. > > John > > -Original Message- > From: Stefan Hajnoczi [mailto:stefa...@gmail.com] > Sent: Thursday, August 30, 2012 1:44 PM > To: John Basila > Cc: qemu-devel@nongnu.org; Anthony Liguori; Rusty Russell; > netfil...@vger.kernel.org > Subject: Re: Adding support for Stateless Static NAT for TAP devices > > On Thu, Aug 30, 2012 at 10:27 AM, John Basila wrote: >> I have tried NAT and this is why I came up with this feature. > > QEMU's net/tap.c is the wrong place to add NAT code. The point of tap is to > use the host network stack. If you want userspace networking, use -netdev > user or -netdev socket. > > Please look into iptables more. I have CCed the netfilter mailing list. The > question is: > > The host has several tap interfaces (tap0, tap1, ...) and the machine on the > other end of each tap interface uses IP address 10.0.0.2. So we have: > > tap0 <-> virtual machine #0 (10.0.0.2) > tap1 <-> virtual machine #1 (10.0.0.2) > tap2 <-> virtual machine #2 (10.0.0.2) > > Because the virtual machines all use the same static IP address, they cannot > communicate with each other or the outside world (they fight over ARP). We'd > like to NAT the tap interfaces: > > tap0 <-> virtual machine #0 (10.0.0.2 NAT to 192.168.0.2) > tap1 <-> virtual machine #1 (10.0.0.2 NAT to 192.168.0.3) > tap2 <-> virtual machine #2 (10.0.0.2 NAT to 192.168.0.4) > > This would allow the virtual machines to communicate even though each > believes it is 10.0.0.2. > > How can this be done using iptables and friends? Why do the systems have the same IP? That seems like a broken network config to me. Regards, Dennis Scanned by Check Point Total Security Gateway.
Re: [Qemu-devel] [PATCH for 1.2] console: Fix warning from clang (and potential crash)
Stefan Weil writes:
> Am 17.08.2012 16:10, schrieb Jan Kiszka:
>> On 2012-08-17 15:50, Stefan Weil wrote:
>>
>>> ccc-analyzer reports this warning:
>>>
>>> console.c:1090:29: warning: Dereference of null pointer
>>> if (active_console->cursor_timer) {
>>> ^
>>>
>>> Function console_select allows active_console to be NULL,
>>> but would crash when accessing cursor_timer. Fix this.
>>>
>>> Signed-off-by: Stefan Weil
>>> ---
>>>
>>> Please note that I don't have a test case which triggers the crash.
>>>
>>> Regards,
>>> Stefan Weil
>>>
>>> console.c |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/console.c b/console.c
>>> index 4525cc7..f5e8814 100644
>>> --- a/console.c
>>> +++ b/console.c
>>> @@ -1087,7 +1087,7 @@ void console_select(unsigned int index)
>>> if (s) {
>>> DisplayState *ds = s->ds;
>>>
>>> -if (active_console->cursor_timer) {
>>> +if (active_console&& active_console->cursor_timer) {
>>> qemu_del_timer(active_console->cursor_timer);
>>> }
>>> active_console = s;
>>>
>>>
>> The only path that could trigger this is console_select() in the absence
>> of any console. Not sure if that is possible, but the above is surely
>> consistent with existing code.
>>
>> Reviewed-by: Jan Kiszka
>>
>> Jan
>>
>>
>
>
> Ping? It's still missing in QEMU 1.2.
It'll need to wait for 1.3 to open up. I missed it for 1.2-rc2 and at
this point, I don't want to commit anything other than actual bug fixes.
Regards,
Anthony Liguori
[Qemu-devel] [Bug 1037606] Re: vmwgfx does not work with kvm vmware vga
** Changed in: linux Status: Unknown => Confirmed ** Changed in: linux Importance: Unknown => Medium -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1037606 Title: vmwgfx does not work with kvm vmware vga Status in The Linux Kernel: Confirmed Status in QEMU: New Status in “linux” package in Ubuntu: Triaged Bug description: vmwgfx driver fails to initialize inside kvm. tried: kvm -m 2048 -vga vmware -cdrom RebeccaBlackLinux.iso (Ubuntu based, any Ubuntu live CD would do) Apport data collected with qantal alpha live CD (somewhat older kernel). The error is shjown in CurrentDmesg.txt https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1037606/+attachment/3265235/+files/CurrentDmesg.txt --- ApportVersion: 2.4-0ubuntu8 Architecture: amd64 AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found. CasperVersion: 1.320 DistroRelease: Ubuntu 12.10 IwConfig: eth0 no wireless extensions. lono wireless extensions. LiveMediaBuild: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120724.2) Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99 MachineType: Bochs Bochs Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: file=/cdrom/preseed/hostname.seed boot=casper initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity ProcVersionSignature: Ubuntu 3.5.0-6.6-generic 3.5.0 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-3.5.0-6-generic N/A linux-backports-modules-3.5.0-6-generic N/A linux-firmware 1.85 RfKill: Tags: quantal Uname: Linux 3.5.0-6-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: dmi.bios.date: 01/01/2007 dmi.bios.vendor: Bochs dmi.bios.version: Bochs dmi.chassis.type: 1 dmi.chassis.vendor: Bochs dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr: dmi.product.name: Bochs dmi.sys.vendor: Bochs --- ApportVersion: 2.0.1-0ubuntu12 Architecture: i386 DistroRelease: Ubuntu 12.04 InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007) Package: linux (not installed) ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash Tags: precise running-unity Uname: Linux 3.6.0-030600rc3-generic i686 UnreportableReason: The running kernel is not an Ubuntu kernel UpgradeStatus: Upgraded to precise on 2012-08-30 (0 days ago) UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1037606/+subscriptions
Re: [Qemu-devel] [PATCH for 1.2] w32: Fix broken build
Stefan Weil writes: > Commit ef8621b1a3b199c348606c0a11a77d8e8bf135f1 added an include > file which is not available for MinGW compilations. > > Signed-off-by: Stefan Weil Applied. Thanks. Regards, Anthony Liguori > --- > target-i386/cpu.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > index f3cac49..423e009 100644 > --- a/target-i386/cpu.c > +++ b/target-i386/cpu.c > @@ -33,7 +33,9 @@ > #include "hyperv.h" > > #include "hw/hw.h" > +#if defined(CONFIG_KVM) > #include > +#endif > > /* feature flags taken from "Intel Processor Identification and the CPUID > * Instruction" and AMD's "CPUID Specification". In cases of disagreement > -- > 1.7.10
Re: [Qemu-devel] Adding support for Stateless Static NAT for TAP devices
On 08/30/2012 12:58 PM, John Basila wrote: > Please allow me to add a few comments: > > The problem here is related to the fact that QEMU is executed with multiple > instances and all instances start from the same snapshot, thus if they all > send a UDP DNS query, they will all create a packet - for example - > 10.0.0.2:2345 -> DNSERVER:53. The source port is the same. The first packet > that reaches the ipfilter will result in going over the iptables rules and > get NATed properly, the second QEMU instance that will send the same UDP > packet will not get to run over the iptables rules as the ipfilter already > saw this packet and the packet should be "RELATED" to a different connection > and thus will cause the response packets of machine B to be received via > machine A as the NAT rule will de-NAT the return packet to to the relevant > connection which is related to machine A. > > John > > -Original Message- > From: Stefan Hajnoczi [mailto:stefa...@gmail.com] > Sent: Thursday, August 30, 2012 1:44 PM > To: John Basila > Cc: qemu-devel@nongnu.org; Anthony Liguori; Rusty Russell; > netfil...@vger.kernel.org > Subject: Re: Adding support for Stateless Static NAT for TAP devices > > On Thu, Aug 30, 2012 at 10:27 AM, John Basila wrote: >> I have tried NAT and this is why I came up with this feature. > > QEMU's net/tap.c is the wrong place to add NAT code. The point of tap is to > use the host network stack. If you want userspace networking, use -netdev > user or -netdev socket. > > Please look into iptables more. I have CCed the netfilter mailing list. The > question is: > > The host has several tap interfaces (tap0, tap1, ...) and the machine on the > other end of each tap interface uses IP address 10.0.0.2. So we have: > > tap0 <-> virtual machine #0 (10.0.0.2) > tap1 <-> virtual machine #1 (10.0.0.2) > tap2 <-> virtual machine #2 (10.0.0.2) > > Because the virtual machines all use the same static IP address, they cannot > communicate with each other or the outside world (they fight over ARP). We'd > like to NAT the tap interfaces: > > tap0 <-> virtual machine #0 (10.0.0.2 NAT to 192.168.0.2) > tap1 <-> virtual machine #1 (10.0.0.2 NAT to 192.168.0.3) > tap2 <-> virtual machine #2 (10.0.0.2 NAT to 192.168.0.4) > > This would allow the virtual machines to communicate even though each > believes it is 10.0.0.2. > > How can this be done using iptables and friends? Why do the systems have the same IP? That seems like a broken network config to me. Regards, Dennis
Re: [Qemu-devel] [RFC v2 PATCH 0/6] Live block commit
On 08/30/2012 02:47 PM, Jeff Cody wrote: > Live block commit. > > I originally had intended for this RFC series to include the more > complicated case of a live commit of the active layer, but removed > it for this commit in the hopes of making it into the soft feature > freeze for 1.2, so this series is the simpler case. > > This series adds the basic case, of a live commit between two > images below the active layer, e.g.: > > [base] <--- [snp-1] <--- [snp-2] <--- [snp-3] <--- [active] > > can be collapsed down via commit, into: > > [base] <--- [active] > > or, > > [base] <--- [snp-1] <--- [active], > > [base] <--- [snp-3] <--- [active], > > etc.. > > TODO: * qemu-io tests (in progress) > * 'stage-2' of live commit functionality, to be able to push down the > active layer. This structured something like mirroring, to allow for > convergence. > > Changes from the RFC v1 series: > > * This patch series is not on top of Paolo's blk mirror series yet, to make it > easier to apply independently if desired. This means some of what was in > the > previous RFC series is not in this one (BlockdevOnError, for instance), but > that can be easily added in once Paolo's series are in. > > * This patches series is dependent on the reopen() series with transactional > reopen. > > * The target release for this series is 1.3 > > * Found some mistakes in the reopen calls > > * Dropped the BlockdevOnError argument (for now), will add in if rebasing on > top of Paolo's series. > > * Used the new qerror system > > I meant to add this to my cover letter, but forgot; if anyone wants to play around with this, you can find it on github: git://github.com/codyprime/qemu-kvm-jtc.git (branch jtc-live-commit-1.3) > Jeff Cody (6): > 1/6 block: add support functions for live commit, to find and delete > images. > 2/6 block: add live block commit functionality > 3/6 blockdev: rename block_stream_cb to a generic block_job_cb > 4/6 qerror: new error for live block commit, QERR_TOP_NOT_FOUND > 5/6 block: helper function, to find the base image of a chain > 6/6 QAPI: add command for live block commit, 'block-commit' > > block.c | 158 > block.h | 6 +- > block/Makefile.objs | 1 + > block/commit.c | 202 > > block_int.h | 19 + > blockdev.c | 91 ++- > qapi-schema.json| 30 > qerror.h| 3 + > qmp-commands.hx | 6 ++ > trace-events| 4 +- > 10 files changed, 515 insertions(+), 5 deletions(-) > create mode 100644 block/commit.c >
Re: [Qemu-devel] Slow inbound traffic on macvtap interfaces
Chris Webb wrote: > I found that on my laptop, the single change of host kernel config > > -CONFIG_INTEL_IDLE=y > +# CONFIG_INTEL_IDLE is not set > > is sufficient to turn transfers into guests from slow to full wire speed I am not deep enough in this code to write a patch, but I wonder if macvtap_forward in macvtap.c is missing a call to kill_fasync, which I understand is used to signal to interested processes when data arrives? Here is the end of macvtap_forward: skb_queue_tail(&q->sk.sk_receive_queue, skb); wake_up_interruptible_poll(sk_sleep(&q->sk), POLLIN | POLLRDNORM | POLLRDBAND); return NET_RX_SUCCESS; Compared to this end of tun_net_xmit in tun.c: /* Enqueue packet */ skb_queue_tail(&tun->socket.sk->sk_receive_queue, skb); /* Notify and wake up reader process */ if (tun->flags & TUN_FASYNC) kill_fasync(&tun->fasync, SIGIO, POLL_IN); wake_up_interruptible_poll(&tun->wq.wait, POLLIN | POLLRDNORM | POLLRDBAND); return NETDEV_TX_OK; Richard.
Re: [Qemu-devel] Adding support for Stateless Static NAT for TAP devices
I have tried NAT and this is why I came up with this feature. When starting multiple QEMU instances from the same snapshot image, the Guest OS in all instances from the same state and if they start a connection to the DNS server for example, they will all use the same source port. The iptables will NAT the first packet it sees, but when the second QEMU instance sends the same packet, the iptables will match the already NATed connection and thus cause problems from returning packets. Using the SSNAT, this solves the problem by allowing a unique connection to be observed by the iptables. Regarding the vhost=on, I can disallow the use of both which I think is fair. John -Original Message- From: Stefan Hajnoczi [mailto:stefa...@gmail.com] Sent: Thursday, August 30, 2012 12:14 PM To: John Basila Cc: qemu-devel@nongnu.org; Anthony Liguori Subject: Re: Adding support for Stateless Static NAT for TAP devices On Thu, Aug 30, 2012 at 09:12:19AM +0300, John Basila wrote: > When running multiple instances of QEMU from the same image file > (using -snapshot) and connecting each instance to a dedicated TAP > device, the Guest OS will most likely not be able to communicate with > the outside world as all packets leave the Guest OS from the same IP > and thus the Host OS will have difficulty returning the packets to the > correct TAP device/Guest OS. Stateless Static Network Address > Translation or SSNAT allows the QEMU to map the network of the Guest > OS to the network of the TAP device allowing a unique IP address for > each Guest OS that ease such case. > The only mandatory argument to the SSNAT is the Guest OS network IP, > the rest will be figured out from the underlying TAP device. > > Signed-off-by: John Basila > --- > net/tap.c| 369 > +- > qapi-schema.json |5 +- > qemu-options.hx | 10 ++- > 3 files changed, 381 insertions(+), 3 deletions(-) This does not work with vhost=on because the host<->guest packet processing happens in vhost_net.ko instead of in QEMU. Use iptables on the host to NAT the tap interface. Stefan Scanned by Check Point Total Security Gateway.
Re: [Qemu-devel] Adding support for Stateless Static NAT for TAP devices
Please allow me to add a few comments: The problem here is related to the fact that QEMU is executed with multiple instances and all instances start from the same snapshot, thus if they all send a UDP DNS query, they will all create a packet - for example - 10.0.0.2:2345 -> DNSERVER:53. The source port is the same. The first packet that reaches the ipfilter will result in going over the iptables rules and get NATed properly, the second QEMU instance that will send the same UDP packet will not get to run over the iptables rules as the ipfilter already saw this packet and the packet should be "RELATED" to a different connection and thus will cause the response packets of machine B to be received via machine A as the NAT rule will de-NAT the return packet to to the relevant connection which is related to machine A. John -Original Message- From: Stefan Hajnoczi [mailto:stefa...@gmail.com] Sent: Thursday, August 30, 2012 1:44 PM To: John Basila Cc: qemu-devel@nongnu.org; Anthony Liguori; Rusty Russell; netfil...@vger.kernel.org Subject: Re: Adding support for Stateless Static NAT for TAP devices On Thu, Aug 30, 2012 at 10:27 AM, John Basila wrote: > I have tried NAT and this is why I came up with this feature. QEMU's net/tap.c is the wrong place to add NAT code. The point of tap is to use the host network stack. If you want userspace networking, use -netdev user or -netdev socket. Please look into iptables more. I have CCed the netfilter mailing list. The question is: The host has several tap interfaces (tap0, tap1, ...) and the machine on the other end of each tap interface uses IP address 10.0.0.2. So we have: tap0 <-> virtual machine #0 (10.0.0.2) tap1 <-> virtual machine #1 (10.0.0.2) tap2 <-> virtual machine #2 (10.0.0.2) Because the virtual machines all use the same static IP address, they cannot communicate with each other or the outside world (they fight over ARP). We'd like to NAT the tap interfaces: tap0 <-> virtual machine #0 (10.0.0.2 NAT to 192.168.0.2) tap1 <-> virtual machine #1 (10.0.0.2 NAT to 192.168.0.3) tap2 <-> virtual machine #2 (10.0.0.2 NAT to 192.168.0.4) This would allow the virtual machines to communicate even though each believes it is 10.0.0.2. How can this be done using iptables and friends? Thanks, Stefan Scanned by Check Point Total Security Gateway.
[Qemu-devel] [PATCH] target-i386: Allow changing of Hypervisor CPUIDs.
This is primarily done so that the guest will think it is running
under vmware when hypervisor=vmware is specified as a property of a
cpu.
Also allow this to work in accel=tcg mode.
The new cpu properties hyper_level, hyper_extra, hyper_extra_a, and
hyper_extra_b can be used to further adjust what the guest sees.
Signed-off-by: Don Slutz
---
target-i386/cpu.c | 178 +
target-i386/cpu.h |9 +++
target-i386/kvm.c | 33 --
3 files changed, 214 insertions(+), 6 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index f3cac49..a444b95 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -26,6 +26,7 @@
#include "qemu-option.h"
#include "qemu-config.h"
+#include "qemu-timer.h"
#include "qapi/qapi-visit-core.h"
#include "arch_init.h"
@@ -244,6 +245,15 @@ typedef struct x86_def_t {
uint32_t xlevel2;
/* The feature bits on CPUID[EAX=7,ECX=0].EBX */
uint32_t cpuid_7_0_ebx_features;
+/* Hypervisor CPUIDs */
+uint32_t cpuid_hv_level;
+uint32_t cpuid_hv_vendor1;
+uint32_t cpuid_hv_vendor2;
+uint32_t cpuid_hv_vendor3;
+/* VMware extra data */
+uint32_t cpuid_hv_extra;
+uint32_t cpuid_hv_extra_a;
+uint32_t cpuid_hv_extra_b;
} x86_def_t;
#define I486_FEATURES (CPUID_FP87 | CPUID_VME | CPUID_PSE)
@@ -860,6 +870,18 @@ static void x86_cpuid_set_tsc_freq(Object *obj, Visitor
*v, void *opaque,
cpu->env.tsc_khz = value / 1000;
}
+static void x86_cpuid_set_hv(x86_def_t *x86_cpu_def, uint32_t level,
+ const char *who)
+{
+uint32_t signature[3];
+
+memcpy(signature, who, 12);
+x86_cpu_def->cpuid_hv_level = level;
+x86_cpu_def->cpuid_hv_vendor1 = signature[0];
+x86_cpu_def->cpuid_hv_vendor2 = signature[1];
+x86_cpu_def->cpuid_hv_vendor3 = signature[2];
+}
+
static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def, const char *cpu_model)
{
unsigned int i;
@@ -867,6 +889,10 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
char *s = g_strdup(cpu_model);
char *featurestr, *name = strtok(s, ",");
+bool hyperv_enabled = false;
+bool hv_enabled = false;
+long hyper_level = -1;
+long hyper_extra = -1;
/* Features to be added*/
uint32_t plus_features = 0, plus_ext_features = 0;
uint32_t plus_ext2_features = 0, plus_ext3_features = 0;
@@ -993,12 +1019,84 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
x86_cpu_def->tsc_khz = tsc_freq / 1000;
} else if (!strcmp(featurestr, "hv_spinlocks")) {
char *err;
+
+if (hv_enabled) {
+fprintf(stderr,
+"Only one of hypervisor= or hv_* can be used at
one time.\n");
+goto error;
+}
numvalue = strtoul(val, &err, 0);
if (!*val || *err) {
fprintf(stderr, "bad numerical value %s\n", val);
goto error;
}
+hyperv_enabled = true;
hyperv_set_spinlock_retries(numvalue);
+} else if (!strcmp(featurestr, "hyper_level")) {
+char *err;
+long longvalue = strtol(val, &err, 0);
+
+if (!*val || *err) {
+fprintf(stderr, "bad numerical value for hyper_level=%s\n",
+val);
+goto error;
+}
+hyper_level = longvalue;
+} else if (!strcmp(featurestr, "hyper_extra")) {
+char *err;
+long longvalue = strtol(val, &err, 0);
+
+if (!*val || *err) {
+fprintf(stderr, "bad numerical value for hyper_extra=%s\n",
+val);
+goto error;
+}
+hyper_extra = longvalue;
+} else if (!strcmp(featurestr, "hyper_extra_a")) {
+char *err;
+
+numvalue = strtoul(val, &err, 0);
+if (!*val || *err) {
+fprintf(stderr,
+"bad numerical value for hyper_extra_a=%s\n",
+val);
+goto error;
+}
+x86_cpu_def->cpuid_hv_extra_a = (uint32_t)numvalue;
+} else if (!strcmp(featurestr, "hyper_extra_b")) {
+char *err;
+
+numvalue = strtoul(val, &err, 0);
+if (!*val || *err) {
+fprintf(stderr,
+"bad numerical value for hyper_extra_b=%s\n",
+val);
+goto error;
+}
+x86_cpu_def->cpuid_hv_extra_b = (uint32_t)numvalue;
+} else if (!strcmp(featurestr, "hv") ||
+
[Qemu-devel] [PATCH] target-i386: Allow changing of Hypervisor CPUIDs.
This is primarily done so that the guest will think it is running
under vmware when hypervisor=vmware is specified as a property of a
cpu.
Also allow this to work in accel=tcg mode.
The new cpu properties hyper_level, hyper_extra, hyper_extra_a, and
hyper_extra_b can be used to further adjust what the guest sees.
Signed-off-by: Don Slutz
---
target-i386/cpu.c | 178 +
target-i386/cpu.h |9 +++
target-i386/kvm.c | 33 --
3 files changed, 214 insertions(+), 6 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index f3cac49..9e82b76 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -26,6 +26,7 @@
#include "qemu-option.h"
#include "qemu-config.h"
+#include "qemu-timer.h"
#include "qapi/qapi-visit-core.h"
#include "arch_init.h"
@@ -244,6 +245,15 @@ typedef struct x86_def_t {
uint32_t xlevel2;
/* The feature bits on CPUID[EAX=7,ECX=0].EBX */
uint32_t cpuid_7_0_ebx_features;
+/* Hypervisor CPUIDs */
+uint32_t cpuid_hv_level;
+uint32_t cpuid_hv_vendor1;
+uint32_t cpuid_hv_vendor2;
+uint32_t cpuid_hv_vendor3;
+/* VMware extra data */
+uint32_t cpuid_hv_extra;
+uint32_t cpuid_hv_extra_a;
+uint32_t cpuid_hv_extra_b;
} x86_def_t;
#define I486_FEATURES (CPUID_FP87 | CPUID_VME | CPUID_PSE)
@@ -860,6 +870,18 @@ static void x86_cpuid_set_tsc_freq(Object *obj, Visitor
*v, void *opaque,
cpu->env.tsc_khz = value / 1000;
}
+static void x86_cpuid_set_hv(x86_def_t *x86_cpu_def, uint32_t level,
+ const char *who)
+{
+uint32_t signature[3];
+
+memcpy(signature, who, 12);
+x86_cpu_def->cpuid_hv_level = level;
+x86_cpu_def->cpuid_hv_vendor1 = signature[0];
+x86_cpu_def->cpuid_hv_vendor2 = signature[1];
+x86_cpu_def->cpuid_hv_vendor3 = signature[2];
+}
+
static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def, const char *cpu_model)
{
unsigned int i;
@@ -867,6 +889,10 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
char *s = g_strdup(cpu_model);
char *featurestr, *name = strtok(s, ",");
+bool hyperv_enabled = false;
+bool hv_enabled = false;
+long hyper_level = -1;
+long hyper_extra = -1;
/* Features to be added*/
uint32_t plus_features = 0, plus_ext_features = 0;
uint32_t plus_ext2_features = 0, plus_ext3_features = 0;
@@ -993,12 +1019,84 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
x86_cpu_def->tsc_khz = tsc_freq / 1000;
} else if (!strcmp(featurestr, "hv_spinlocks")) {
char *err;
+
+if (hv_enabled) {
+fprintf(stderr,
+"Only one of hypervisor= or hv_* can be used at
one time.\n");
+goto error;
+}
numvalue = strtoul(val, &err, 0);
if (!*val || *err) {
fprintf(stderr, "bad numerical value %s\n", val);
goto error;
}
+hyperv_enabled = true;
hyperv_set_spinlock_retries(numvalue);
+} else if (!strcmp(featurestr, "hyper_level")) {
+char *err;
+long longvalue = strtol(val, &err, 0);
+
+if (!*val || *err) {
+fprintf(stderr, "bad numerical value for hyper_level=%s\n",
+val);
+goto error;
+}
+hyper_level = longvalue;
+} else if (!strcmp(featurestr, "hyper_extra")) {
+char *err;
+long longvalue = strtol(val, &err, 0);
+
+if (!*val || *err) {
+fprintf(stderr, "bad numerical value for hyper_extra=%s\n",
+val);
+goto error;
+}
+hyper_extra = longvalue;
+} else if (!strcmp(featurestr, "hyper_extra_a")) {
+char *err;
+
+numvalue = strtoul(val, &err, 0);
+if (!*val || *err) {
+fprintf(stderr,
+"bad numerical value for hyper_extra_a=%s\n",
+val);
+goto error;
+}
+x86_cpu_def->cpuid_hv_extra_a = (uint32_t)numvalue;
+} else if (!strcmp(featurestr, "hyper_extra_b")) {
+char *err;
+
+numvalue = strtoul(val, &err, 0);
+if (!*val || *err) {
+fprintf(stderr,
+"bad numerical value for hyper_extra_b=%s\n",
+val);
+goto error;
+}
+x86_cpu_def->cpuid_hv_extra_b = (uint32_t)numvalue;
+} else if (!strcmp(featurestr, "hv") ||
+
[Qemu-devel] Adding support for Stateless Static NAT for TAP devices
When running multiple instances of QEMU from the same image file
(using -snapshot) and connecting each instance to a dedicated TAP
device, the Guest OS will most likely not be able to communicate
with the outside world as all packets leave the Guest OS from the
same IP and thus the Host OS will have difficulty returning the
packets to the correct TAP device/Guest OS. Stateless Static
Network Address Translation or SSNAT allows the QEMU to map the
network of the Guest OS to the network of the TAP device allowing
a unique IP address for each Guest OS that ease such case.
The only mandatory argument to the SSNAT is the Guest OS network
IP, the rest will be figured out from the underlying TAP device.
Signed-off-by: John Basila
---
net/tap.c| 369 +-
qapi-schema.json |5 +-
qemu-options.hx | 10 ++-
3 files changed, 381 insertions(+), 3 deletions(-)
diff --git a/net/tap.c b/net/tap.c
index 1971525..2408a49 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -39,16 +39,88 @@
#include "qemu-char.h"
#include "qemu-common.h"
#include "qemu-error.h"
+#include "qemu_socket.h"
#include "net/tap-linux.h"
#include "hw/vhost_net.h"
+#include "checksum.h"
+
+#define ETH_P_ARP 0x0806 /* Address Resolution packet */
+#define ETH_P_IP 0x0800 /* Internet Protocol packet */
+#define ETH_P_IPV6 0x86DD /* IPv6 over blueblook */
+
+#define ETH_ALEN 6
+
+struct ethhdr {
+unsigned char h_dest[ETH_ALEN]; /* destination eth addr */
+unsigned char h_source[ETH_ALEN]; /* source ether addr*/
+unsigned short h_proto;/* packet type ID field */
+};
+
+#define IP_PROTO_TCP 6
+#define IP_PROTO_UDP 17
+#define IPV4_ADRESS_LENGTH 4
+
+struct arphdr {
+unsigned short ar_hrd; /* format of hardware address */
+unsigned short ar_pro; /* format of protocol address */
+unsigned char ar_hln; /* length of hardware address */
+unsigned char ar_pln; /* length of protocol address */
+unsigned short ar_op; /* ARP opcode (command) */
+
+/*
+ * Ethernet looks like this : This bit is variable sized however...
+ */
+unsigned char ar_sha[ETH_ALEN];/* sender hardware
address */
+unsigned char ar_sip[IPV4_ADRESS_LENGTH]; /* sender IP address */
+unsigned char ar_tha[ETH_ALEN];/* target hardware
address */
+unsigned char ar_tip[IPV4_ADRESS_LENGTH]; /* target IP address */
+};
+
+#define IP_HEADER_LENGTH(ip) (((ip->ip_hlv)&0xf) << 2)
+
+/** An IPv4 packet header */
+struct iphdr {
+ uint8_t ip_hlv; /**< Header length and version of the header
*/
+ uint8_t ip_tos; /**< Type of Service
*/
+ uint16_t ip_len; /**< Length in octets, inlc. this header and data
*/
+ uint16_t ip_id; /**< ID is used to aid in assembling framents
*/
+ uint16_t ip_off; /**< Info about fragmentation (control, offset)
*/
+ uint8_t ip_ttl; /**< Time to Live
*/
+ uint8_t ip_p;/**< Next level protocol type
*/
+ uint16_t ip_sum; /**< Header checksum
*/
+ uint32_t ip_src; /**< Source IP address
*/
+ uint32_t ip_dst; /**< Destination IP address
*/
+};
+
+/** UDP packet header */
+typedef struct udphdr {
+uint16_t uh_sport; /* source port */
+uint16_t uh_dport; /* destination port */
+uint16_t uh_ulen; /* udp length */
+uint16_t uh_chksum;/* udp checksum */
+} udp_header;
+
+
/* Maximum GSO packet size (64k) plus plenty of room for
* the ethernet and virtio_net headers
*/
#define TAP_BUFSIZE (4096 + 65536)
+typedef struct SSNATInfo {
+ unsigned int ssnat_active : 1;
+
+ struct in_addr ssnat_ifaddr;
+ struct in_addr ssnat_ifmask;
+ uint8_t ssnat_hwaddr[ETH_ALEN];
+
+ struct in_addr ssnat_guest;
+ struct in_addr ssnat_host;
+ struct in_addr ssnat_mask;
+} SSNATInfo;
+
typedef struct TAPState {
NetClientState nc;
int fd;
@@ -59,6 +131,9 @@ typedef struct TAPState {
unsigned int write_poll : 1;
unsigned int using_vnet_hdr : 1;
unsigned int has_ufo: 1;
+
+ SSNATInfo ssnat_info;
+
VHostNetState *vhost_net;
unsigned host_vnet_hdr_len;
} TAPState;
@@ -154,11 +229,154 @@ static ssize_t tap_receive_raw(NetClientState *nc, const
uint8_t *buf, size_t si
return tap_write_packet(s, iov, iovcnt);
}
+#define SSNAT_MAP_IP(_orig, _to, _mask) ( (_orig.s_addr & ~_mask.s_addr) |
(_to.s_addr & _mask.s_addr) )
+#define SSNAT_IS_MATCH(_orig, _from, _mask)( (_orig.s_addr & _mask.s_addr)
== (_from.s_addr & _mask.s_addr) )
+
+static void tap_ssnat_translate_arp(uint8_t* buf, size_t size, const struct
in_addr from, const struct in_addr to
[Qemu-devel] VHDX support
Is anyone currently working on VHDX (as opposed to VHD) support, as used by the most recent version of Hyper-V? If not, would you be interested in patches? File format at: http://www.microsoft.com/en-us/download/details.aspx?id=29681 (Word format, sadly) -- Alex Bligh
Re: [Qemu-devel] [PATCH for 1.2] console: Fix warning from clang (and potential crash)
Am 17.08.2012 16:10, schrieb Jan Kiszka:
On 2012-08-17 15:50, Stefan Weil wrote:
ccc-analyzer reports this warning:
console.c:1090:29: warning: Dereference of null pointer
if (active_console->cursor_timer) {
^
Function console_select allows active_console to be NULL,
but would crash when accessing cursor_timer. Fix this.
Signed-off-by: Stefan Weil
---
Please note that I don't have a test case which triggers the crash.
Regards,
Stefan Weil
console.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/console.c b/console.c
index 4525cc7..f5e8814 100644
--- a/console.c
+++ b/console.c
@@ -1087,7 +1087,7 @@ void console_select(unsigned int index)
if (s) {
DisplayState *ds = s->ds;
-if (active_console->cursor_timer) {
+if (active_console&& active_console->cursor_timer) {
qemu_del_timer(active_console->cursor_timer);
}
active_console = s;
The only path that could trigger this is console_select() in the absence
of any console. Not sure if that is possible, but the above is surely
consistent with existing code.
Reviewed-by: Jan Kiszka
Jan
Ping? It's still missing in QEMU 1.2.
Re: [Qemu-devel] [PATCH] ahci: properly reset PxCMD on HBA reset
On 30.08.2012, at 12:59, Jason Baron wrote: > On Fri, Aug 24, 2012 at 06:39:02AM +0200, Alexander Graf wrote: >>> While testing q35, I found that windows 7 (specifically, windows 7 ultimate >>> with sp1 x64), wouldn't install because it can't find the cdrom or disk >>> drive. >>> The failure message is: 'A required cd/dvd device driver is missing. If you >>> have a driver floppy disk, CD, DVD, or USB flash drive, please insert it >>> now.' >>> This can also be reproduced on piix by adding an ahci controller, and >>> observing that windows 7 does not see any devices behind it. >>> >>> The problem is that when windows issues a HBA reset, qemu does not reset the >>> individual ports' PxCMD register. Windows 7 then reads back the PxCMD >>> register >>> and presumably assumes that the ahci controller has already been >>> initialized. >>> Windows then never sets up the PxIE register to enable interrupts, and thus >>> it >>> never gets irqs back when it sends ata device inquiry commands. >>> >>> I believe this change brings qemu into ahci 1.3 specification compliance. >>> >>> Section 10.4.3 HBA Reset: >>> >>> " >>> When GHC.HR is set to '1', GHC.AE, GHC.IE, the IS register, and all port >>> register fields (except PxFB/PxFBU/PxCLB/PxCLBU) that are not HwInit in the >>> HBA's register memory space are reset. >>> " >>> >>> I've also re-tested Fedora 16 and 17 to verify that they continue to work >>> with >>> this change. >> >> What a nasty little bug. If it makes it work for you, the change is all fine >> from my POV (and should go into 1.2). >> > > Ok, I don't see it 1.2.0-rc2. If others are ok with this for 1.2, whose > tree should this go through? Kevin :) Alex > > Thanks, > > -Jason
[Qemu-devel] [PATCH for 1.2] w32: Fix broken build
Commit ef8621b1a3b199c348606c0a11a77d8e8bf135f1 added an include file which is not available for MinGW compilations. Signed-off-by: Stefan Weil --- target-i386/cpu.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/target-i386/cpu.c b/target-i386/cpu.c index f3cac49..423e009 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -33,7 +33,9 @@ #include "hyperv.h" #include "hw/hw.h" +#if defined(CONFIG_KVM) #include +#endif /* feature flags taken from "Intel Processor Identification and the CPUID * Instruction" and AMD's "CPUID Specification". In cases of disagreement -- 1.7.10
Re: [Qemu-devel] [PATCH] ahci: properly reset PxCMD on HBA reset
On Fri, Aug 24, 2012 at 06:39:02AM +0200, Alexander Graf wrote: > > While testing q35, I found that windows 7 (specifically, windows 7 ultimate > > with sp1 x64), wouldn't install because it can't find the cdrom or disk > > drive. > > The failure message is: 'A required cd/dvd device driver is missing. If you > > have a driver floppy disk, CD, DVD, or USB flash drive, please insert it > > now.' > > This can also be reproduced on piix by adding an ahci controller, and > > observing that windows 7 does not see any devices behind it. > > > > The problem is that when windows issues a HBA reset, qemu does not reset the > > individual ports' PxCMD register. Windows 7 then reads back the PxCMD > > register > > and presumably assumes that the ahci controller has already been > > initialized. > > Windows then never sets up the PxIE register to enable interrupts, and thus > > it > > never gets irqs back when it sends ata device inquiry commands. > > > > I believe this change brings qemu into ahci 1.3 specification compliance. > > > > Section 10.4.3 HBA Reset: > > > > " > > When GHC.HR is set to '1', GHC.AE, GHC.IE, the IS register, and all port > > register fields (except PxFB/PxFBU/PxCLB/PxCLBU) that are not HwInit in the > > HBA's register memory space are reset. > > " > > > > I've also re-tested Fedora 16 and 17 to verify that they continue to work > > with > > this change. > > What a nasty little bug. If it makes it work for you, the change is all fine > from my POV (and should go into 1.2). > Ok, I don't see it 1.2.0-rc2. If others are ok with this for 1.2, whose tree should this go through? Thanks, -Jason
[Qemu-devel] [PATCH] ahci: add migration support
Add support for ahci migration. This patch builds upon the patches posted
previously by Andreas Faerber:
http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01538.html
(I hope I am giving Andreas proper credit for his work.)
I've tested these patches by migrating Windows 7 and Fedora 16 guests on
both piix with ahci attached and on q35 (which has a built-in ahci controller).
Signed-off-by: Jason Baron
---
hw/ide/ahci.c | 64 -
hw/ide/ahci.h | 10 +
hw/ide/ich.c | 11 +++--
3 files changed, 81 insertions(+), 4 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index b53c757..e94509b 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -1204,6 +1204,65 @@ void ahci_reset(AHCIState *s)
}
}
+static const VMStateDescription vmstate_ahci_device = {
+.name = "ahci port",
+.version_id = 1,
+.fields = (VMStateField []) {
+VMSTATE_IDE_BUS(port, AHCIDevice),
+VMSTATE_UINT32(port_state, AHCIDevice),
+VMSTATE_UINT32(finished, AHCIDevice),
+VMSTATE_UINT32(port_regs.lst_addr, AHCIDevice),
+VMSTATE_UINT32(port_regs.lst_addr_hi, AHCIDevice),
+VMSTATE_UINT32(port_regs.fis_addr, AHCIDevice),
+VMSTATE_UINT32(port_regs.fis_addr_hi, AHCIDevice),
+VMSTATE_UINT32(port_regs.irq_stat, AHCIDevice),
+VMSTATE_UINT32(port_regs.irq_mask, AHCIDevice),
+VMSTATE_UINT32(port_regs.cmd, AHCIDevice),
+VMSTATE_UINT32(port_regs.tfdata, AHCIDevice),
+VMSTATE_UINT32(port_regs.sig, AHCIDevice),
+VMSTATE_UINT32(port_regs.scr_stat, AHCIDevice),
+VMSTATE_UINT32(port_regs.scr_ctl, AHCIDevice),
+VMSTATE_UINT32(port_regs.scr_err, AHCIDevice),
+VMSTATE_UINT32(port_regs.scr_act, AHCIDevice),
+VMSTATE_UINT32(port_regs.cmd_issue, AHCIDevice),
+VMSTATE_END_OF_LIST()
+},
+};
+
+static int ahci_state_post_load(void *opaque, int version_id)
+{
+int i;
+AHCIState *s = opaque;
+
+for (i = 0; i < s->ports; i++) {
+AHCIPortRegs *pr = &s->dev[i].port_regs;
+
+map_page(&s->dev[i].lst,
+ ((uint64_t)pr->lst_addr_hi << 32) | pr->lst_addr, 1024);
+map_page(&s->dev[i].res_fis,
+ ((uint64_t)pr->fis_addr_hi << 32) | pr->fis_addr, 256);
+}
+
+return 0;
+}
+
+const VMStateDescription vmstate_ahci = {
+.name = "ahci",
+.version_id = 1,
+.post_load = ahci_state_post_load,
+.fields = (VMStateField []) {
+VMSTATE_STRUCT_VARRAY_POINTER_INT32(dev, AHCIState, ports,
+ vmstate_ahci_device, AHCIDevice),
+VMSTATE_UINT32(control_regs.cap, AHCIState),
+VMSTATE_UINT32(control_regs.ghc, AHCIState),
+VMSTATE_UINT32(control_regs.irqstatus, AHCIState),
+VMSTATE_UINT32(control_regs.impl, AHCIState),
+VMSTATE_UINT32(control_regs.version, AHCIState),
+VMSTATE_UINT32(idp_index, AHCIState),
+VMSTATE_END_OF_LIST()
+},
+};
+
typedef struct SysbusAHCIState {
SysBusDevice busdev;
AHCIState ahci;
@@ -1212,7 +1271,10 @@ typedef struct SysbusAHCIState {
static const VMStateDescription vmstate_sysbus_ahci = {
.name = "sysbus-ahci",
-.unmigratable = 1,
+.fields = (VMStateField []) {
+VMSTATE_AHCI(ahci, AHCIPCIState),
+VMSTATE_END_OF_LIST()
+},
};
static void sysbus_ahci_reset(DeviceState *dev)
diff --git a/hw/ide/ahci.h b/hw/ide/ahci.h
index 1200a56..7719dbf 100644
--- a/hw/ide/ahci.h
+++ b/hw/ide/ahci.h
@@ -307,6 +307,16 @@ typedef struct AHCIPCIState {
AHCIState ahci;
} AHCIPCIState;
+extern const VMStateDescription vmstate_ahci;
+
+#define VMSTATE_AHCI(_field, _state) { \
+.name = (stringify(_field)), \
+.size = sizeof(AHCIState), \
+.vmsd = &vmstate_ahci, \
+.flags = VMS_STRUCT,\
+.offset = vmstate_offset_value(_state, _field, AHCIState), \
+}
+
typedef struct NCQFrame {
uint8_t fis_type;
uint8_t c;
diff --git a/hw/ide/ich.c b/hw/ide/ich.c
index 272b773..ae6f56f 100644
--- a/hw/ide/ich.c
+++ b/hw/ide/ich.c
@@ -79,9 +79,14 @@
#define ICH9_IDP_INDEX 0x10
#define ICH9_IDP_INDEX_LOG2 0x04
-static const VMStateDescription vmstate_ahci = {
+static const VMStateDescription vmstate_ich9_ahci = {
.name = "ahci",
-.unmigratable = 1,
+.version_id = 1,
+.fields = (VMStateField []) {
+VMSTATE_PCI_DEVICE(card, AHCIPCIState),
+VMSTATE_AHCI(ahci, AHCIPCIState),
+VMSTATE_END_OF_LIST()
+},
};
static void pci_ich9_reset(DeviceState *dev)
@@ -152,7 +157,7 @@ static void ich_ahci_class_init(ObjectClass *klass, void
*data)
k->device_id = PCI_DEVICE_ID_INTEL_82801IR;
k->revision = 0x02;
k->class_id = PCI_CLASS_STORAGE_SA
[Qemu-devel] [PATCH 1/7] block: correctly set the keep_read_only flag
I believe the bs->keep_read_only flag is supposed to reflect
the initial open state of the device. If the device is initially
opened R/O, then commit operations, or reopen operations changing
to R/W, are prohibited.
Currently, the keep_read_only flag is only accurate for the active
layer, and its backing file. Subsequent images end up always having
the keep_read_only flag set.
For instance, what happens now:
[ base ] kro = 1, ro = 1
|
v
[ snap-1 ] kro = 1, ro = 1
|
v
[ snap-2 ] kro = 0, ro = 1
|
v
[ active ] kro = 0, ro = 0
What we want:
[ base ] kro = 0, ro = 1
|
v
[ snap-1 ] kro = 0, ro = 1
|
v
[ snap-2 ] kro = 0, ro = 1
|
v
[ active ] kro = 0, ro = 0
Signed-off-by: Jeff Cody
---
block.c | 16 +++-
block.h | 1 +
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/block.c b/block.c
index 470bdcc..e31b76f 100644
--- a/block.c
+++ b/block.c
@@ -655,7 +655,7 @@ static int bdrv_open_common(BlockDriverState *bs, const
char *filename,
* Clear flags that are internal to the block layer before opening the
* image.
*/
-open_flags &= ~(BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING);
+open_flags &= ~(BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING | BDRV_O_ALLOW_RDWR);
/*
* Snapshots should be writable.
@@ -664,8 +664,6 @@ static int bdrv_open_common(BlockDriverState *bs, const
char *filename,
open_flags |= BDRV_O_RDWR;
}
-bs->keep_read_only = bs->read_only = !(open_flags & BDRV_O_RDWR);
-
/* Open the image, either directly or using a protocol */
if (drv->bdrv_file_open) {
ret = drv->bdrv_file_open(bs, filename, open_flags);
@@ -804,6 +802,12 @@ int bdrv_open(BlockDriverState *bs, const char *filename,
int flags,
goto unlink_and_fail;
}
+if (flags & BDRV_O_RDWR) {
+flags |= BDRV_O_ALLOW_RDWR;
+}
+
+bs->keep_read_only = !(flags & BDRV_O_ALLOW_RDWR);
+
/* Open the image */
ret = bdrv_open_common(bs, filename, flags, drv);
if (ret < 0) {
@@ -833,12 +837,6 @@ int bdrv_open(BlockDriverState *bs, const char *filename,
int flags,
bdrv_close(bs);
return ret;
}
-if (bs->is_temporary) {
-bs->backing_hd->keep_read_only = !(flags & BDRV_O_RDWR);
-} else {
-/* base image inherits from "parent" */
-bs->backing_hd->keep_read_only = bs->keep_read_only;
-}
}
if (!bdrv_key_required(bs)) {
diff --git a/block.h b/block.h
index 2e2be11..4d919c2 100644
--- a/block.h
+++ b/block.h
@@ -80,6 +80,7 @@ typedef struct BlockDevOps {
#define BDRV_O_COPY_ON_READ 0x0400 /* copy read backing sectors into image */
#define BDRV_O_INCOMING0x0800 /* consistency hint for incoming migration
*/
#define BDRV_O_CHECK 0x1000 /* open solely for consistency check */
+#define BDRV_O_ALLOW_RDWR 0x2000 /* allow reopen to change from r/o to r/w */
#define BDRV_O_CACHE_MASK (BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NO_FLUSH)
--
1.7.11.2
[Qemu-devel] [ANNOUNCE] QEMU 1.2.0-rc2 release
Hi, On behalf of the QEMU Team, I'd like to announce the availability of the first release candidate for the QEMU 1.2 release. This release is meant for testing purposes and should not be used in a production environment. http://wiki.qemu.org/download/qemu-1.2.0-rc2.tar.bz2 You can help improve the quality of the QEMU 1.2 release by testing this release and reporting bugs on Launchpad: https://bugs.launchpad.net/qemu/ The release plan for the 1.2 release is available at: http://wiki.qemu.org/Planning/1.2 And a detailed change log is available at: http://wiki.qemu.org/ChangeLog/Next Known Issues: - References are not completely released during device removal which may lead to internal memory leaks. Changelog since -rc1: - scsi-disk: Fix typo (uint32 -> uint32_t) (Stefan Weil) - msix: make [un]use vectors on reset/load optional (Michael S. Tsirkin) - kvm: get/set PV EOI MSR (Michael S. Tsirkin) - linux-headers: update to 3.6-rc3 (Michael S. Tsirkin) - target-i386: disable pv eoi to fix migration across QEMU versions (Anthony Liguori) - reset PMBA and PMREGMISC PIIX4 registers. (Gleb Natapov) - qemu-ga: Fix null pointer passed to unlink in failure branch (Stefan Weil) - memory: Fix copy&paste mistake in memory_region_iorange_write (Jan Kiszka) - ivshmem: remove redundant ioeventfd configuration (Cam Macdonell) - hw/arm_gic.c: Define .class_size in arm_gic_info TypeInfo (Peter Maydell) - tcg/mips: fix broken CONFIG_TCG_PASS_AREG0 code (Aurelien Jarno) - Update OpenBIOS PPC image (Aurelien Jarno) - target-ppc: fix altivec instructions (Aurelien Jarno) - audio/winwave: previous audio buffer should be flushed (munkyu.im) - iscsi: Set number of blocks to 0 for blank CDROM devices (Ronnie Sahlberg) - scsi: more fixes to properties for passthrough devices (Paolo Bonzini) - esp: support 24-bit DMA (Paolo Bonzini) - megasas: Add 'hba_serial' property (Hannes Reinecke) - target-mips: allow microMIPS SWP and SDP to have RD equal to BASE (Eric Johnson) - target-mips: add privilege level check to several Cop0 instructions (Eric Johnson) - Revert "fix some debug printf format strings" (malc) - Revert "vl: fix -hdachs/-hda argument order parsing issues" (malc) - Revert "qemu-options.hx: mention retrace= VGA option" (malc) - Revert "vga: add some optional CGA compatibility hacks" (malc) - Revert "i8259: add -no-spurious-interrupt-hack option" (malc) - mips-linux-user: Always support rdhwr. (Richard Henderson) - target-mips: Streamline indexed cp1 memory addressing. (Richard Henderson) - Fix order of CVT.PS.S operands (Richard Sandiford) - Fix operands of RECIP2.S and RECIP2.PS (Richard Sandiford) - linux-user: Clarify "Unable to reserve guest address space" error (Peter Maydell) - linux-user: fix emulation of getdents (Dmitry V. Levin) - linux-user: arg_table need not have global scope (Jim Meyering) - tcg/ia64: fix and optimize ld/st slow path (Aurelien Jarno) - tcg/ia64: fix prologue/epilogue (Aurelien Jarno) - tcg/arm: Fix broken CONFIG_TCG_PASS_AREG0 code (Peter Maydell) - i8259: add -no-spurious-interrupt-hack option (Matthew Ogilvie) - vga: add some optional CGA compatibility hacks (Matthew Ogilvie) - qemu-options.hx: mention retrace= VGA option (Matthew Ogilvie) - vl: fix -hdachs/-hda argument order parsing issues (Matthew Ogilvie) - target-i386/translate.c: mov to/from crN/drN: ignore mod bits (Matthew Ogilvie) - fix some debug printf format strings (Matthew Ogilvie) - ivshmem: fix memory_region_del_eventfd assertion failure (Paolo Bonzini) - qom: object_delete should unparent the object first (Paolo Bonzini) - monitor: don't try to initialize json parser when monitor is HMP (Anthony Liguori) - target-mips: Fix some helper functions (VR54xx multiplication) (Stefan Weil) - target-mips: Enable access to required RDHWR hardware registers (Meador Inge) - monitor: move json init from OPEN event to init (Anthony Liguori) - boards: add a 'none' machine type to all platforms (Anthony Liguori) Regards, Anthony Liguori
[Qemu-devel] [RFC v2 PATCH 3/6] blockdev: rename block_stream_cb to a generic block_job_cb
Signed-off-by: Jeff Cody
---
blockdev.c | 8 +---
trace-events | 2 +-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 7c83baa..68d65fb 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -53,6 +53,8 @@ static const int if_max_devs[IF_COUNT] = {
[IF_SCSI] = 7,
};
+static void block_job_cb(void *opaque, int ret);
+
/*
* We automatically delete the drive when a device using it gets
* unplugged. Questionable feature, but we can't just drop it.
@@ -1063,12 +1065,12 @@ static QObject *qobject_from_block_job(BlockJob *job)
job->speed);
}
-static void block_stream_cb(void *opaque, int ret)
+static void block_job_cb(void *opaque, int ret)
{
BlockDriverState *bs = opaque;
QObject *obj;
-trace_block_stream_cb(bs, bs->job, ret);
+trace_block_job_cb(bs, bs->job, ret);
assert(bs->job);
obj = qobject_from_block_job(bs->job);
@@ -1110,7 +1112,7 @@ void qmp_block_stream(const char *device, bool has_base,
}
stream_start(bs, base_bs, base, has_speed ? speed : 0,
- block_stream_cb, bs, &local_err);
+ block_job_cb, bs, &local_err);
if (error_is_set(&local_err)) {
error_propagate(errp, local_err);
return;
diff --git a/trace-events b/trace-events
index 9eb8f10..8d7a8d3 100644
--- a/trace-events
+++ b/trace-events
@@ -79,7 +79,7 @@ commit_start(void *bs, void *base, void *top, void *s, void
*co, void *opaque, i
# blockdev.c
qmp_block_job_cancel(void *job) "job %p"
-block_stream_cb(void *bs, void *job, int ret) "bs %p job %p ret %d"
+block_job_cb(void *bs, void *job, int ret) "bs %p job %p ret %d"
qmp_block_stream(void *bs, void *job) "bs %p job %p"
# hw/virtio-blk.c
--
1.7.11.2
[Qemu-devel] [RFC v2 PATCH 1/6] block: add support functions for live commit, to find and delete images.
Add bdrv_find_child(), and bdrv_delete_intermediate().
bdrv_find_child(): given 'bs' and the active (topmost) BDS of an image chain,
find the image that is the immediate top of 'bs'
bdrv_delete_intermediate():
Given 3 BDS (active, top, base), delete images above
base up to and including top, and set base to be the
parent of top's child node.
E.g., this converts:
bottom <- base <- intermediate <- top <- active
to
bottom <- base <- active
where top == active is permitted, although active
will not be deleted.
Signed-off-by: Jeff Cody
---
block.c | 142
block.h | 5 ++-
2 files changed, 146 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index 9470319..11e275c 100644
--- a/block.c
+++ b/block.c
@@ -1752,6 +1752,148 @@ int bdrv_change_backing_file(BlockDriverState *bs,
return ret;
}
+/* Finds the image layer immediately to the 'top' of bs.
+ *
+ * active is the current topmost image.
+ */
+BlockDriverState *bdrv_find_child(BlockDriverState *active,
+ BlockDriverState *bs)
+{
+BlockDriverState *child = NULL;
+BlockDriverState *intermediate;
+
+/* if the active bs layer is the same as the new top, then there
+ * is no image above the top, so it will be returned as the child
+ */
+if (active == bs) {
+child = active;
+} else {
+intermediate = active;
+while (intermediate->backing_hd) {
+if (intermediate->backing_hd == bs) {
+child = intermediate;
+break;
+}
+intermediate = intermediate->backing_hd;
+}
+}
+
+return child;
+}
+
+typedef struct BlkIntermediateStates {
+BlockDriverState *bs;
+QSIMPLEQ_ENTRY(BlkIntermediateStates) entry;
+} BlkIntermediateStates;
+
+
+/* deletes images above 'base' up to and including 'top', and sets the image
+ * above 'top' to have base as its backing file.
+ *
+ * E.g., this will convert the following chain:
+ * bottom <- base <- intermediate <- top <- active
+ *
+ * to
+ *
+ * bottom <- base <- active
+ *
+ * It is allowed for bottom==base, in which case it converts:
+ *
+ * base <- intermediate <- top <- active
+ *
+ * to
+ *
+ * base <- active
+ *
+ * It is also allowed for top==active, except in that case active is not
+ * deleted:
+ *
+ * base <- intermediate <- top
+ *
+ * becomes
+ *
+ * base <- top
+ */
+int bdrv_delete_intermediate(BlockDriverState *active, BlockDriverState *top,
+ BlockDriverState *base)
+{
+BlockDriverState *intermediate;
+BlockDriverState *base_bs = NULL;
+BlockDriverState *new_top_bs = NULL;
+BlkIntermediateStates *intermediate_state, *next;
+int ret = -1;
+
+QSIMPLEQ_HEAD(states_to_delete, BlkIntermediateStates) states_to_delete;
+QSIMPLEQ_INIT(&states_to_delete);
+
+if (!top->drv || !base->drv) {
+goto exit;
+}
+
+new_top_bs = bdrv_find_child(active, top);
+
+/* special case of new_top_bs->backing_hd already pointing to base -
nothing
+ * to do, no intermediate images
+ */
+if (new_top_bs->backing_hd == base) {
+ret = 0;
+goto exit;
+}
+
+if (new_top_bs == NULL) {
+/* we could not find the image above 'top', this is an error */
+goto exit;
+}
+
+/* if the active and top image passed in are the same, then we
+ * can't delete the active, so we start one below
+ */
+intermediate = (active == top) ? active->backing_hd : top;
+
+/* now we will go down through the list, and add each BDS we find
+ * into our deletion queue, until we hit the 'base'
+ */
+while (intermediate) {
+intermediate_state = g_malloc0(sizeof(BlkIntermediateStates));
+intermediate_state->bs = intermediate;
+QSIMPLEQ_INSERT_TAIL(&states_to_delete, intermediate_state, entry);
+
+if (intermediate->backing_hd == base) {
+base_bs = intermediate->backing_hd;
+break;
+}
+intermediate = intermediate->backing_hd;
+}
+if (base_bs == NULL) {
+/* something went wrong, we did not end at the base. safely
+ * unravel everything, and exit with error */
+goto exit;
+}
+
+/* success - we can delete the intermediate states, and link top->base */
+ret = bdrv_change_backing_file(new_top_bs, base_bs->filename,
+ base_bs->drv ? base_bs->drv->format_name :
"");
+if (ret) {
+goto exit;
+}
+new_top_bs->backing_hd = base_bs;
+
+
+QSIMPLEQ_FOREACH_SAFE(intermediate_state, &states_to_delete, entry, next) {
+/* so that bdrv_close() does not recursively close the chain */
+intermediate_state->bs->
[Qemu-devel] [RFC v2 PATCH 2/6] block: add live block commit functionality
This adds the live commit coroutine. This iteration focuses on the
commit only below the active layer, and not the active layer itself.
The behaviour is similar to block streaming; the sectors are walked
through, and anything that exists above 'base' is committed back down
into base. At the end, intermediate images are deleted, and the
chain stitched together. Images are restored to their original open
flags upon completion.
Signed-off-by: Jeff Cody
---
block/Makefile.objs | 1 +
block/commit.c | 202
block_int.h | 19 +
trace-events| 2 +
4 files changed, 224 insertions(+)
create mode 100644 block/commit.c
diff --git a/block/Makefile.objs b/block/Makefile.objs
index b5754d3..4a136b8 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -4,6 +4,7 @@ block-obj-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o
qed-cluster.o
block-obj-y += qed-check.o
block-obj-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
block-obj-y += stream.o
+block-obj-y += commit.o
block-obj-$(CONFIG_WIN32) += raw-win32.o
block-obj-$(CONFIG_POSIX) += raw-posix.o
block-obj-$(CONFIG_LIBISCSI) += iscsi.o
diff --git a/block/commit.c b/block/commit.c
new file mode 100644
index 000..bd3d882
--- /dev/null
+++ b/block/commit.c
@@ -0,0 +1,202 @@
+/*
+ * Live block commit
+ *
+ * Copyright Red Hat, Inc. 2012
+ *
+ * Authors:
+ * Jeff Cody
+ * Based on stream.c by Stefan Hajnoczi
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include "trace.h"
+#include "block_int.h"
+#include "qemu/ratelimit.h"
+
+enum {
+/*
+ * Size of data buffer for populating the image file. This should be large
+ * enough to process multiple clusters in a single call, so that populating
+ * contiguous regions of the image is efficient.
+ */
+COMMIT_BUFFER_SIZE = 512 * 1024, /* in bytes */
+};
+
+#define SLICE_TIME 1ULL /* ns */
+
+typedef struct CommitBlockJob {
+BlockJob common;
+RateLimit limit;
+BlockDriverState *active;
+BlockDriverState *top;
+BlockDriverState *base;
+BlockErrorAction on_error;
+int base_flags;
+int top_flags;
+} CommitBlockJob;
+
+static int coroutine_fn commit_populate(BlockDriverState *bs,
+BlockDriverState *base,
+int64_t sector_num, int nb_sectors,
+void *buf)
+{
+if (bdrv_read(bs, sector_num, buf, nb_sectors)) {
+return -EIO;
+}
+if (bdrv_write(base, sector_num, buf, nb_sectors)) {
+return -EIO;
+}
+return 0;
+}
+
+static void coroutine_fn commit_run(void *opaque)
+{
+CommitBlockJob *s = opaque;
+BlockDriverState *active = s->active;
+BlockDriverState *top = s->top;
+BlockDriverState *base = s->base;
+BlockDriverState *top_child = NULL;
+int64_t sector_num, end;
+int error = 0;
+int ret = 0;
+int n = 0;
+void *buf;
+int bytes_written = 0;
+
+s->common.len = bdrv_getlength(top);
+if (s->common.len < 0) {
+block_job_complete(&s->common, s->common.len);
+return;
+}
+
+top_child = bdrv_find_child(active, top);
+
+end = s->common.len >> BDRV_SECTOR_BITS;
+buf = qemu_blockalign(top, COMMIT_BUFFER_SIZE);
+
+for (sector_num = 0; sector_num < end; sector_num += n) {
+uint64_t delay_ns = 0;
+bool copy;
+
+wait:
+/* Note that even when no rate limit is applied we need to yield
+ * with no pending I/O here so that qemu_aio_flush() returns.
+ */
+block_job_sleep_ns(&s->common, rt_clock, delay_ns);
+if (block_job_is_cancelled(&s->common)) {
+break;
+}
+/* Copy if allocated above the base */
+ret = bdrv_co_is_allocated_above(top, base, sector_num,
+ COMMIT_BUFFER_SIZE / BDRV_SECTOR_SIZE,
+ &n);
+copy = (ret == 1);
+trace_commit_one_iteration(s, sector_num, n, ret);
+if (ret >= 0 && copy) {
+if (s->common.speed) {
+delay_ns = ratelimit_calculate_delay(&s->limit, n);
+if (delay_ns > 0) {
+goto wait;
+}
+}
+ret = commit_populate(top, base, sector_num, n, buf);
+bytes_written += n * BDRV_SECTOR_SIZE;
+}
+if (ret < 0) {
+if (s->on_error == BLOCK_ERR_STOP_ANY ||
+s->on_error == BLOCK_ERR_STOP_ENOSPC) {
+n = 0;
+continue;
+}
+if (error == 0) {
+error = ret;
+}
+if (s->on_error == BLOCK_ERR_REPORT) {
+break;
+}
+}
+ret = 0;
+
+/* Publish progre
[Qemu-devel] [RFC v2 PATCH 0/6] Live block commit
Live block commit. I originally had intended for this RFC series to include the more complicated case of a live commit of the active layer, but removed it for this commit in the hopes of making it into the soft feature freeze for 1.2, so this series is the simpler case. This series adds the basic case, of a live commit between two images below the active layer, e.g.: [base] <--- [snp-1] <--- [snp-2] <--- [snp-3] <--- [active] can be collapsed down via commit, into: [base] <--- [active] or, [base] <--- [snp-1] <--- [active], [base] <--- [snp-3] <--- [active], etc.. TODO: * qemu-io tests (in progress) * 'stage-2' of live commit functionality, to be able to push down the active layer. This structured something like mirroring, to allow for convergence. Changes from the RFC v1 series: * This patch series is not on top of Paolo's blk mirror series yet, to make it easier to apply independently if desired. This means some of what was in the previous RFC series is not in this one (BlockdevOnError, for instance), but that can be easily added in once Paolo's series are in. * This patches series is dependent on the reopen() series with transactional reopen. * The target release for this series is 1.3 * Found some mistakes in the reopen calls * Dropped the BlockdevOnError argument (for now), will add in if rebasing on top of Paolo's series. * Used the new qerror system Jeff Cody (6): 1/6 block: add support functions for live commit, to find and delete images. 2/6 block: add live block commit functionality 3/6 blockdev: rename block_stream_cb to a generic block_job_cb 4/6 qerror: new error for live block commit, QERR_TOP_NOT_FOUND 5/6 block: helper function, to find the base image of a chain 6/6 QAPI: add command for live block commit, 'block-commit' block.c | 158 block.h | 6 +- block/Makefile.objs | 1 + block/commit.c | 202 block_int.h | 19 + blockdev.c | 91 ++- qapi-schema.json| 30 qerror.h| 3 + qmp-commands.hx | 6 ++ trace-events| 4 +- 10 files changed, 515 insertions(+), 5 deletions(-) create mode 100644 block/commit.c -- 1.7.11.2
[Qemu-devel] [PATCH 6/7] block: qcow2 image file reopen
These are the stubs for the file reopen drivers for the qcow2 format.
There is currently nothing that needs to be done by the qcow2 driver
in reopen.
Signed-off-by: Jeff Cody
---
block/qcow2.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/block/qcow2.c b/block/qcow2.c
index 8f183f1..d462093 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -52,6 +52,7 @@ typedef struct {
uint32_t magic;
uint32_t len;
} QCowExtension;
+
#define QCOW2_EXT_MAGIC_END 0
#define QCOW2_EXT_MAGIC_BACKING_FORMAT 0xE2792ACA
#define QCOW2_EXT_MAGIC_FEATURE_TABLE 0x6803f857
@@ -558,6 +559,24 @@ static int qcow2_set_key(BlockDriverState *bs, const char
*key)
return 0;
}
+/* We have nothing to do for QCOW2 reopen, stubs just return
+ * success */
+static int qcow2_reopen_prepare(BDRVReopenState *state, Error **errp)
+{
+return 0;
+}
+
+static void qcow2_reopen_commit(BDRVReopenState *state)
+{
+return;
+}
+
+static void qcow2_reopen_abort(BDRVReopenState *state)
+{
+return;
+}
+
+
static int coroutine_fn qcow2_co_is_allocated(BlockDriverState *bs,
int64_t sector_num, int nb_sectors, int *pnum)
{
@@ -1679,6 +1698,9 @@ static BlockDriver bdrv_qcow2 = {
.bdrv_probe = qcow2_probe,
.bdrv_open = qcow2_open,
.bdrv_close = qcow2_close,
+.bdrv_reopen_prepare = qcow2_reopen_prepare,
+.bdrv_reopen_commit = qcow2_reopen_commit,
+.bdrv_reopen_abort= qcow2_reopen_abort,
.bdrv_create= qcow2_create,
.bdrv_co_is_allocated = qcow2_co_is_allocated,
.bdrv_set_key = qcow2_set_key,
--
1.7.11.2
[Qemu-devel] [PATCH 7/7] block: qcow image file reopen
These are the stubs for the file reopen drivers for the qcow format.
There is currently nothing that needs to be done by the qcow driver
in reopen.
Signed-off-by: Jeff Cody
---
block/qcow.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/block/qcow.c b/block/qcow.c
index 7b5ab87..f201575 100644
--- a/block/qcow.c
+++ b/block/qcow.c
@@ -197,6 +197,26 @@ static int qcow_open(BlockDriverState *bs, int flags)
return ret;
}
+
+/* We have nothing to do for QCOW reopen, stubs just return
+ * success */
+static int qcow_reopen_prepare(BDRVReopenState *state, Error **errp)
+{
+return 0;
+}
+
+static void qcow_reopen_commit(BDRVReopenState *state)
+{
+return;
+}
+
+static void qcow_reopen_abort(BDRVReopenState *state)
+{
+return;
+}
+
+
+
static int qcow_set_key(BlockDriverState *bs, const char *key)
{
BDRVQcowState *s = bs->opaque;
@@ -868,6 +888,9 @@ static BlockDriver bdrv_qcow = {
.bdrv_probe= qcow_probe,
.bdrv_open = qcow_open,
.bdrv_close= qcow_close,
+.bdrv_reopen_prepare = qcow_reopen_prepare,
+.bdrv_reopen_commit = qcow_reopen_commit,
+.bdrv_reopen_abort = qcow_reopen_abort,
.bdrv_create = qcow_create,
.bdrv_co_readv = qcow_co_readv,
--
1.7.11.2
[Qemu-devel] [RFC v2 PATCH 5/6] block: helper function, to find the base image of a chain
This is a simple helper function, that will return the base image
of a given image chain.
Signed-off-by: Jeff Cody
---
block.c | 16
block.h | 1 +
2 files changed, 17 insertions(+)
diff --git a/block.c b/block.c
index 11e275c..5f58600 100644
--- a/block.c
+++ b/block.c
@@ -3137,6 +3137,22 @@ int bdrv_get_backing_file_depth(BlockDriverState *bs)
return 1 + bdrv_get_backing_file_depth(bs->backing_hd);
}
+BlockDriverState *bdrv_find_base(BlockDriverState *bs)
+{
+BlockDriverState *curr_bs = NULL;
+
+if (!bs) {
+return NULL;
+}
+
+curr_bs = bs;
+
+while (curr_bs->backing_hd) {
+curr_bs = curr_bs->backing_hd;
+}
+return curr_bs;
+}
+
#define NB_SUFFIXES 4
char *get_human_readable_size(char *buf, int buf_size, int64_t size)
diff --git a/block.h b/block.h
index ee76869..376cc50 100644
--- a/block.h
+++ b/block.h
@@ -201,6 +201,7 @@ int bdrv_commit_all(void);
int bdrv_change_backing_file(BlockDriverState *bs,
const char *backing_file, const char *backing_fmt);
void bdrv_register(BlockDriver *bdrv);
+BlockDriverState *bdrv_find_base(BlockDriverState *bs);
int bdrv_delete_intermediate(BlockDriverState *active, BlockDriverState *top,
BlockDriverState *base);
BlockDriverState *bdrv_find_child(BlockDriverState *active,
--
1.7.11.2
[Qemu-devel] [PATCH 5/7] block: qed image file reopen
These are the stubs for the file reopen drivers for the qed format.
There is currently nothing that needs to be done by the qed driver
in reopen.
Signed-off-by: Jeff Cody
---
block/qed.c | 20
1 file changed, 20 insertions(+)
diff --git a/block/qed.c b/block/qed.c
index a02dbfd..231e86a 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -505,6 +505,23 @@ out:
return ret;
}
+/* We have nothing to do for QED reopen, stubs just return
+ * success */
+static int bdrv_qed_reopen_prepare(BDRVReopenState *state, Error **errp)
+{
+return 0;
+}
+
+static void bdrv_qed_reopen_commit(BDRVReopenState *state)
+{
+return;
+}
+
+static void bdrv_qed_reopen_abort(BDRVReopenState *state)
+{
+return;
+}
+
static void bdrv_qed_close(BlockDriverState *bs)
{
BDRVQEDState *s = bs->opaque;
@@ -1553,6 +1570,9 @@ static BlockDriver bdrv_qed = {
.bdrv_rebind = bdrv_qed_rebind,
.bdrv_open= bdrv_qed_open,
.bdrv_close = bdrv_qed_close,
+.bdrv_reopen_prepare = bdrv_qed_reopen_prepare,
+.bdrv_reopen_commit = bdrv_qed_reopen_commit,
+.bdrv_reopen_abort= bdrv_qed_reopen_abort,
.bdrv_create = bdrv_qed_create,
.bdrv_co_is_allocated = bdrv_qed_co_is_allocated,
.bdrv_make_empty = bdrv_qed_make_empty,
--
1.7.11.2
Re: [Qemu-devel] [PATCH 5/6] Fix enumeration typo error
On Thu, 23 Aug 2012 13:14:25 +0800 Lei Li wrote: > Signed-off-by: Lei Li Reviewed-by: Luiz Capitulino PS: CC'ing qemu-trivial as per Eric's suggestion. > --- > qapi-schema-guest.json |2 +- > qapi-schema.json |4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json > index d955cf1..ed0eb69 100644 > --- a/qapi-schema-guest.json > +++ b/qapi-schema-guest.json > @@ -293,7 +293,7 @@ > ## > # @GuestFsFreezeStatus > # > -# An enumation of filesystem freeze states > +# An enumeration of filesystem freeze states > # > # @thawed: filesystems thawed/unfrozen > # > diff --git a/qapi-schema.json b/qapi-schema.json > index 1346bcc..8e13a05 100644 > --- a/qapi-schema.json > +++ b/qapi-schema.json > @@ -118,7 +118,7 @@ > ## > # @RunState > # > -# An enumation of VM run states. > +# An enumeration of VM run states. > # > # @debug: QEMU is running on a debugger > # > @@ -836,7 +836,7 @@ > ## > # @SpiceQueryMouseMode > # > -# An enumation of Spice mouse states. > +# An enumeration of Spice mouse states. > # > # @client: Mouse cursor position is determined by the client. > #
Re: [Qemu-devel] [PATCH 3/6] QAPI: Introduce memchar_write QMP command
On Thu, 23 Aug 2012 13:14:23 +0800
Lei Li wrote:
> Signed-off-by: Lei Li
> ---
> hmp-commands.hx | 16
> hmp.c| 15 +++
> hmp.h|1 +
> qapi-schema.json | 28
> qemu-char.c | 36
> qmp-commands.hx | 33 +
> 6 files changed, 129 insertions(+), 0 deletions(-)
>
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index f6104b0..829aea1 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -797,6 +797,22 @@ Inject an NMI on the given CPU (x86 only).
> ETEXI
>
> {
> +.name = "memchar-write",
> +.args_type = "chardev:s,size:i,data:s,format:s?",
> +.params = "chardev size data",
> +.help = "Provide writing interface for memchardev. Write"
> + "'data' to memchr char device with size 'size'",
> +.mhandler.cmd = hmp_memchar_write,
> +},
> +
> +STEXI
> +@item memchar-write @var{chardev} @var{size} @var{data} @var{format}
> +@findex memchar-write
> +Provide writing interface for memchardev. Write @var{data}
> +to memchr char device with size @var{size}.
> +ETEXI
> +
> +{
> .name = "migrate",
> .args_type = "detach:-d,blk:-b,inc:-i,uri:s",
> .params = "[-d] [-b] [-i] uri",
> diff --git a/hmp.c b/hmp.c
> index 81c8acb..c1164eb 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -668,6 +668,21 @@ void hmp_pmemsave(Monitor *mon, const QDict *qdict)
> hmp_handle_error(mon, &errp);
> }
>
> +void hmp_memchar_write(Monitor *mon, const QDict *qdict)
> +{
> +uint32_t size = qdict_get_int(qdict, "size");
> +const char *chardev = qdict_get_str(qdict, "chardev");
> +const char *data = qdict_get_str(qdict, "data");
> +int con = qdict_get_try_bool(qdict, "utf8", 0);
> +enum DataFormat format;
> +Error *errp = NULL;
> +
> +format = con ? DATA_FORMAT_UTF8 : DATA_FORMAT_BASE64;
> +qmp_memchar_write(chardev, size, data, true, format, &errp);
> +
> +hmp_handle_error(mon, &errp);
> +}
> +
> static void hmp_cont_cb(void *opaque, int err)
> {
> if (!err) {
> diff --git a/hmp.h b/hmp.h
> index 7dd93bf..15e1311 100644
> --- a/hmp.h
> +++ b/hmp.h
> @@ -43,6 +43,7 @@ void hmp_system_powerdown(Monitor *mon, const QDict *qdict);
> void hmp_cpu(Monitor *mon, const QDict *qdict);
> void hmp_memsave(Monitor *mon, const QDict *qdict);
> void hmp_pmemsave(Monitor *mon, const QDict *qdict);
> +void hmp_memchar_write(Monitor *mon, const QDict *qdict);
> void hmp_cont(Monitor *mon, const QDict *qdict);
> void hmp_system_wakeup(Monitor *mon, const QDict *qdict);
> void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
> diff --git a/qapi-schema.json b/qapi-schema.json
> index bd8ad74..2fc1a27 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -235,6 +235,34 @@
> ##
> { 'command': 'query-chardev', 'returns': ['ChardevInfo'] }
>
> +{ 'enum': 'DataFormat'
> + 'data': [ 'utf8', 'base64' ] }
> +
> +##
> +# @memchar-write:
> +#
> +# Provide writing interface for memchardev. Write data to memchar
> +# char device.
> +#
> +# @chardev: the name of the memchar char device.
> +#
> +# @size: the size to write in bytes.
> +#
> +# @data: the source data write to memchar.
> +#
> +# @format: #optional the format of the data write to memchardev, by
> +# default is 'utf8'.
> +#
> +# Returns: Nothing on success
> +# If @chardev is not a valid memchr device, DeviceNotFound
> +# If an I/O error occurs while writing, IOError
> +#
> +# Since: 1.3
> +##
> +{ 'command': 'memchar-write',
> + 'data': {'chardev': 'str', 'size': 'int', 'data': 'str',
> + '*format': 'DataFormat'} }
> +
> ##
> # @CommandInfo:
> #
> diff --git a/qemu-char.c b/qemu-char.c
> index b21b93a..d8f3238 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -2647,6 +2647,42 @@ size_t qemu_chr_mem_osize(const CharDriverState *chr)
> return d->cbuf_count;
> }
>
> +void qmp_memchar_write(const char *chardev, int64_t size,
> + const char *data, bool has_format,
> + enum DataFormat format,
> +
> + Error **errp)
> +{
> +CharDriverState *chr;
> +guchar *write_data;
> +int ret;
> +gsize write_count;
> +
> +chr = qemu_chr_find(chardev);
> +
> +if(!chr) {
> +error_set(errp, QERR_DEVICE_NOT_FOUND, chardev);
> +return;
> +}
> +
> +write_count = (gsize)size;
> +
> +if (has_format) {
> +if (format == DATA_FORMAT_BASE64) {
> +write_data = g_base64_decode(data, &write_count);
> +}
> +} else {
> +write_data = (uint8_t *)data;
> +}
> +
> +ret = mem_chr_write(chr, write_data, size);
> +if (ret <= 0) {
> +error_set(errp, QERR_IO_ERROR);
We're only using the QERR_ macros for the errors we have to maintain
compatibility (they're listed in ErrorC
Re: [Qemu-devel] Posix timer syscalls ; dealing with the timer_t type
Andreas Färber wrote: > Hi, > > Am 30.08.2012 14:30, schrieb Erik de Castro Lopo: > > I'm working on implementing Posix timers in linux-user. > > > > I'm having trouble figuring out how to handle the timer_t type. > > Consider the following code with say 32 bit ARM being emulated > > on 64 bit x86-64: > > > > timer_t timerid; > > > > err = timer_create(clockid, &sev, &timerid); > > err = timer_gettime(timerid, &curr); > > > > The issue is that memory for the timer_t value in the 32 bit > > target is alloacted on the stack (where the timer_t is 4 bytes) > > but the value provided by the 64 bit host where the timer_t is > > 8 bytes. > > > > Any suggestions on dealing with this? > > typedef target_ulong target_timer_t; > > or abi_ulong, or without the u if signed. The timer_t type is actually an alias for void*. > Depending on where/how you use this, you may need to convert back and > forth between host and target values. The complication is that each call to the host's timer_create() function generates 64 bits of data, but on the 32 bit target, where there are only 32 bits to store that data. The only obvious solution is store the 64 bit pointers from the host in a table and return the index into that table to the target as its version of the timer_t. Does that make sense? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/
[Qemu-devel] [PATCH 2/7] block: Framework for reopening files safely
This is based heavily on Supriya Kannery's bdrv_reopen()
patch series.
This provides a transactional method to reopen multiple
images files safely.
Image files are queue for reopen via bdrv_reopen_queue(), and the
reopen occurs when bdrv_reopen_multiple() is called. Changes are
staged in bdrv_reopen_prepare() and in the equivalent driver level
functions. If any of the staged images fails a prepare, then all
of the images left untouched, and the staged changes for each image
abandoned.
Signed-off-by: Jeff Cody
---
block.c | 226 ++
block.h | 15
block_int.h | 13
qemu-common.h | 1 +
4 files changed, 255 insertions(+)
diff --git a/block.c b/block.c
index e31b76f..9470319 100644
--- a/block.c
+++ b/block.c
@@ -857,6 +857,232 @@ unlink_and_fail:
return ret;
}
+/*
+ * Adds a BlockDriverState to a simple queue for an atomic, transactional
+ * reopen of multiple devices.
+ *
+ * bs_queue can either be an existing BlockReopenQueue that has had
QSIMPLE_INIT
+ * already performed, or alternatively may be NULL a new BlockReopenQueue will
+ * be created and initialized. This newly created BlockReopenQueue should be
+ * passed back in for subsequent calls that are intended to be of the same
+ * atomic 'set'.
+ *
+ * bs is the BlockDriverState to add to the reopen queue.
+ *
+ * flags contains the open flags for the associated bs
+ *
+ * returns a pointer to bs_queue, which is either the newly allocated
+ * bs_queue, or the existing bs_queue being used.
+ *
+ */
+BlockReopenQueue *bdrv_reopen_queue(BlockReopenQueue *bs_queue,
+BlockDriverState *bs, int flags)
+{
+assert(bs != NULL);
+
+BlockReopenQueueEntry *bs_entry;
+if (bs_queue == NULL) {
+bs_queue = g_new0(BlockReopenQueue, 1);
+QSIMPLEQ_INIT(bs_queue);
+}
+
+if (bs->file) {
+bdrv_reopen_queue(bs_queue, bs->file, flags);
+}
+
+bs_entry = g_new0(BlockReopenQueueEntry, 1);
+QSIMPLEQ_INSERT_TAIL(bs_queue, bs_entry, entry);
+
+bs_entry->state = g_new0(BDRVReopenState, 1);
+bs_entry->state->bs = bs;
+bs_entry->state->flags = flags;
+
+return bs_queue;
+}
+
+/*
+ * Reopen multiple BlockDriverStates atomically & transactionally.
+ *
+ * The queue passed in (bs_queue) must have been built up previous
+ * via bdrv_reopen_queue().
+ *
+ * Reopens all BDS specified in the queue, with the appropriate
+ * flags. All devices are prepared for reopen, and failure of any
+ * device will cause all device changes to be abandonded, and intermediate
+ * data cleaned up.
+ *
+ * If all devices prepare successfully, then the changes are committed
+ * to all devices.
+ *
+ */
+int bdrv_reopen_multiple(BlockReopenQueue *bs_queue, Error **errp)
+{
+int ret = -1;
+BlockReopenQueueEntry *bs_entry;
+Error *local_err = NULL;
+
+assert(bs_queue != NULL);
+
+bdrv_drain_all();
+
+QSIMPLEQ_FOREACH(bs_entry, bs_queue, entry) {
+if (bdrv_reopen_prepare(bs_entry->state, &local_err)) {
+error_propagate(errp, local_err);
+goto cleanup;
+}
+bs_entry->prepared = true;
+}
+
+/* If we reach this point, we have success and just need to apply the
+ * changes
+ */
+QSIMPLEQ_FOREACH(bs_entry, bs_queue, entry) {
+bdrv_reopen_commit(bs_entry->state);
+}
+
+ret = 0;
+
+cleanup:
+QSIMPLEQ_FOREACH(bs_entry, bs_queue, entry) {
+if (ret && bs_entry->prepared) {
+bdrv_reopen_abort(bs_entry->state);
+}
+g_free(bs_entry->state);
+g_free(bs_entry);
+}
+g_free(bs_queue);
+return ret;
+}
+
+
+/* Reopen a single BlockDriverState with the specified flags. */
+int bdrv_reopen(BlockDriverState *bs, int bdrv_flags, Error **errp)
+{
+int ret = -1;
+Error *local_err = NULL;
+BlockReopenQueue *queue = bdrv_reopen_queue(NULL, bs, bdrv_flags);
+
+ret = bdrv_reopen_multiple(queue, &local_err);
+if (local_err != NULL) {
+error_propagate(errp, local_err);
+}
+return ret;
+}
+
+
+/*
+ * Prepares a BlockDriverState for reopen. All changes are staged in the
+ * 'reopen_state' field of the BlockDriverState, which must be NULL when
+ * entering (all previous reopens must have completed for the BDS).
+ *
+ * bs is the BlockDriverState to reopen
+ * flags are the new open flags
+ *
+ * Returns 0 on success, non-zero on error. On error errp will be set
+ * as well.
+ *
+ * On failure, bdrv_reopen_abort() will be called to clean up any data.
+ * It is the responsibility of the caller to then call the abort() or
+ * commit() for any other BDS that have been left in a prepare() state
+ *
+ */
+int bdrv_reopen_prepare(BDRVReopenState *reopen_state, Error **errp)
+{
+int ret = -1;
+Error *local_err = NULL;
+BlockDriver *drv;
+
+assert(reopen_state != NULL);
+assert(reopen_state->bs->drv != NULL);
+drv = reopen_state->
[Qemu-devel] [PATCH 3/7] block: raw-posix image file reopen
This is derived from the Supriya Kannery's reopen patches.
This contains the raw-posix driver changes for the bdrv_reopen_*
functions. All changes are staged into a temporary scratch buffer
during the prepare() stage, and copied over to the live structure
during commit(). Upon abort(), all changes are abandoned, and the
live structures are unmodified.
The _prepare() will create an extra fd - either by means of a dup,
if possible, or opening a new fd if not (for instance, access
control changes). Upon _commit(), the original fd is closed and
the new fd is used. Upon _abort(), the duplicate/new fd is closed.
Signed-off-by: Jeff Cody
---
block/raw-posix.c | 153 +-
1 file changed, 139 insertions(+), 14 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 6be20b1..48086d7 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -140,6 +140,15 @@ typedef struct BDRVRawState {
#endif
} BDRVRawState;
+typedef struct BDRVRawReopenState {
+BDRVReopenState reopen_state;
+int fd;
+int open_flags;
+uint8_t *aligned_buf;
+unsigned aligned_buf_size;
+BDRVRawState *stash_s;
+} BDRVRawReopenState;
+
static int fd_open(BlockDriverState *bs);
static int64_t raw_getlength(BlockDriverState *bs);
@@ -185,6 +194,28 @@ static int raw_normalize_devicepath(const char **filename)
}
#endif
+static void raw_parse_flags(int bdrv_flags, int *open_flags)
+{
+assert(open_flags != NULL);
+
+*open_flags |= O_BINARY;
+*open_flags &= ~O_ACCMODE;
+if (bdrv_flags & BDRV_O_RDWR) {
+*open_flags |= O_RDWR;
+} else {
+*open_flags |= O_RDONLY;
+}
+
+/* Use O_DSYNC for write-through caching, no flags for write-back caching,
+ * and O_DIRECT for no caching. */
+if ((bdrv_flags & BDRV_O_NOCACHE)) {
+*open_flags |= O_DIRECT;
+}
+if (!(bdrv_flags & BDRV_O_CACHE_WB)) {
+*open_flags |= O_DSYNC;
+}
+}
+
static int raw_open_common(BlockDriverState *bs, const char *filename,
int bdrv_flags, int open_flags)
{
@@ -196,20 +227,8 @@ static int raw_open_common(BlockDriverState *bs, const
char *filename,
return ret;
}
-s->open_flags = open_flags | O_BINARY;
-s->open_flags &= ~O_ACCMODE;
-if (bdrv_flags & BDRV_O_RDWR) {
-s->open_flags |= O_RDWR;
-} else {
-s->open_flags |= O_RDONLY;
-}
-
-/* Use O_DSYNC for write-through caching, no flags for write-back caching,
- * and O_DIRECT for no caching. */
-if ((bdrv_flags & BDRV_O_NOCACHE))
-s->open_flags |= O_DIRECT;
-if (!(bdrv_flags & BDRV_O_CACHE_WB))
-s->open_flags |= O_DSYNC;
+s->open_flags = open_flags;
+raw_parse_flags(bdrv_flags, &s->open_flags);
s->fd = -1;
fd = qemu_open(filename, s->open_flags, 0644);
@@ -283,6 +302,109 @@ static int raw_open(BlockDriverState *bs, const char
*filename, int flags)
return raw_open_common(bs, filename, flags, 0);
}
+static int raw_reopen_prepare(BDRVReopenState *state, Error **errp)
+{
+BDRVRawState *s;
+BDRVRawReopenState *raw_s;
+int ret = 0;
+
+assert(state != NULL);
+assert(state->bs != NULL);
+
+s = state->bs->opaque;
+
+state->opaque = g_malloc0(sizeof(BDRVRawReopenState));
+raw_s = state->opaque;
+
+raw_parse_flags(state->flags, &raw_s->open_flags);
+
+/*
+ * If we didn't have BDRV_O_NOCACHE set before, we may not have allocated
+ * aligned_buf
+ */
+if ((state->flags & BDRV_O_NOCACHE)) {
+/*
+ * Allocate a buffer for read/modify/write cycles. Choose the size
+ * pessimistically as we don't know the block size yet.
+ */
+raw_s->aligned_buf_size = 32 * MAX_BLOCKSIZE;
+raw_s->aligned_buf = qemu_memalign(MAX_BLOCKSIZE,
+ raw_s->aligned_buf_size);
+
+if (raw_s->aligned_buf == NULL) {
+ret = -1;
+goto error;
+}
+}
+
+int fcntl_flags = O_APPEND | O_ASYNC | O_NONBLOCK;
+#ifdef O_NOATIME
+fcntl_flags |= O_NOATIME;
+#endif
+if ((raw_s->open_flags & ~fcntl_flags) == (s->open_flags & ~fcntl_flags)) {
+/* dup the original fd */
+/* TODO: use qemu fcntl wrapper */
+raw_s->fd = fcntl(s->fd, F_DUPFD_CLOEXEC, 0);
+if (raw_s->fd == -1) {
+ret = -1;
+goto error;
+}
+ret = fcntl_setfl(raw_s->fd, raw_s->open_flags);
+} else {
+raw_s->fd = qemu_open(state->bs->filename, raw_s->open_flags, 0644);
+if (raw_s->fd == -1) {
+ret = -1;
+}
+}
+error:
+return ret;
+}
+
+
+static void raw_reopen_commit(BDRVReopenState *state)
+{
+BDRVRawReopenState *raw_s = state->opaque;
+BDRVRawState *s = state->bs->opaque;
+
+if (raw_s->aligned_buf != NULL) {
+if (s->aligned_buf) {
+qemu_vfree(s->aligned_buf);
+}
+s->al
[Qemu-devel] [PATCH 4/7] block: raw image file reopen
These are the stubs for the file reopen drivers for the raw format.
There is currently nothing that needs to be done by the raw driver
in reopen.
Signed-off-by: Jeff Cody
---
block/raw.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/block/raw.c b/block/raw.c
index ff34ea4..fa47ff1 100644
--- a/block/raw.c
+++ b/block/raw.c
@@ -9,6 +9,24 @@ static int raw_open(BlockDriverState *bs, int flags)
return 0;
}
+/* We have nothing to do for raw reopen, stubs just return
+ * success */
+static int raw_reopen_prepare(BDRVReopenState *state, Error **errp)
+{
+return 0;
+}
+
+static void raw_reopen_commit(BDRVReopenState *state)
+{
+return;
+}
+
+static void raw_reopen_abort(BDRVReopenState *state)
+{
+return;
+}
+
+
static int coroutine_fn raw_co_readv(BlockDriverState *bs, int64_t sector_num,
int nb_sectors, QEMUIOVector *qiov)
{
@@ -115,6 +133,10 @@ static BlockDriver bdrv_raw = {
.bdrv_open = raw_open,
.bdrv_close = raw_close,
+.bdrv_reopen_prepare = raw_reopen_prepare,
+.bdrv_reopen_commit = raw_reopen_commit,
+.bdrv_reopen_abort= raw_reopen_abort,
+
.bdrv_co_readv = raw_co_readv,
.bdrv_co_writev = raw_co_writev,
.bdrv_co_is_allocated = raw_co_is_allocated,
--
1.7.11.2
Re: [Qemu-devel] CPU hotplug
Am 30.08.2012 20:56, schrieb Igor Mammedov: On Thu, 30 Aug 2012 20:45:10 +0200 Stefan Priebe wrote: Am 30.08.2012 20:40, schrieb Igor Mammedov: Am 30.08.2012 um 17:41 schrieb Andreas Färber : Am 30.08.2012 11:06, schrieb Stefan Priebe: I tried latest 1.2rc1 kvm-qemu with vanilla kernel v3.5.2 but the VM just crashes when sending cpu_set X online through qm monitor. For SLES we're carrying a patch by Kamalesh Babulal that prevents this (BNC#747339). But this just disables CPU [hotplug] and does Not fix it? It fixes the crash. Hotplug needs to be implemented first, and this has been taking several months already (for x86, to be specific). Mhm RHEL 6.3 claims to support this? it's not officially supported, it's just tech-preview. That allows to play with hotplug and uncover possible guest issues early. Yes, but does this mean that is doesn't work at RHEL too? i wasn't able to get it working any guest or host at all. It works with RHEL 6.3 host/guest combo. Extra testing is greatly appreciated. mhm OK. I'm using Debian Squeeze with qemu-kvm 1.2rc1 and vanilla kernel 3.5.2 as guest AND host. This just results in the known crash. Stefan
Re: [Qemu-devel] CPU hotplug
On Thu, 30 Aug 2012 20:45:10 +0200 Stefan Priebe wrote: > Am 30.08.2012 20:40, schrieb Igor Mammedov: > Am 30.08.2012 um 17:41 schrieb Andreas Färber : > > > Am 30.08.2012 11:06, schrieb Stefan Priebe: > >> I tried latest 1.2rc1 kvm-qemu with vanilla kernel v3.5.2 but the VM > >> just crashes when sending cpu_set X online through qm monitor. > > > > For SLES we're carrying a patch by Kamalesh Babulal that prevents this > > (BNC#747339). > > But this just disables CPU [hotplug] and does Not fix it? > >>> > >>> It fixes the crash. Hotplug needs to be implemented first, and this has > >>> been taking several months already (for x86, to be specific). > >> > >> Mhm RHEL 6.3 claims to support this? > > it's not officially supported, it's just tech-preview. That allows to play > > with > > hotplug and uncover possible guest issues early. > > Yes, but does this mean that is doesn't work at RHEL too? i wasn't able > to get it working any guest or host at all. It works with RHEL 6.3 host/guest combo. Extra testing is greatly appreciated. > Greets, > Stefan > -- Regards, Igor
[Qemu-devel] [RFC v2 PATCH 4/6] qerror: new error for live block commit, QERR_TOP_NOT_FOUND
Signed-off-by: Jeff Cody --- qerror.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/qerror.h b/qerror.h index d0a76a4..7396184 100644 --- a/qerror.h +++ b/qerror.h @@ -219,6 +219,9 @@ void assert_no_error(Error *err); #define QERR_TOO_MANY_FILES \ ERROR_CLASS_GENERIC_ERROR, "Too many open files" +#define QERR_TOP_NOT_FOUND \ +ERROR_CLASS_GENERIC_ERROR, "Top image file %s not found" + #define QERR_UNDEFINED_ERROR \ ERROR_CLASS_GENERIC_ERROR, "An undefined error has occurred" -- 1.7.11.2
Re: [Qemu-devel] [PATCH 2/6] monitor: Adjust qmp_human_monitor_command to new MemCharDriver
On Thu, 23 Aug 2012 13:14:22 +0800 Lei Li wrote: > Signed-off-by: Lei Li > --- > monitor.c |8 +++- > 1 files changed, 7 insertions(+), 1 deletions(-) > > diff --git a/monitor.c b/monitor.c > index 480f583..ab4650b 100644 > --- a/monitor.c > +++ b/monitor.c > @@ -642,7 +642,13 @@ char *qmp_human_monitor_command(const char > *command_line, bool has_cpu_index, > CharDriverState mchar; > > memset(&hmp, 0, sizeof(hmp)); > -qemu_chr_init_mem(&mchar); > + > +/* Since the backend of MemCharDriver convert to a circular > + * buffer with fixed size, so should indicate the init memory > + * size. > + * > + * XXX: is 4096 as init memory enough for this? */ > +qemu_chr_init_mem(&mchar, 4096); I'm not sure I like this. The end result will be that hmp commands writing more than 4096 bytes will simply fail or return garbage (if the circular buffer is changed to allow writing more than it supports) today they would just work. Although it's always possible to increase the buffer size, we would only realize this is needed when the bug is triggered, which means it has a high chance of happening in production. IOW, this would be a regression. The only solution I can think of is to make the circular buffer and the current MemoryDriver live in parallel. Actually, you really seem to be adding something else. > hmp.chr = &mchar; > > old_mon = cur_mon;
Re: [Qemu-devel] QEMU emulation per CPU
On Thu, Aug 30, 2012 at 7:27 PM, Naresh Bhat wrote: > Hi Santosa, > > Can you please forward a link of that discussion thread ?? try: http://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg05037.html -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
[Qemu-devel] [RFC v2 PATCH 6/6] QAPI: add command for live block commit, 'block-commit'
The command for live block commit is added, which has the following
arguments:
device: the block device to perform the commit on (mandatory)
base: the base image to commit into; optional (if not specified,
it is the underlying original image)
top:the top image of the commit - all data from inside top down
to base will be committed into base. optional (if not specified,
it is the active image) - see note below
speed: maximum speed, in bytes/sec
note: eventually this will support merging down the active layer,
but that code is not yet complete. If the active layer is passed
in currently as top, or top is left to the default, then the error
QERR_TOP_NOT_FOUND will be returned.
The is done as a block job, so upon completion a BLOCK_JOB_COMPLETED will
be emitted.
Signed-off-by: Jeff Cody
---
blockdev.c | 83
qapi-schema.json | 30
qmp-commands.hx | 6
3 files changed, 119 insertions(+)
diff --git a/blockdev.c b/blockdev.c
index 68d65fb..e0d6ca0 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -827,6 +827,89 @@ exit:
return;
}
+void qmp_block_commit(const char *device,
+ bool has_base, const char *base,
+ bool has_top, const char *top,
+ bool has_speed, int64_t speed,
+ Error **errp)
+{
+BlockDriverState *bs;
+BlockDriverState *base_bs, *top_bs, *child_bs;
+Error *local_err = NULL;
+int orig_base_flags, orig_top_flags;
+BlockReopenQueue *reopen_queue = NULL;
+/* This will be part of the QMP command, if/when the
+ * BlockdevOnError change for blkmirror makes it in
+ */
+BlockErrorAction on_error = BLOCK_ERR_REPORT;
+
+/* drain all i/o before commits */
+bdrv_drain_all();
+
+bs = bdrv_find(device);
+if (!bs) {
+error_set(errp, QERR_DEVICE_NOT_FOUND, device);
+return;
+}
+if (base && has_base) {
+base_bs = bdrv_find_backing_image(bs, base);
+} else {
+base_bs = bdrv_find_base(bs);
+}
+
+if (base_bs == NULL) {
+error_set(errp, QERR_BASE_NOT_FOUND, "NULL");
+return;
+}
+
+if (top && has_top) {
+/* if we want to allow the active layer,
+ * use 'bdrv_find_image()' here */
+top_bs = bdrv_find_backing_image(bs, top);
+if (top_bs == NULL) {
+error_set(errp, QERR_TOP_NOT_FOUND, top);
+return;
+}
+} else {
+/* we will eventually default to the top layer,i.e. top_bs = bs */
+error_set(errp, QERR_TOP_NOT_FOUND, top);
+return;
+}
+
+child_bs = bdrv_find_child(bs, top_bs);
+
+orig_base_flags = bdrv_get_flags(base_bs); /* what we are writing into
*/
+orig_top_flags = bdrv_get_flags(child_bs); /* to change the backing file
*/
+
+/* convert base_bs to r/w, if necessary */
+if (!(orig_base_flags & BDRV_O_RDWR)) {
+reopen_queue = bdrv_reopen_queue(reopen_queue, base_bs,
+ orig_base_flags | BDRV_O_RDWR);
+}
+if (!(orig_top_flags & BDRV_O_RDWR)) {
+reopen_queue = bdrv_reopen_queue(reopen_queue, base_bs,
+ orig_base_flags | BDRV_O_RDWR);
+}
+if (reopen_queue) {
+bdrv_reopen_multiple(reopen_queue, &local_err);
+if (local_err != NULL) {
+error_propagate(errp, local_err);
+return;
+}
+}
+
+commit_start(bs, base_bs, top_bs, speed, on_error,
+ block_job_cb, bs, orig_base_flags, orig_top_flags,
+ &local_err);
+if (local_err != NULL) {
+error_propagate(errp, local_err);
+return;
+}
+/* Grab a reference so hotplug does not delete the BlockDriverState from
+ * underneath us.
+ */
+drive_get_ref(drive_get_by_blockdev(bs));
+}
static void eject_device(BlockDriverState *bs, int force, Error **errp)
{
diff --git a/qapi-schema.json b/qapi-schema.json
index bd8ad74..45feda6 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1401,6 +1401,36 @@
'returns': 'str' }
##
+# @block-commit
+#
+# Live commit of data from child image nodes into parent nodes - i.e.,
+# writes data between 'top' and 'base' into 'base'.
+#
+# @device: the name of the device
+#
+# @base: #optional The parent image of the device to write data into.
+#If not specified, this is the original parent image.
+#
+# @top:#optional The child image, above which data will not be committed
+#down. If not specified, this is the active layer.
+#
+# @speed: #optional the maximum speed, in bytes per second
+#
+# Returns: Nothing on success
+# If commit or stream is already active on this device, DeviceInUse
+# If @device does not exist, DeviceNotFound
+# If image commit is not supported by this de
[Qemu-devel] [PATCH 0/7] block: bdrv_reopen() patches
These patches are strongly based off Supriya Kannery's original bdrv_reopen() patches as part of the hostcache series, including the _prepare(), _commit(), and _abort() structure. Some additions / changes: * Added support for multiple image reopen transactionally * Reopen changes are staged into temporary stashes in prepare(), and copied over in commit() (discarded in abort()). * Driver-level reopen file changes are mainly contained in the raw-* files. TODO: The raw-win32 driver still needs to be finished TODO: The vmdk driver still needs to be finished Jeff Cody (7): block: correctly set the keep_read_only flag block: Framework for reopening files safely block: raw-posix image file reopen block: raw image file reopen block: qed image file reopen block: qcow2 image file reopen block: qcow image file reopen block.c | 242 -- block.h | 16 block/qcow.c | 23 ++ block/qcow2.c | 22 + block/qed.c | 20 + block/raw-posix.c | 153 ++ block/raw.c | 22 + block_int.h | 13 +++ qemu-common.h | 1 + 9 files changed, 489 insertions(+), 23 deletions(-) -- 1.7.11.2
Re: [Qemu-devel] CPU hotplug
Am 30.08.2012 20:40, schrieb Igor Mammedov: Am 30.08.2012 um 17:41 schrieb Andreas Färber : Am 30.08.2012 11:06, schrieb Stefan Priebe: I tried latest 1.2rc1 kvm-qemu with vanilla kernel v3.5.2 but the VM just crashes when sending cpu_set X online through qm monitor. For SLES we're carrying a patch by Kamalesh Babulal that prevents this (BNC#747339). But this just disables CPU [hotplug] and does Not fix it? It fixes the crash. Hotplug needs to be implemented first, and this has been taking several months already (for x86, to be specific). Mhm RHEL 6.3 claims to support this? it's not officially supported, it's just tech-preview. That allows to play with hotplug and uncover possible guest issues early. Yes, but does this mean that is doesn't work at RHEL too? i wasn't able to get it working any guest or host at all. Greets, Stefan
Re: [Qemu-devel] [PATCH 1/6] qemu-char: Convert MemCharDriver to circular buffer
On Thu, 23 Aug 2012 13:14:21 +0800
Lei Li wrote:
> Signed-off-by: Lei Li
> ---
> qemu-char.c | 96 +++---
> qemu-char.h |2 +-
> 2 files changed, 78 insertions(+), 20 deletions(-)
>
> diff --git a/qemu-char.c b/qemu-char.c
> index 398baf1..b21b93a 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -2528,38 +2528,96 @@ static CharDriverState *qemu_chr_open_socket(QemuOpts
> *opts)
> /***/
> /* Memory chardev */
> typedef struct {
> -size_t outbuf_size;
> -size_t outbuf_capacity;
> -uint8_t *outbuf;
> +size_t cbuf_capacity;
> +size_t cbuf_in;
> +size_t cbuf_out;
> +size_t cbuf_count;
> +uint8_t *cbuf;
> } MemoryDriver;
>
> +static int mem_chr_is_empty(CharDriverState *chr)
> +{
> +MemoryDriver *d = chr->opaque;
> +
> +return d->cbuf_count == 0;
> +}
> +
> +static int mem_chr_is_full(CharDriverState *chr)
> +{
> +MemoryDriver *d = chr->opaque;
> +
> +return d->cbuf_count == d->cbuf_capacity;
> +}
Please, make them return a bool and chr can be const.
> +
> static int mem_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
> {
> MemoryDriver *d = chr->opaque;
> +int left;
>
> -/* TODO: the QString implementation has the same code, we should
> - * introduce a generic way to do this in cutils.c */
> -if (d->outbuf_capacity < d->outbuf_size + len) {
> -/* grow outbuf */
> -d->outbuf_capacity += len;
> -d->outbuf_capacity *= 2;
> -d->outbuf = g_realloc(d->outbuf, d->outbuf_capacity);
> +if (d->cbuf_capacity < len) {
> +return -1;
> }
This is the first time I look at a circular buffer implementation, but
I'd expect this too work: ie. you just write the last bytes that fit on
the buffer.
>
> -memcpy(d->outbuf + d->outbuf_size, buf, len);
> -d->outbuf_size += len;
> +left = d->cbuf_capacity - d->cbuf_count % d->cbuf_capacity;
> +
> +/* Some of cbuf need to be overwrited */
> +if (left < len) {
> +memcpy(d->cbuf + d->cbuf_in, buf, left);
> +memcpy(d->cbuf + d->cbuf_out, buf + left, len - left);
> +d->cbuf_out = (d->cbuf_out + len - left) % d->cbuf_capacity;
> +d->cbuf_count = d->cbuf_count + left;
> +} else {
> +/* Completely overwrite */
> +if (mem_chr_is_full(chr)) {
> +d->cbuf_out = (d->cbuf_out + len) % d->cbuf_capacity;
> +} else {
> +/* Enough cbuf to write */
> +d->cbuf_count += len;
> +}
> +memcpy(d->cbuf + d->cbuf_in, buf, len);
> +}
Couldn't this be made simpler by having a pointer to d->cbuf that points
to where we are, then we just made that pointer points to the beginning
of the buffer every time we cross its end? Just an idea.
> +
> +d->cbuf_in = (d->cbuf_in + len) % d->cbuf_capacity;
>
> return len;
> }
>
> -void qemu_chr_init_mem(CharDriverState *chr)
> +static void mem_chr_read(CharDriverState *chr, uint8_t *buf, int len)
> +{
> +MemoryDriver *d = chr->opaque;
> +int left;
> +
> +if (mem_chr_is_empty(chr)) {
> +return;
> +}
> +
> +left = d->cbuf_capacity - d->cbuf_count % d->cbuf_capacity;
> +
> +if (d->cbuf_capacity < len) {
> +len = d->cbuf_capacity;
> +}
> +
> +if (left < len) {
> +memcpy(buf, d->cbuf + d->cbuf_out, left);
> +memcpy(buf + left, d->cbuf + d->cbuf_out + left, len - left);
> +} else {
> +memcpy(buf, d->cbuf + d->cbuf_out, len);
> +}
> +
> +d->cbuf_out = (d->cbuf_out + len) % d->cbuf_capacity;
> +d->cbuf_count -= len;
> +}
> +
> +void qemu_chr_init_mem(CharDriverState *chr, size_t size)
Won't this break bisect?
> {
> MemoryDriver *d;
>
> d = g_malloc(sizeof(*d));
> -d->outbuf_size = 0;
> -d->outbuf_capacity = 4096;
> -d->outbuf = g_malloc0(d->outbuf_capacity);
> +d->cbuf_capacity = size;
> +d->cbuf_in = 0;
> +d->cbuf_out = 0;
> +d->cbuf_count = 0;
> +d->cbuf = g_malloc0(d->cbuf_capacity);
>
> memset(chr, 0, sizeof(*chr));
> chr->opaque = d;
> @@ -2569,7 +2627,7 @@ void qemu_chr_init_mem(CharDriverState *chr)
> QString *qemu_chr_mem_to_qs(CharDriverState *chr)
> {
> MemoryDriver *d = chr->opaque;
> -return qstring_from_substr((char *) d->outbuf, 0, d->outbuf_size - 1);
> +return qstring_from_substr((char *) d->cbuf, 0, d->cbuf_count - 1);
> }
>
> /* NOTE: this driver can not be closed with qemu_chr_delete()! */
> @@ -2577,7 +2635,7 @@ void qemu_chr_close_mem(CharDriverState *chr)
> {
> MemoryDriver *d = chr->opaque;
>
> -g_free(d->outbuf);
> +g_free(d->cbuf);
> g_free(chr->opaque);
> chr->opaque = NULL;
> chr->chr_write = NULL;
> @@ -2586,7 +2644,7 @@ void qemu_chr_close_mem(CharDriverState *chr)
> size_t qemu_chr_mem_osize(const CharDriverState *chr)
> {
> const MemoryDriver *d = chr->o
Re: [Qemu-devel] CPU hotplug
On Thu, 30 Aug 2012 19:23:14 +0200 Stefan Priebe wrote: > Am 30.08.2012 18:43, schrieb Andreas Färber: > > Am 30.08.2012 18:35, schrieb Stefan Priebe: > >> Am 30.08.2012 um 17:41 schrieb Andreas Färber : > >> > >>> Am 30.08.2012 11:06, schrieb Stefan Priebe: > I tried latest 1.2rc1 kvm-qemu with vanilla kernel v3.5.2 but the VM > just crashes when sending cpu_set X online through qm monitor. > >>> > >>> For SLES we're carrying a patch by Kamalesh Babulal that prevents this > >>> (BNC#747339). > >> > >> But this just disables CPU [hotplug] and does Not fix it? > > > > It fixes the crash. Hotplug needs to be implemented first, and this has > > been taking several months already (for x86, to be specific). > > Mhm RHEL 6.3 claims to support this? it's not officially supported, it's just tech-preview. That allows to play with hotplug and uncover possible guest issues early. > Dynamic virtual CPU allocation > => > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.3_Release_Notes/virtualization.html > > > > Greets, > Stefan -- Regards, Igor
[Qemu-devel] [PATCH 1/2] pcie: drop version_id field for live migration
While testing q35 live migration, I found that the migration would abort with
the following error: "Unknown savevm section type 76".
The error is due to this check failing in 'vmstate_load_state()':
while(field->name) {
if ((field->field_exists &&
field->field_exists(opaque, version_id)) ||
(!field->field_exists &&
field->version_id <= version_id)) {
The VMSTATE_PCIE_DEVICE() currently has a 'version_id' set to 2. However,
'version_id' in the above check is 1. And thus we fail to load the pcie device
field. Further the code returns to 'qemu_loadvm_state()' which produces the
error that I saw.
I'm proposing to fix this by simply dropping the 'version_id' field from
VMSTATE_PCIE_DEVICE(). VMSTATE_PCI_DEVICE() defines no such field and further
the vmstate_pcie_device that VMSTATE_PCI_DEVICE() refers to is already
versioned. Thus, any versioning issues could be detected at the vmsd level.
Taking a step back, I think that the 'field->version_id' should be compared
against a saved version number for the field not the 'version_id'. Futhermore,
once vmstate_load_state() is called recursively on another vmsd, the check of:
if (version_id > vmsd->version_id) {
return -EINVAL;
}
Will never fail since version_id is always equal to vmsd->version_id. So I'm
wondering why we aren't storing the vmsd version id of the source in the
migration stream?
This patch also renames the 'name' field of vmstate_pcie_device from:
PCIDevice -> PCIEDevice to differentiate it from vmstate_pci_device.
Signed-off-by: Jason Baron
---
hw/pci.c |2 +-
hw/pcie.h |1 -
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 3727afa..5386a4f 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -439,7 +439,7 @@ const VMStateDescription vmstate_pci_device = {
};
const VMStateDescription vmstate_pcie_device = {
-.name = "PCIDevice",
+.name = "PCIEDevice",
.version_id = 2,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
diff --git a/hw/pcie.h b/hw/pcie.h
index b8ab0c7..4889194 100644
--- a/hw/pcie.h
+++ b/hw/pcie.h
@@ -133,7 +133,6 @@ extern const VMStateDescription vmstate_pcie_device;
#define VMSTATE_PCIE_DEVICE(_field, _state) {\
.name = (stringify(_field)), \
-.version_id = 2, \
.size = sizeof(PCIDevice), \
.vmsd = &vmstate_pcie_device, \
.flags = VMS_STRUCT,\
--
1.7.1
[Qemu-devel] [PATCH 2/2] pcie_aer: clear cmask for Advanced Error Interrupt Message Number
The Advanced Error Interrupt Message Number (bits 31:27 of the Root Error Status Register) is updated when the number of msi messages assigned to a device changes. Migration of windows 7 on q35 chipset failed because the check in get_pci_config_device() fails due to wmask being set on these bits. Its valid to update these bits and we must restore this state across migration. Signed-off-by: Jason Baron --- hw/pcie_aer.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/hw/pcie_aer.c b/hw/pcie_aer.c index 3b6981c..6edcd79 100644 --- a/hw/pcie_aer.c +++ b/hw/pcie_aer.c @@ -738,6 +738,12 @@ void pcie_aer_root_init(PCIDevice *dev) PCI_ERR_ROOT_CMD_EN_MASK); pci_set_long(dev->w1cmask + pos + PCI_ERR_ROOT_STATUS, PCI_ERR_ROOT_STATUS_REPORT_MASK); +/* Bits 31:27 - Advanced Error Interrupt Message Number + * These bits are updated when the number of MSI messages changes. + * By clearing the cmask, pcie devices can be migrated. + */ +pci_set_long(dev->cmask + pos + PCI_ERR_ROOT_STATUS, + (1 << PCI_ERR_ROOT_IRQ_SHIFT) - 1); } void pcie_aer_root_reset(PCIDevice *dev) -- 1.7.1
[Qemu-devel] [PATCH 0/2] pcie migration fixes
Hi, A couple of pcie related migration fixes that I found while testing q35 migration. Thanks, -Jason Jason Baron (2): pcie: drop version_id field for live migration pcie_aer: clear cmask for Advanced Error Interrupt Message Number hw/pci.c |2 +- hw/pcie.h |1 - hw/pcie_aer.c |6 ++ 3 files changed, 7 insertions(+), 2 deletions(-)
Re: [Qemu-devel] [PATCH v7 5/6] add the QKeyCode enum and the key_defs table
On Mon, 20 Aug 2012 12:39:28 +0800
Amos Kong wrote:
> key_defs[] in monitor.c is a mapping table of keys and keycodes,
> this patch added a QKeyCode enum and a new key_defs table,
> key's index in the enmu is same as keycode's index in new key_defs[].
>
> And added two help functions to convert key/code to index of mapping
> table, those functions will return Q_KEY_CODE_MAX if the code/key is
> invalid.
>
> 'key_defs' was dropped from the monitor, monitor functions were
> changed to access key_defs directly.
>
> Signed-off-by: Amos Kong
This patch (and probably the next one too) doesn't apply on master, could
you rebase please?
As you'll have to respin, please change versions to 1.3.0. I also have
comments below (minor, but as you'll respin anyway).
> ---
> console.h|6 ++
> input.c | 186
> ++
> monitor.c| 183 +++-
> qapi-schema.json | 26
> 4 files changed, 229 insertions(+), 172 deletions(-)
>
> diff --git a/console.h b/console.h
> index 4334db5..7934b11 100644
> --- a/console.h
> +++ b/console.h
> @@ -6,6 +6,7 @@
> #include "notify.h"
> #include "monitor.h"
> #include "trace.h"
> +#include "qapi-types.h"
>
> /* keyboard/mouse support */
>
> @@ -397,4 +398,9 @@ static inline int vnc_display_pw_expire(DisplayState *ds,
> time_t expires)
> /* curses.c */
> void curses_display_init(DisplayState *ds, int full_screen);
>
> +/* input.c */
> +extern const int key_defs[];
Why are you exporting key_defs[]? It should be static.
Also, it would be better to move the addition of QKeyCode out of this patch
(ie. you first add it and then move the table).
> +int index_from_key(const char *key);
> +int index_from_keycode(int code);
> +
> #endif
> diff --git a/input.c b/input.c
> index 6968b31..5630cb1 100644
> --- a/input.c
> +++ b/input.c
> @@ -37,6 +37,192 @@ static QTAILQ_HEAD(, QEMUPutMouseEntry) mouse_handlers =
> static NotifierList mouse_mode_notifiers =
> NOTIFIER_LIST_INITIALIZER(mouse_mode_notifiers);
>
> +const int key_defs[] = {
> +[Q_KEY_CODE_SHIFT] = 0x2a,
> +[Q_KEY_CODE_SHIFT_R] = 0x36,
> +
> +[Q_KEY_CODE_ALT] = 0x38,
> +[Q_KEY_CODE_ALT_R] = 0xb8,
> +[Q_KEY_CODE_ALTGR] = 0x64,
> +[Q_KEY_CODE_ALTGR_R] = 0xe4,
> +[Q_KEY_CODE_CTRL] = 0x1d,
> +[Q_KEY_CODE_CTRL_R] = 0x9d,
> +
> +[Q_KEY_CODE_MENU] = 0xdd,
> +
> +[Q_KEY_CODE_ESC] = 0x01,
> +
> +[Q_KEY_CODE_1] = 0x02,
> +[Q_KEY_CODE_2] = 0x03,
> +[Q_KEY_CODE_3] = 0x04,
> +[Q_KEY_CODE_4] = 0x05,
> +[Q_KEY_CODE_5] = 0x06,
> +[Q_KEY_CODE_6] = 0x07,
> +[Q_KEY_CODE_7] = 0x08,
> +[Q_KEY_CODE_8] = 0x09,
> +[Q_KEY_CODE_9] = 0x0a,
> +[Q_KEY_CODE_0] = 0x0b,
> +[Q_KEY_CODE_MINUS] = 0x0c,
> +[Q_KEY_CODE_EQUAL] = 0x0d,
> +[Q_KEY_CODE_BACKSPACE] = 0x0e,
> +
> +[Q_KEY_CODE_TAB] = 0x0f,
> +[Q_KEY_CODE_Q] = 0x10,
> +[Q_KEY_CODE_W] = 0x11,
> +[Q_KEY_CODE_E] = 0x12,
> +[Q_KEY_CODE_R] = 0x13,
> +[Q_KEY_CODE_T] = 0x14,
> +[Q_KEY_CODE_Y] = 0x15,
> +[Q_KEY_CODE_U] = 0x16,
> +[Q_KEY_CODE_I] = 0x17,
> +[Q_KEY_CODE_O] = 0x18,
> +[Q_KEY_CODE_P] = 0x19,
> +[Q_KEY_CODE_BRACKET_LEFT] = 0x1a,
> +[Q_KEY_CODE_BRACKET_RIGHT] = 0x1b,
> +[Q_KEY_CODE_RET] = 0x1c,
> +
> +[Q_KEY_CODE_A] = 0x1e,
> +[Q_KEY_CODE_S] = 0x1f,
> +[Q_KEY_CODE_D] = 0x20,
> +[Q_KEY_CODE_F] = 0x21,
> +[Q_KEY_CODE_G] = 0x22,
> +[Q_KEY_CODE_H] = 0x23,
> +[Q_KEY_CODE_J] = 0x24,
> +[Q_KEY_CODE_K] = 0x25,
> +[Q_KEY_CODE_L] = 0x26,
> +[Q_KEY_CODE_SEMICOLON] = 0x27,
> +[Q_KEY_CODE_APOSTROPHE] = 0x28,
> +[Q_KEY_CODE_GRAVE_ACCENT] = 0x29,
> +
> +[Q_KEY_CODE_BACKSLASH] = 0x2b,
> +[Q_KEY_CODE_Z] = 0x2c,
> +[Q_KEY_CODE_X] = 0x2d,
> +[Q_KEY_CODE_C] = 0x2e,
> +[Q_KEY_CODE_V] = 0x2f,
> +[Q_KEY_CODE_B] = 0x30,
> +[Q_KEY_CODE_N] = 0x31,
> +[Q_KEY_CODE_M] = 0x32,
> +[Q_KEY_CODE_COMMA] = 0x33,
> +[Q_KEY_CODE_DOT] = 0x34,
> +[Q_KEY_CODE_SLASH] = 0x35,
> +
> +[Q_KEY_CODE_ASTERISK] = 0x37,
> +
> +[Q_KEY_CODE_SPC] = 0x39,
> +[Q_KEY_CODE_CAPS_LOCK] = 0x3a,
> +[Q_KEY_CODE_F1] = 0x3b,
> +[Q_KEY_CODE_F2] = 0x3c,
> +[Q_KEY_CODE_F3] = 0x3d,
> +[Q_KEY_CODE_F4] = 0x3e,
> +[Q_KEY_CODE_F5] = 0x3f,
> +[Q_KEY_CODE_F6] = 0x40,
> +[Q_KEY_CODE_F7] = 0x41,
> +[Q_KEY_CODE_F8] = 0x42,
> +[Q_KEY_CODE_F9] = 0x43,
> +[Q_KEY_CODE_F10] = 0x44,
> +[Q_KEY_CODE_NUM_LOCK] = 0x45,
> +[Q_KEY_CODE_SCROLL_LOCK] = 0x46,
> +
> +[Q_KEY_CODE_KP_DIVIDE] = 0xb5,
> +[Q_KEY_CODE_KP_MULTIPLY] = 0x37,
> +[Q_KEY_CODE_KP_SUBTRACT] = 0x4a,
> +[Q_KEY_CODE_KP_ADD] = 0x4e,
> +[Q_KEY_CODE_KP_ENTER] = 0x9c,
> +[Q_KEY_CODE_KP_DECIMAL] = 0x53,
> +[Q_KEY_CODE_SYSRQ] = 0x54,
> +
> +[Q_KEY_CODE_KP_0] = 0x52,
> +[Q_KEY_CODE_KP_1] = 0x4f,
> +[Q_KEY_CODE_KP_2] = 0x50,
> +[Q_KEY_CODE_KP_3] = 0
Re: [Qemu-devel] CPU hotplug
Am 30.08.2012 18:43, schrieb Andreas Färber: Am 30.08.2012 18:35, schrieb Stefan Priebe: Am 30.08.2012 um 17:41 schrieb Andreas Färber : Am 30.08.2012 11:06, schrieb Stefan Priebe: I tried latest 1.2rc1 kvm-qemu with vanilla kernel v3.5.2 but the VM just crashes when sending cpu_set X online through qm monitor. For SLES we're carrying a patch by Kamalesh Babulal that prevents this (BNC#747339). But this just disables CPU [hotplug] and does Not fix it? It fixes the crash. Hotplug needs to be implemented first, and this has been taking several months already (for x86, to be specific). Mhm RHEL 6.3 claims to support this? Dynamic virtual CPU allocation => https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.3_Release_Notes/virtualization.html Greets, Stefan
Re: [Qemu-devel] [PATCH 00/18] qapi: Convert savevm, loadvm, delvm and info snapshots
On Wed, 15 Aug 2012 09:41:41 +0200 Pavel Hrdina wrote: > This patch series convert these commands into qapi and intruduce QMP commands > vm-snapshot-save, vm-snapshot-load, vm-snapshot-delete and query-vm-snapshots. > It also rewrite error report for function used by these commands. Unfortunately, most of the error conversions are wrong. I've commented on them, but the most important thing here is to decide how we should propagate the Error object in the block layer and what to do with its errno usage. It's better to discuss this first before doing large changes. It might also be worth it to split this series and work on error propagation first. I've CC'ed the block layer guys in one of my reviews to this series.
Re: [Qemu-devel] [PATCH 12/18] savevm: add error parameter to qemu_loadvm_state()
On Wed, 15 Aug 2012 09:41:53 +0200
Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina
> ---
> migration.c | 2 +-
> savevm.c| 44
> sysemu.h| 3 ++-
> 3 files changed, 31 insertions(+), 18 deletions(-)
>
> diff --git a/migration.c b/migration.c
> index ec2f267..f048faf 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -88,7 +88,7 @@ int qemu_start_incoming_migration(const char *uri, Error
> **errp)
>
> void process_incoming_migration(QEMUFile *f)
> {
> -if (qemu_loadvm_state(f) < 0) {
> +if (qemu_loadvm_state(f, NULL) < 0) {
> fprintf(stderr, "load of migration failed\n");
> exit(0);
> }
> diff --git a/savevm.c b/savevm.c
> index 0d54115..500eb72 100644
> --- a/savevm.c
> +++ b/savevm.c
> @@ -1916,7 +1916,8 @@ typedef struct LoadStateEntry {
> int version_id;
> } LoadStateEntry;
>
> -int qemu_loadvm_state(QEMUFile *f)
> +int qemu_loadvm_state(QEMUFile *f,
> + Error **errp)
> {
> QLIST_HEAD(, LoadStateEntry) loadvm_handlers =
> QLIST_HEAD_INITIALIZER(loadvm_handlers);
> @@ -1925,21 +1926,26 @@ int qemu_loadvm_state(QEMUFile *f)
> unsigned int v;
> int ret;
>
> -if (qemu_savevm_state_blocked(NULL)) {
> -return -EINVAL;
> +if (qemu_savevm_state_blocked(errp)) {
> +return -ENOTSUP;
> }
>
> v = qemu_get_be32(f);
> -if (v != QEMU_VM_FILE_MAGIC)
> +if (v != QEMU_VM_FILE_MAGIC) {
> +error_set(errp, ERROR_CLASS_GENERIC_ERROR,
> + "Unknown vm-state file magic");
> return -EINVAL;
> +}
>
> v = qemu_get_be32(f);
> if (v == QEMU_VM_FILE_VERSION_COMPAT) {
> -fprintf(stderr, "SaveVM v2 format is obsolete and don't work
> anymore\n");
> +error_set(errp, QERR_NOT_SUPPORTED);
> return -ENOTSUP;
> }
> -if (v != QEMU_VM_FILE_VERSION)
> +if (v != QEMU_VM_FILE_VERSION) {
> +error_set(errp, QERR_NOT_SUPPORTED);
> return -ENOTSUP;
> +}
>
> while ((section_type = qemu_get_byte(f)) != QEMU_VM_EOF) {
> uint32_t instance_id, version_id, section_id;
> @@ -1961,15 +1967,18 @@ int qemu_loadvm_state(QEMUFile *f)
> /* Find savevm section */
> se = find_se(idstr, instance_id);
> if (se == NULL) {
> -fprintf(stderr, "Unknown savevm section or instance '%s'
> %d\n", idstr, instance_id);
> +error_set(errp, ERROR_CLASS_GENERIC_ERROR,
> + "Unknown savevm section or instance '%s' %d",
> + idstr, instance_id);
> ret = -EINVAL;
> goto out;
> }
>
> /* Validate version */
> if (version_id > se->version_id) {
> -fprintf(stderr, "savevm: unsupported version %d for '%s'
> v%d\n",
> -version_id, idstr, se->version_id);
> +error_set(errp, ERROR_CLASS_GENERIC_ERROR,
> + "savevm: unsupported version %d for '%s' v%d",
> + version_id, idstr, se->version_id);
> ret = -EINVAL;
> goto out;
> }
> @@ -1984,8 +1993,7 @@ int qemu_loadvm_state(QEMUFile *f)
>
> ret = vmstate_load(f, le->se, le->version_id);
> if (ret < 0) {
> -fprintf(stderr, "qemu: warning: error while loading state
> for instance 0x%x of device '%s'\n",
> -instance_id, idstr);
> +error_set(errp, QERR_GENERIC_ERROR, ret);
> goto out;
> }
> break;
> @@ -1999,20 +2007,21 @@ int qemu_loadvm_state(QEMUFile *f)
> }
> }
> if (le == NULL) {
> -fprintf(stderr, "Unknown savevm section %d\n", section_id);
> +error_set(errp, ERROR_CLASS_GENERIC_ERROR,
> + "Unknown savevm section %d", section_id);
You sure that this error message will be printed to the terminal? This has
to be done by the caller.
> ret = -EINVAL;
> goto out;
> }
>
> ret = vmstate_load(f, le->se, le->version_id);
> if (ret < 0) {
> -fprintf(stderr, "qemu: warning: error while loading state
> section id %d\n",
> -section_id);
> +error_set(errp, QERR_GENERIC_ERROR, ret);
> goto out;
> }
> break;
> default:
> -fprintf(stderr, "Unknown savevm section type %d\n",
> section_type);
> +error_set(errp, ERROR_CLASS_GENERIC_ERROR,
> + "Unknown savevm section type %d", section_type);
> ret = -EINVAL;
> goto out;
> }
> @@ -2030,6 +2039,9 @@ out:
>
> if (ret == 0) {
> ret = qemu_file_get_error(f);
[Qemu-devel] [PATCH] qxl: dont update invalid area
From: Dunrong Huang
This patch fixes the following error:
$ ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 -spice
port=5900,disable-ticketing -vga qxl -cdrom
~/Images/linuxmint-13-mate-dvd-32bit.iso
(/home/mathslinux/usr/bin/qemu-system-x86_64:10068): SpiceWorker-CRITICAL **:
red_worker.c:4599:red_update_area: condition `area->left >= 0 && area->top >= 0
&& area->left < area->right && area->top < area->bottom' failed
Aborted
spice server terminates QEMU process if we pass invalid area to it,
so dont update those invalid areas.
Signed-off-by: Dunrong Huang
---
hw/qxl.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index c2dd3b4..10e6bb3 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1385,6 +1385,13 @@ async_common:
QXLCookie *cookie = NULL;
QXLRect update = d->ram->update_area;
+if (update.left < 0 || update.top < 0 || update.left >= update.right ||
+update.top >= update.bottom) {
+qxl_set_guest_bug(d, "QXL_IO_UPDATE_AREA: "
+ "invalid area(%d,%d,%d,%d)\n", update.left,
+ update.right, update.top, update.bottom);
+break;
+}
if (async == QXL_ASYNC) {
cookie = qxl_cookie_new(QXL_COOKIE_TYPE_IO,
QXL_IO_UPDATE_AREA_ASYNC);
--
1.7.8.6
Re: [Qemu-devel] Posix timer syscalls ; dealing with the timer_t type
Hi, Am 30.08.2012 14:30, schrieb Erik de Castro Lopo: > I'm working on implementing Posix timers in linux-user. > > I'm having trouble figuring out how to handle the timer_t type. > Consider the following code with say 32 bit ARM being emulated > on 64 bit x86-64: > > timer_t timerid; > > err = timer_create(clockid, &sev, &timerid); > err = timer_gettime(timerid, &curr); > > The issue is that memory for the timer_t value in the 32 bit > target is alloacted on the tack (where the timer_t is 4 bytes) > but the value provided by the 64 bit host where the timer_t is > 8 bytes. > > Any suggestions on dealing with this? typedef target_ulong target_timer_t; or abi_ulong, or without the u if signed. Depending on where/how you use this, you may need to convert back and forth between host and target values. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] CPU hotplug
Am 30.08.2012 18:35, schrieb Stefan Priebe: > Am 30.08.2012 um 17:41 schrieb Andreas Färber : > >> Am 30.08.2012 11:06, schrieb Stefan Priebe: >>> I tried latest 1.2rc1 kvm-qemu with vanilla kernel v3.5.2 but the VM >>> just crashes when sending cpu_set X online through qm monitor. >> >> For SLES we're carrying a patch by Kamalesh Babulal that prevents this >> (BNC#747339). > > But this just disables CPU [hotplug] and does Not fix it? It fixes the crash. Hotplug needs to be implemented first, and this has been taking several months already (for x86, to be specific). 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] CPU hotplug
Am 30.08.2012 um 17:41 schrieb Andreas Färber : > Hello, > > Am 30.08.2012 11:06, schrieb Stefan Priebe: >> I tried latest 1.2rc1 kvm-qemu with vanilla kernel v3.5.2 but the VM >> just crashes when sending cpu_set X online through qm monitor. > > For SLES we're carrying a patch by Kamalesh Babulal that prevents this > (BNC#747339). > > Don't know why that patch is not in upstream - Bo Yang? But this just disables CPU Hotelzug and does Not fix it? Stefan
Re: [Qemu-devel] Is is possible to virtualise or share the TPM?
On 08/30/2012 11:40 AM, Jordi Cucurull Juan wrote: Do you refer to the patches that add TPM support to the SeaBIOS? Sorry for the confusion. What I meant is that the patches adding support for a private vTPM for each QEMU VM are 'behind' those adding support for the passthrough device model. There are SeaBIOS patches as well adding support for TPM, but those are different. If this is the case, this is just a completely virtual TPM without any link with the TPM of the physical machine, right? The SeaBIOS patches don't do that. They just add TPM BIOS support for TPM initialization, ACPI tables etc. To add a completely virtual TPM to QEMU a completely different device model is necessary than the one I have recently posted. Stefan Jordi. On 08/30/2012 04:50 PM, Stefan Berger wrote: On 08/30/2012 10:21 AM, Jordi Cucurull Juan wrote: Dear Stefan, What does it mean that the patches with the VTPM functionality exist but they are behind the regular ones? Does it mean that they are not currently updated? That they have less priority? It means that in my patch queue they are 'behind' the ones I posted over the last few months. Stefan Best regards, Jordi. On 08/29/2012 02:57 PM, Stefan Berger wrote: On 08/23/2012 04:05 PM, Corey Bryant wrote: On 08/21/2012 06:31 AM, Jordi Cucurull Juan wrote: Dear all, After applying the TPM patches to QEMU, I was wondering if it is possible to simultaneously use the TPM in more than one virtual machine, i.e. virtualisation of the TPM. According to the paper "Stefan Berger, Ramón Cáceres, Kenneth A. Goldman, Ronald Perez, Reiner Sailer, Leendert van Doorn. vTPM: Virtualizing the Trusted Platform Module" this seems to be possible in Xen. Is not possible in QEMU? Thanks! Jordi. I don't think the pass-through driver supports use by multiple VMs. Stefan Berger should be able to answer better so I'm adding him to the thread. The pass-through driver cannot provide access for multiple VMs to the single hardware TPM on the host. The usage model and the statefulness of the TPM (SRK password, owner password, keys) basically prevent/complicate this. The implementation for Xen was indep. of the Qemu code base today and there we used a software implementation of the TPM that provided a private TPm instance to each VM. I have patches for this for Qemu but due to an IRC chat in Sept. 2011 they are 'behind' the pass-through driver patches. Stefan
Re: [Qemu-devel] Is is possible to virtualise or share the TPM?
On 08/30/2012 11:40 AM, Jordi Cucurull Juan wrote: Do you refer to the patches that add TPM support to the SeaBIOS? Sorry for the confusion. What I meant is that the patches adding support for a private vTPM for each QEMU VM are 'behind' those adding support for the passthrough device model. There are SeaBIOS patches as well adding support for TPM, but those are different. If this is the case, this is just a completely virtual TPM without any link with the TPM of the physical machine, right? The SeaBIOS patches don't do that. They just add TPM BIOS support for TPM initialization, ACPI tables etc. To add a completely virtual TPM to QEMU a completely different device model is necessary than the one I have recently posted. Stefan Jordi. On 08/30/2012 04:50 PM, Stefan Berger wrote: On 08/30/2012 10:21 AM, Jordi Cucurull Juan wrote: Dear Stefan, What does it mean that the patches with the VTPM functionality exist but they are behind the regular ones? Does it mean that they are not currently updated? That they have less priority? It means that in my patch queue they are 'behind' the ones I posted over the last few months. Stefan Best regards, Jordi. On 08/29/2012 02:57 PM, Stefan Berger wrote: On 08/23/2012 04:05 PM, Corey Bryant wrote: On 08/21/2012 06:31 AM, Jordi Cucurull Juan wrote: Dear all, After applying the TPM patches to QEMU, I was wondering if it is possible to simultaneously use the TPM in more than one virtual machine, i.e. virtualisation of the TPM. According to the paper "Stefan Berger, Ramón Cáceres, Kenneth A. Goldman, Ronald Perez, Reiner Sailer, Leendert van Doorn. vTPM: Virtualizing the Trusted Platform Module" this seems to be possible in Xen. Is not possible in QEMU? Thanks! Jordi. I don't think the pass-through driver supports use by multiple VMs. Stefan Berger should be able to answer better so I'm adding him to the thread. The pass-through driver cannot provide access for multiple VMs to the single hardware TPM on the host. The usage model and the statefulness of the TPM (SRK password, owner password, keys) basically prevent/complicate this. The implementation for Xen was indep. of the Qemu code base today and there we used a software implementation of the TPM that provided a private TPm instance to each VM. I have patches for this for Qemu but due to an IRC chat in Sept. 2011 they are 'behind' the pass-through driver patches. Stefan
Re: [Qemu-devel] CPU hotplug
30.08.2012 19:41, Andreas Färber wrote: > Hello, > > Am 30.08.2012 11:06, schrieb Stefan Priebe: >> I tried latest 1.2rc1 kvm-qemu with vanilla kernel v3.5.2 but the VM >> just crashes when sending cpu_set X online through qm monitor. > > For SLES we're carrying a patch by Kamalesh Babulal that prevents this > (BNC#747339). The same is for debian/ubuntu: http://bugs.debian.org/680551 /mjt
Re: [Qemu-devel] [Spice-devel] [PATCH] Add new client_present and client capabilities fields to QXLRom
Gerd Hoffmann writes: >> The scheme I had in mind was this: >> >> - When a new non-a8-capable client appears, don't send it any of the >> a8 surfaces >> >> - If the client doesn't understand a8 surfaces, >> >> - keep all a8 surfaces rendered on the server side >> >> - if the guest sends a command using an a8 surface as a >> destination, simply render the command on the server side >> >> - if the client sends a command using an a8 surface as a source, >> rewrite the image object to be a real image referring to the >> server side bits (which are also sent or possibly cached) >> rather than a surface > > Hmm, when the server is able to translate a8 ops into non-a8 ops using > server-side rendering, then there is no need to notify the guest about > the client capabilities. To be clear, this ability doesn't exist at the moment, and it would be a significant chunk of work to add it. >> But it's much simpler to just say that the guest should stop referring >> to a8 surfaces if the client can't handle them. > > Not sure about that, this move might just shift the complexity from > spice-server to the guest qxl driver. The ability to handle this is already pretty much present in at least the X driver (and I'm pretty sure the Windows driver has it as well) because any time something can't be expressed in the SPICE protocol, it has to fall back to software rendering. Ie., it has to read all the involved surfaces back from video memory, do software rendering, then upload the result as an image. Dealing with a disappearing ability to handle a8 surfaces would simply be a matter of reading back the a8 surfaces to guest RAM and then not attempt to acccelerate any operations involving them any more. It looks much more involved to do it in spice-server because it would probably involve adding a new concept of "emulated surface" that needs to be handled specially in a bunch of cases. Søren
Re: [Qemu-devel] [PATCH] sheepdog: fix savevm and loadvm
Am 29.08.2012 20:39, schrieb MORITA Kazutaka: > This patch sets data to be sent to Sheepdog correctly and fixes savevm > and loadvm operations on a Sheepdog image. > > Signed-off-by: MORITA Kazutaka Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] CPU hotplug
Hello, Am 30.08.2012 11:06, schrieb Stefan Priebe: > I tried latest 1.2rc1 kvm-qemu with vanilla kernel v3.5.2 but the VM > just crashes when sending cpu_set X online through qm monitor. For SLES we're carrying a patch by Kamalesh Babulal that prevents this (BNC#747339). Don't know why that patch is not in upstream - Bo Yang? Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] Is is possible to virtualise or share the TPM?
Do you refer to the patches that add TPM support to the SeaBIOS? If this is the case, this is just a completely virtual TPM without any link with the TPM of the physical machine, right? Jordi. On 08/30/2012 04:50 PM, Stefan Berger wrote: On 08/30/2012 10:21 AM, Jordi Cucurull Juan wrote: Dear Stefan, What does it mean that the patches with the VTPM functionality exist but they are behind the regular ones? Does it mean that they are not currently updated? That they have less priority? It means that in my patch queue they are 'behind' the ones I posted over the last few months. Stefan Best regards, Jordi. On 08/29/2012 02:57 PM, Stefan Berger wrote: On 08/23/2012 04:05 PM, Corey Bryant wrote: On 08/21/2012 06:31 AM, Jordi Cucurull Juan wrote: Dear all, After applying the TPM patches to QEMU, I was wondering if it is possible to simultaneously use the TPM in more than one virtual machine, i.e. virtualisation of the TPM. According to the paper "Stefan Berger, Ramón Cáceres, Kenneth A. Goldman, Ronald Perez, Reiner Sailer, Leendert van Doorn. vTPM: Virtualizing the Trusted Platform Module" this seems to be possible in Xen. Is not possible in QEMU? Thanks! Jordi. I don't think the pass-through driver supports use by multiple VMs. Stefan Berger should be able to answer better so I'm adding him to the thread. The pass-through driver cannot provide access for multiple VMs to the single hardware TPM on the host. The usage model and the statefulness of the TPM (SRK password, owner password, keys) basically prevent/complicate this. The implementation for Xen was indep. of the Qemu code base today and there we used a software implementation of the TPM that provided a private TPm instance to each VM. I have patches for this for Qemu but due to an IRC chat in Sept. 2011 they are 'behind' the pass-through driver patches. Stefan
Re: [Qemu-devel] [PATCH 03/18] block: add error parameter to bdrv_snapshot_goto() and related functions
On Wed, 15 Aug 2012 09:41:44 +0200
Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina
> ---
> block.c| 26 +++---
> block.h| 3 ++-
> block/qcow2-snapshot.c | 11 ---
> block/qcow2.h | 4 +++-
> block/rbd.c| 6 +-
> block/sheepdog.c | 16 +---
> block_int.h| 3 ++-
> qemu-img.c | 2 +-
> savevm.c | 2 +-
> 9 files changed, 46 insertions(+), 27 deletions(-)
>
> diff --git a/block.c b/block.c
> index 8bc49b7..ad25184 100644
> --- a/block.c
> +++ b/block.c
> @@ -2683,29 +2683,33 @@ int bdrv_snapshot_create(BlockDriverState *bs,
> }
>
> int bdrv_snapshot_goto(BlockDriverState *bs,
> - const char *snapshot_id)
> + const char *snapshot_id,
> + Error **errp)
> {
> BlockDriver *drv = bs->drv;
> int ret, open_ret;
>
> -if (!drv)
> -return -ENOMEDIUM;
> -if (drv->bdrv_snapshot_goto)
> -return drv->bdrv_snapshot_goto(bs, snapshot_id);
> -
> -if (bs->file) {
> +if (!drv) {
> +error_set(errp, QERR_DEVICE_HAS_NO_MEDIUM, bdrv_get_device_name(bs));
> +ret = -ENOMEDIUM;
Most of the comments I made in 02/18 apply for this patch (and probably
the next ones too), so to summarize:
1. The QERR_ macros are deprecated, we should use error_setg() instead
2. As a general rule, only the Error object should be propagated up (ie.
we shouldn't propagate the Error object _and_ errno). It's debatable if
we can get rid of errno, if we can't then we'll have to extend the error API
to embed errno.
We have to discuss this with block layer guys, preferably before doing
large series.
One more comment below.
> +} else if (drv->bdrv_snapshot_goto) {
> +ret = drv->bdrv_snapshot_goto(bs, snapshot_id, errp);
> +} else if (bs->file) {
> drv->bdrv_close(bs);
> -ret = bdrv_snapshot_goto(bs->file, snapshot_id);
> +ret = bdrv_snapshot_goto(bs->file, snapshot_id, errp);
> open_ret = drv->bdrv_open(bs, bs->open_flags);
> if (open_ret < 0) {
> bdrv_delete(bs->file);
> bs->drv = NULL;
> -return open_ret;
> +error_set(errp, QERR_OPEN_FILE_FAILED, bdrv_get_device_name(bs));
> +ret = open_ret;
> }
> -return ret;
> +} else {
> +error_set(errp, QERR_NOT_SUPPORTED);
> +ret = -ENOTSUP;
> }
>
> -return -ENOTSUP;
> +return ret;
> }
>
> int bdrv_snapshot_delete(BlockDriverState *bs, const char *snapshot_id)
> diff --git a/block.h b/block.h
> index 92e782b..11edcd3 100644
> --- a/block.h
> +++ b/block.h
> @@ -299,7 +299,8 @@ int bdrv_snapshot_create(BlockDriverState *bs,
> QEMUSnapshotInfo *sn_info,
> Error **errp);
> int bdrv_snapshot_goto(BlockDriverState *bs,
> - const char *snapshot_id);
> + const char *snapshot_id,
> + Error **errp);
> int bdrv_snapshot_delete(BlockDriverState *bs, const char *snapshot_id);
> int bdrv_snapshot_list(BlockDriverState *bs,
> QEMUSnapshotInfo **psn_info);
> diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
> index cf86dae..8a87b0c 100644
> --- a/block/qcow2-snapshot.c
> +++ b/block/qcow2-snapshot.c
> @@ -426,7 +426,9 @@ fail:
> }
>
> /* copy the snapshot 'snapshot_name' into the current disk image */
> -int qcow2_snapshot_goto(BlockDriverState *bs, const char *snapshot_id)
> +int qcow2_snapshot_goto(BlockDriverState *bs,
> +const char *snapshot_id,
> +Error **errp)
> {
> BDRVQcowState *s = bs->opaque;
> QCowSnapshot *sn;
> @@ -438,13 +440,13 @@ int qcow2_snapshot_goto(BlockDriverState *bs, const
> char *snapshot_id)
> /* Search the snapshot */
> snapshot_index = find_snapshot_by_id_or_name(bs, snapshot_id);
> if (snapshot_index < 0) {
> +error_set(errp, QERR_OPEN_FILE_FAILED, snapshot_id);
> return -ENOENT;
> }
> sn = &s->snapshots[snapshot_index];
>
> if (sn->disk_size != bs->total_sectors * BDRV_SECTOR_SIZE) {
> -error_report("qcow2: Loading snapshots with different disk "
> -"size is not implemented");
> +error_set(errp, QERR_NOT_SUPPORTED);
> ret = -ENOTSUP;
> goto fail;
> }
> @@ -536,6 +538,9 @@ int qcow2_snapshot_goto(BlockDriverState *bs, const char
> *snapshot_id)
>
> fail:
> g_free(sn_l1_table);
> +if (!error_is_set(errp)) {
> +error_set(errp, QERR_GENERIC_ERROR, ret);
> +}
> return ret;
> }
>
> diff --git a/block/qcow2.h b/block/qcow2.h
> index 854bd12..6babb56 100644
> --- a/block/qcow2.h
> +++ b/block/qcow2.h
> @@ -311,7 +311,9 @@ int qcow2_zero_clusters(BlockDriverState *bs, uint64_t
> offset, in
Re: [Qemu-devel] Is is possible to virtualise or share the TPM?
On 08/30/2012 10:21 AM, Jordi Cucurull Juan wrote: Dear Stefan, What does it mean that the patches with the VTPM functionality exist but they are behind the regular ones? Does it mean that they are not currently updated? That they have less priority? It means that in my patch queue they are 'behind' the ones I posted over the last few months. Stefan Best regards, Jordi. On 08/29/2012 02:57 PM, Stefan Berger wrote: On 08/23/2012 04:05 PM, Corey Bryant wrote: On 08/21/2012 06:31 AM, Jordi Cucurull Juan wrote: Dear all, After applying the TPM patches to QEMU, I was wondering if it is possible to simultaneously use the TPM in more than one virtual machine, i.e. virtualisation of the TPM. According to the paper "Stefan Berger, Ramón Cáceres, Kenneth A. Goldman, Ronald Perez, Reiner Sailer, Leendert van Doorn. vTPM: Virtualizing the Trusted Platform Module" this seems to be possible in Xen. Is not possible in QEMU? Thanks! Jordi. I don't think the pass-through driver supports use by multiple VMs. Stefan Berger should be able to answer better so I'm adding him to the thread. The pass-through driver cannot provide access for multiple VMs to the single hardware TPM on the host. The usage model and the statefulness of the TPM (SRK password, owner password, keys) basically prevent/complicate this. The implementation for Xen was indep. of the Qemu code base today and there we used a software implementation of the TPM that provided a private TPm instance to each VM. I have patches for this for Qemu but due to an IRC chat in Sept. 2011 they are 'behind' the pass-through driver patches. Stefan
[Qemu-devel] [Bug 1037606] Re: vmwgfx does not work with kvm vmware vga
** Bug watch added: Linux Kernel Bug Tracker #46711 http://bugzilla.kernel.org/show_bug.cgi?id=46711 ** Also affects: linux via http://bugzilla.kernel.org/show_bug.cgi?id=46711 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1037606 Title: vmwgfx does not work with kvm vmware vga Status in The Linux Kernel: Unknown Status in QEMU: New Status in “linux” package in Ubuntu: Triaged Bug description: vmwgfx driver fails to initialize inside kvm. tried: kvm -m 2048 -vga vmware -cdrom RebeccaBlackLinux.iso (Ubuntu based, any Ubuntu live CD would do) Apport data collected with qantal alpha live CD (somewhat older kernel). The error is shjown in CurrentDmesg.txt https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1037606/+attachment/3265235/+files/CurrentDmesg.txt --- ApportVersion: 2.4-0ubuntu8 Architecture: amd64 AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found. CasperVersion: 1.320 DistroRelease: Ubuntu 12.10 IwConfig: eth0 no wireless extensions. lono wireless extensions. LiveMediaBuild: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120724.2) Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99 MachineType: Bochs Bochs Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: file=/cdrom/preseed/hostname.seed boot=casper initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity ProcVersionSignature: Ubuntu 3.5.0-6.6-generic 3.5.0 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-3.5.0-6-generic N/A linux-backports-modules-3.5.0-6-generic N/A linux-firmware 1.85 RfKill: Tags: quantal Uname: Linux 3.5.0-6-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: dmi.bios.date: 01/01/2007 dmi.bios.vendor: Bochs dmi.bios.version: Bochs dmi.chassis.type: 1 dmi.chassis.vendor: Bochs dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr: dmi.product.name: Bochs dmi.sys.vendor: Bochs --- ApportVersion: 2.0.1-0ubuntu12 Architecture: i386 DistroRelease: Ubuntu 12.04 InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007) Package: linux (not installed) ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash Tags: precise running-unity Uname: Linux 3.6.0-030600rc3-generic i686 UnreportableReason: The running kernel is not an Ubuntu kernel UpgradeStatus: Upgraded to precise on 2012-08-30 (0 days ago) UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1037606/+subscriptions
Re: [Qemu-devel] [PATCH 02/18] block: add error parameter to bdrv_snapshot_create() and related functions
On Wed, 15 Aug 2012 09:41:43 +0200
Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina
> ---
> block.c| 25 +
> block.h| 3 ++-
> block/qcow2-snapshot.c | 9 -
> block/qcow2.h | 4 +++-
> block/rbd.c| 20 ++--
> block/sheepdog.c | 17 +
> block_int.h| 3 ++-
> qemu-img.c | 2 +-
> savevm.c | 2 +-
> 9 files changed, 57 insertions(+), 28 deletions(-)
>
> diff --git a/block.c b/block.c
> index 016858b..8bc49b7 100644
> --- a/block.c
> +++ b/block.c
> @@ -2661,16 +2661,25 @@ BlockDriverState *bdrv_snapshots(void)
> }
>
> int bdrv_snapshot_create(BlockDriverState *bs,
> - QEMUSnapshotInfo *sn_info)
> + QEMUSnapshotInfo *sn_info,
> + Error **errp)
> {
> BlockDriver *drv = bs->drv;
> -if (!drv)
> -return -ENOMEDIUM;
> -if (drv->bdrv_snapshot_create)
> -return drv->bdrv_snapshot_create(bs, sn_info);
> -if (bs->file)
> -return bdrv_snapshot_create(bs->file, sn_info);
> -return -ENOTSUP;
> +int ret;
> +
> +if (!drv) {
> +error_set(errp, QERR_DEVICE_HAS_NO_MEDIUM, bdrv_get_device_name(bs));
We should only use QERR_ macros for the errors listed in the ErrorClass enum
(except GenericError), all other errors should generally use error_setg(), like
this:
error_setg(errp, "device '%s' has no medium);
> +ret = -ENOMEDIUM;
And, usually, we should get rid of errno propagation. There are two cases here:
1. errno is propagated up so that upper layers can print a decent error
message to the user.
In this case, it's safe to eliminate errno. error_setg() will store a
decent message already and the Error object can be propagated up.
2. errno is propagated up so that upper layers can distinguish among
error causes and take different actions accordingly.
Doesn't seem to be the case of bdrv_snapshot_create() (ie. errno is only
used to communicate the error to the user). However, I'm pretty sure that
such usage exists in qemu and the error API will break it, as most of our
errors are generic.
I see two solutions to this problem:
A. Add specific errors to ErrorClass. I don't like this very much,
as it's possible that such errors are going to be useful only
internally.
B. Add two new functions:
void error_sete(Error **err, ErrorClass err_class, int errno, const
char *fmt, ...);
int error_get_errno(const Error **err);
So that we can maintain errno when it's used to communicate
error cause among functions.
> +} else if (drv->bdrv_snapshot_create) {
> +ret = drv->bdrv_snapshot_create(bs, sn_info, errp);
> +} else if (bs->file) {
> +ret = bdrv_snapshot_create(bs->file, sn_info, errp);
> +} else {
> +error_set(errp, QERR_NOT_SUPPORTED);
> +ret = -ENOTSUP;
> +}
> +
> +return ret;
> }
>
> int bdrv_snapshot_goto(BlockDriverState *bs,
> diff --git a/block.h b/block.h
> index 2e2be11..92e782b 100644
> --- a/block.h
> +++ b/block.h
> @@ -296,7 +296,8 @@ int bdrv_can_snapshot(BlockDriverState *bs);
> int bdrv_is_snapshot(BlockDriverState *bs);
> BlockDriverState *bdrv_snapshots(void);
> int bdrv_snapshot_create(BlockDriverState *bs,
> - QEMUSnapshotInfo *sn_info);
> + QEMUSnapshotInfo *sn_info,
> + Error **errp);
> int bdrv_snapshot_goto(BlockDriverState *bs,
> const char *snapshot_id);
> int bdrv_snapshot_delete(BlockDriverState *bs, const char *snapshot_id);
> diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
> index 4e7c93b..cf86dae 100644
> --- a/block/qcow2-snapshot.c
> +++ b/block/qcow2-snapshot.c
> @@ -25,6 +25,7 @@
> #include "qemu-common.h"
> #include "block_int.h"
> #include "block/qcow2.h"
> +#include "qerror.h"
>
> typedef struct QEMU_PACKED QCowSnapshotHeader {
> /* header is 8 byte aligned */
> @@ -312,7 +313,9 @@ static int find_snapshot_by_id_or_name(BlockDriverState
> *bs, const char *name)
> }
>
> /* if no id is provided, a new one is constructed */
> -int qcow2_snapshot_create(BlockDriverState *bs, QEMUSnapshotInfo *sn_info)
> +int qcow2_snapshot_create(BlockDriverState *bs,
> + QEMUSnapshotInfo *sn_info,
> + Error **errp)
> {
> BDRVQcowState *s = bs->opaque;
> QCowSnapshot *new_snapshot_list = NULL;
> @@ -331,6 +334,8 @@ int qcow2_snapshot_create(BlockDriverState *bs,
> QEMUSnapshotInfo *sn_info)
>
> /* Check that the ID is unique */
> if (find_snapshot_by_id(bs, sn_info->id_str) >= 0) {
> +error_set(errp, QERR_INVALID_PARAMETER_VALUE,
> + "name", "non-existing id identifier");
> return -EEXIST;
> }
>
> @@
Re: [Qemu-devel] [PATCH for-1.2] msix: make [un]use vectors on reset/load optional
On Thu, Aug 30, 2012 at 03:34:42PM +0200, Andreas Färber wrote: > Am 29.08.2012 20:13, schrieb Michael S. Tsirkin: > > On Wed, Aug 29, 2012 at 06:54:35PM +0200, Andreas Färber wrote: > >> $subject: "[un]used vectors"? -- could be fixed by committer. > > > > Sorry I don't unedrstand. it's not 'unused': it's use and unuse. > > What is wrong with the subject? > > The grammar with two verbs "make [un]use" sounded wrong to my ears. > Given your explanation of [un]use above, did you mean "make clearing > [un]use vectors optional on reset/load" or something like that? > > /-F No, sorry. What is meant is simply functions msix_vector_use/msix_vector_unuse: calling these on reset/load was required but is now optional. > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [Bug 1037606] Re: vmwgfx does not work with kvm vmware vga
This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug. If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report. [0] https://wiki.ubuntu.com/Bugs/Upstream/kernel ** Changed in: linux (Ubuntu) Status: Confirmed => Triaged -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1037606 Title: vmwgfx does not work with kvm vmware vga Status in QEMU: New Status in “linux” package in Ubuntu: Triaged Bug description: vmwgfx driver fails to initialize inside kvm. tried: kvm -m 2048 -vga vmware -cdrom RebeccaBlackLinux.iso (Ubuntu based, any Ubuntu live CD would do) Apport data collected with qantal alpha live CD (somewhat older kernel). The error is shjown in CurrentDmesg.txt https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1037606/+attachment/3265235/+files/CurrentDmesg.txt --- ApportVersion: 2.4-0ubuntu8 Architecture: amd64 AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found. CasperVersion: 1.320 DistroRelease: Ubuntu 12.10 IwConfig: eth0 no wireless extensions. lono wireless extensions. LiveMediaBuild: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120724.2) Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99 MachineType: Bochs Bochs Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: file=/cdrom/preseed/hostname.seed boot=casper initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity ProcVersionSignature: Ubuntu 3.5.0-6.6-generic 3.5.0 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-3.5.0-6-generic N/A linux-backports-modules-3.5.0-6-generic N/A linux-firmware 1.85 RfKill: Tags: quantal Uname: Linux 3.5.0-6-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: dmi.bios.date: 01/01/2007 dmi.bios.vendor: Bochs dmi.bios.version: Bochs dmi.chassis.type: 1 dmi.chassis.vendor: Bochs dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr: dmi.product.name: Bochs dmi.sys.vendor: Bochs --- ApportVersion: 2.0.1-0ubuntu12 Architecture: i386 DistroRelease: Ubuntu 12.04 InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007) Package: linux (not installed) ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash Tags: precise running-unity Uname: Linux 3.6.0-030600rc3-generic i686 UnreportableReason: The running kernel is not an Ubuntu kernel UpgradeStatus: Upgraded to precise on 2012-08-30 (0 days ago) UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1037606/+subscriptions
Re: [Qemu-devel] Is is possible to virtualise or share the TPM?
Dear Stefan, What does it mean that the patches with the VTPM functionality exist but they are behind the regular ones? Does it mean that they are not currently updated? That they have less priority? Best regards, Jordi. On 08/29/2012 02:57 PM, Stefan Berger wrote: On 08/23/2012 04:05 PM, Corey Bryant wrote: On 08/21/2012 06:31 AM, Jordi Cucurull Juan wrote: Dear all, After applying the TPM patches to QEMU, I was wondering if it is possible to simultaneously use the TPM in more than one virtual machine, i.e. virtualisation of the TPM. According to the paper "Stefan Berger, Ramón Cáceres, Kenneth A. Goldman, Ronald Perez, Reiner Sailer, Leendert van Doorn. vTPM: Virtualizing the Trusted Platform Module" this seems to be possible in Xen. Is not possible in QEMU? Thanks! Jordi. I don't think the pass-through driver supports use by multiple VMs. Stefan Berger should be able to answer better so I'm adding him to the thread. The pass-through driver cannot provide access for multiple VMs to the single hardware TPM on the host. The usage model and the statefulness of the TPM (SRK password, owner password, keys) basically prevent/complicate this. The implementation for Xen was indep. of the Qemu code base today and there we used a software implementation of the TPM that provided a private TPm instance to each VM. I have patches for this for Qemu but due to an IRC chat in Sept. 2011 they are 'behind' the pass-through driver patches. Stefan -- Jordi Cucurull Juan Researcher Scytl Secure Electronic Voting Plaça Gal·la Placidia, 1-3, 1st floor · 08006 Barcelona Phone: + 34 934 230 324 Fax+ 34 933 251 028 jordi.cucur...@scytl.com http://www.scytl.com NOTICE: The information in this e-mail and in any of its attachments is confidential and intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, any disclosure, copying, distribution or retaining of this message or any part of it, without the prior written consent of Scytl Secure Electronic Voting, SA is prohibited and may be unlawful. If you have received this in error, please contact the sender and delete the material from any computer. Your data are in a file owned by Scytl Secure Electronic Voting, S.A. You can exercice your rights of access, rectification, cancellation and opposition by contacting Scytl Secure Electronic Voting, S.A. at the following address: Gal·la Placídia, 1-3. 1st, 08006 Barcelona (Spain), according to the Organic Law 15/1999, of 13th December of Protection of Personal Data.
Re: [Qemu-devel] [PATCH for-1.2] msix: make [un]use vectors on reset/load optional
Am 29.08.2012 20:13, schrieb Michael S. Tsirkin: > On Wed, Aug 29, 2012 at 06:54:35PM +0200, Andreas Färber wrote: >> $subject: "[un]used vectors"? -- could be fixed by committer. > > Sorry I don't unedrstand. it's not 'unused': it's use and unuse. > What is wrong with the subject? The grammar with two verbs "make [un]use" sounded wrong to my ears. Given your explanation of [un]use above, did you mean "make clearing [un]use vectors optional on reset/load" or something like that? /-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.2] hw/arm_gic.c: Define .class_size in arm_gic_info TypeInfo
Am 29.08.2012 20:57, schrieb Stefan Weil: > PS. Are there perhaps more bugs of this sort? A quick test looking > for .class_init without .class_size shows a lot of files. That alone is not wrong. A problem only arises when a new struct ...Class is casted to but the object not sized appropriately through .class_size. 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] macvlan/macvtap: guest/host cannot communicate when network cable is unplugged
On Thu, Aug 30, 2012 at 1:13 PM, ching wrote: > >> Can you try the same test with two macvlan interfaces on the host (no >> macvtap)? You may need to use the ping -I >> argument to force the ping source address to a specific macvlan >> interface. >> >> If you see the same problem, it may just be the macvlan design - it is >> stacked on top of eth0 and might not work when eth0 is down. CCing >> macvlan/macvtap folks. >> >> Stefan >> > > tested as below > > $ifconfig > > eth0 Link encap:Ethernet HWaddr f4:6d:xx:xx:xx:xx > inet6 addr: fe80::xx:xx:xx:xx/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:86507 errors:0 dropped:0 overruns:0 frame:0 > TX packets:55940 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:126005746 (120.1 MiB) TX bytes:4394225 (4.1 MiB) > > macvtap0 Link encap:Ethernet HWaddr 52:54:xx:xx:xx:xx > inet6 addr: fe80::xx:xx:xx:xx/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:70 errors:0 dropped:0 overruns:0 frame:0 > TX packets:84 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:9036 (8.8 KiB) TX bytes:14734 (14.3 KiB) > > znet0 Link encap:Ethernet HWaddr 00:60:xx:xx:xx:92 > inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 > inet6 addr: 2002:xx:xx:xx:xx/64 Scope:Global > inet6 addr: fe80:xx:xx:xx:xx/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:4463190 errors:0 dropped:0 overruns:0 frame:0 > TX packets:12527522 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:3959213697 (3.6 GiB) TX bytes:18590336476 (17.3 GiB) > >znet1 Link encap:Ethernet HWaddr 00:60:xx:xx:xx:99 > inet addr:192.168.1.177 Bcast:192.168.1.255 Mask:255.255.255.0 > inet6 addr: 2002:xx:xx:xx:xx64 Scope:Global > inet6 addr: fe80:xx:xx:xx:xx/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:8 errors:0 dropped:0 overruns:0 frame:0 > TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:1399 (1.3 KiB) TX bytes:1522 (1.4 KiB) > > $ ip -d link show > > 10: znet0@eth0: mtu 1500 qdisc noqueue > state UP mode DEFAULT > link/ether 00:60:xx:xx:xx:92 brd ff:ff:ff:ff:ff:ff > macvlan mode bridge > 15: znet1@eth0: mtu 1500 qdisc noqueue > state UNKNOWN mode DEFAULT > link/ether 00:60:xx:xx:xx:99 brd ff:ff:ff:ff:ff:ff > macvlan mode bridge > > > the macvlan interface cannot ping each other no matter network cable is > plugged or not > > $ ping -I 192.168.1.2 192.168.1.177 > PING 192.168.1.177 (192.168.1.177) from 192.168.1.2 : 56(84) bytes of data. > > --- 192.168.1.177 ping statistics --- > 6 packets transmitted, 0 received, 100% packet loss, time 4999ms In bridge mode I expected them to be able to communicate. > I also perform an additional test: the guests (macvtap bridge mode) CAN > communicate each other no matter network cable is plugged or not. Strange. I thought the original problem was that the macvtap guests cannot communicate with each other when the network cable is unplugged? Hopefully someone else can help you, I'm not familiar enough with macvlan/macvtap. Stefan
[Qemu-devel] [PATCH] xhci: allow 1 and 2 bytes accesses to capability registers
Some xHC drivers (most notably on Windows and BSD systems) read
the first capability registers using 1 and 2 bytes accesses, since
this is how they are defined in section 5.3 of the xHCI specs.
Enabling these kind of read accesses allows Windows and FreeBSD
guests to properly recognize the host controller.
As this is an exception to the general 4-byte aligned accesses rule,
we special-case the code path for capability reading and implement
checks to guard against wrong size/alignment combinations.
Signed-off-by: Alejandro Martinez Ruiz
---
hw/usb/hcd-xhci.c | 75 ---
1 file changed, 55 insertions(+), 20 deletions(-)
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index 6c2ff02..6cca161 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -2320,13 +2320,30 @@ static void xhci_reset(DeviceState *dev)
xhci->ev_buffer_get = 0;
}
-static uint32_t xhci_cap_read(XHCIState *xhci, uint32_t reg)
+static uint32_t xhci_cap_read(XHCIState *xhci, uint32_t reg, unsigned size)
{
-uint32_t ret;
+uint32_t ret = 0;
+
+/*
+ * Section 5.3 of the xHCI specification defines the first capability
+ * registers as being only 1 and 2 bytes in size. In fact, these are
+ * often accessed as 1 or 2 bytes reads.
+ *
+ * Some drivers read the first 4 bytes in one go, while others -most
+ * notably the original NEC Renesas driver for Windows and the *BSDs-
+ * read one register at a time. This is the only known exception to
+ * the 4 byte accesses rule, so we'll special-case the code.
+ */
switch (reg) {
-case 0x00: /* HCIVERSION, CAPLENGTH */
-ret = 0x0100 | LEN_CAP;
+case 0x00: /* CAPLENGTH [, HCIVERSION] */
+ret = LEN_CAP;
+if (size < 4) {
+break;
+}
+/* fall-through if asking for all 4 bytes */
+case 0x02: /* HCIVERSION */
+ret |= 0x0100 >> (4 - size) * CHAR_BIT;
break;
case 0x04: /* HCSPARAMS 1 */
ret = (MAXPORTS<<24) | (MAXINTRS<<8) | MAXSLOTS;
@@ -2685,26 +2702,43 @@ static void xhci_doorbell_write(XHCIState *xhci,
uint32_t reg, uint32_t val)
static uint64_t xhci_mem_read(void *ptr, target_phys_addr_t addr,
unsigned size)
{
+uint64_t ret = 0;
XHCIState *xhci = ptr;
-/* Only aligned reads are allowed on xHCI */
-if (addr & 3) {
-fprintf(stderr, "xhci_mem_read: Mis-aligned read\n");
-return 0;
-}
-
+/* Allow 1, 2 and 4-byte aligned reads on capabilities, and only
+ * 4-byte reads elsewhere.
+ */
if (addr < LEN_CAP) {
-return xhci_cap_read(xhci, addr);
-} else if (addr >= OFF_OPER && addr < (OFF_OPER + LEN_OPER)) {
-return xhci_oper_read(xhci, addr - OFF_OPER);
-} else if (addr >= OFF_RUNTIME && addr < (OFF_RUNTIME + LEN_RUNTIME)) {
-return xhci_runtime_read(xhci, addr - OFF_RUNTIME);
-} else if (addr >= OFF_DOORBELL && addr < (OFF_DOORBELL + LEN_DOORBELL)) {
-return xhci_doorbell_read(xhci, addr - OFF_DOORBELL);
+/* deny accesses to odd addresses, specially since we accept 1-byte
reads */
+if (addr & 1) {
+fprintf(stderr, "xhci_mem_read: invalid %ud-byte capability read
at address %x\n", size, (unsigned int) addr);
+goto out;
+}
+
+/* We deal with read size down in xhci_cap_read, since access
+ * is variable for some addresses.
+ */
+ret = xhci_cap_read(xhci, addr, size);
} else {
-fprintf(stderr, "xhci_mem_read: Bad offset %x\n", (int)addr);
-return 0;
+/* non capability read */
+if (size < 4) {
+fprintf(stderr, "xhci_mem_read: mis-aligned %ud-byte read on
address %x\n", size, (unsigned int) addr);
+goto out;
+}
+
+if (addr >= OFF_OPER && addr < (OFF_OPER + LEN_OPER)) {
+ret = xhci_oper_read(xhci, addr - OFF_OPER);
+} else if (addr >= OFF_RUNTIME && addr < (OFF_RUNTIME + LEN_RUNTIME)) {
+ret = xhci_runtime_read(xhci, addr - OFF_RUNTIME);
+} else if (addr >= OFF_DOORBELL && addr < (OFF_DOORBELL +
LEN_DOORBELL)) {
+ret = xhci_doorbell_read(xhci, addr - OFF_DOORBELL);
+} else {
+fprintf(stderr, "xhci_mem_read: tried to read %ud bytes from bad
offset %x\n", size, (unsigned int) addr);
+}
}
+
+out:
+return ret;
}
static void xhci_mem_write(void *ptr, target_phys_addr_t addr,
@@ -2732,8 +2766,9 @@ static void xhci_mem_write(void *ptr, target_phys_addr_t
addr,
static const MemoryRegionOps xhci_mem_ops = {
.read = xhci_mem_read,
.write = xhci_mem_write,
-.valid.min_access_size = 4,
+.valid.min_access_size = 1,
.valid.max_access_size = 4,
+.valid.unaligned = false,
.endianness = DEVICE_LITTLE_ENDIAN,
};
--
1.7.12.rc2.18.g61b472e
Re: [Qemu-devel] [PATCH V6 0/2] Add JSON output to qemu-img info
Le Monday 27 Aug 2012 à 11:52:59 (-0600), Eric Blake a écrit : > On 08/27/2012 01:15 AM, Benoît Canet wrote: > > This patchset add a JSON output mode to the qemu-img info command. > > It's a rewrite from scratch of the original patchset by Wenchao Xia > > following Anthony Liguori advices on JSON formating. > > > > the --output=(json|human) option is now mandatory on the command line. > > This statement is not true, but doesn't affect the series itself. > > > in v6: > > > > Blue Swirl: -Add missing const in getopt structure declaration. > > > > Eric Blake: -Remove spurious undef. > > -Use an enum instead of two boolean. > > You have now addressed my complaints about the interface, but I would > feel comfortable if someone more familiar with qemu-img itself gives > final review and/or ack. gentle ping Benoît > > -- > Eric Blake ebl...@redhat.com+1-919-301-3266 > Libvirt virtualization library http://libvirt.org >
[Qemu-devel] Posix timer syscalls ; dealing with the timer_t type
Hi all, I'm working on implementing Posix timers in linux-user. I'm having trouble figuring out how to handle the timer_t type. Consider the following code with say 32 bit ARM being emulated on 64 bit x86-64: timer_t timerid; err = timer_create(clockid, &sev, &timerid); err = timer_gettime(timerid, &curr); The issue is that memory for the timer_t value in the 32 bit target is alloacted on the tack (where the timer_t is 4 bytes) but the value provided by the 64 bit host where the timer_t is 8 bytes. Any suggestions on dealing with this? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/
Re: [Qemu-devel] QEMU emulation per CPU
Hi Santosa, Can you please forward a link of that discussion thread ?? Thanks and Regards -Naresh Bhat On Thu, Aug 30, 2012 at 2:39 PM, Mulyadi Santosa wrote: > Hi... > > On Thu, Aug 30, 2012 at 3:58 PM, Naresh Bhat wrote: >> Hi, >> >> Can you please explain me why qemu user mode doesn't get along nicely >> with POSIX threads. ?? > > there is another thread in this qemu-devel list that explains this. > All I can conclude from that thread is that it has something to do > with timers and address mapping... > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com -- "For things to change, we must change" -Naresh Bhat
Re: [Qemu-devel] [PATCH 01/18] qerror: introduce QERR_GENERIC_ERROR
On Wed, 15 Aug 2012 09:41:42 +0200 Pavel Hrdina wrote: > Signed-off-by: Pavel Hrdina > --- > qerror.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/qerror.h b/qerror.h > index d0a76a4..7e0bae7 100644 > --- a/qerror.h > +++ b/qerror.h > @@ -120,6 +120,9 @@ void assert_no_error(Error *err); > #define QERR_FEATURE_DISABLED \ > ERROR_CLASS_GENERIC_ERROR, "The feature '%s' is not enabled" > > +#define QERR_GENERIC_ERROR \ > +ERROR_CLASS_GENERIC_ERROR, "An (Errno %d) error has occurred" > + You should use error_setg() instead: http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg04980.html There usage examples in the series introducing it. It would be better to wait for it to be merged before you use it though, as it's always possible for people to ask for changes. > #define QERR_INVALID_BLOCK_FORMAT \ > ERROR_CLASS_GENERIC_ERROR, "Invalid block format '%s'" >
Re: [Qemu-devel] macvlan/macvtap: guest/host cannot communicate when network cable is unplugged
> Can you try the same test with two macvlan interfaces on the host (no > macvtap)? You may need to use the ping -I > argument to force the ping source address to a specific macvlan > interface. > > If you see the same problem, it may just be the macvlan design - it is > stacked on top of eth0 and might not work when eth0 is down. CCing > macvlan/macvtap folks. > > Stefan > tested as below $ifconfig eth0 Link encap:Ethernet HWaddr f4:6d:xx:xx:xx:xx inet6 addr: fe80::xx:xx:xx:xx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:86507 errors:0 dropped:0 overruns:0 frame:0 TX packets:55940 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:126005746 (120.1 MiB) TX bytes:4394225 (4.1 MiB) macvtap0 Link encap:Ethernet HWaddr 52:54:xx:xx:xx:xx inet6 addr: fe80::xx:xx:xx:xx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:70 errors:0 dropped:0 overruns:0 frame:0 TX packets:84 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:9036 (8.8 KiB) TX bytes:14734 (14.3 KiB) znet0 Link encap:Ethernet HWaddr 00:60:xx:xx:xx:92 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 2002:xx:xx:xx:xx/64 Scope:Global inet6 addr: fe80:xx:xx:xx:xx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4463190 errors:0 dropped:0 overruns:0 frame:0 TX packets:12527522 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3959213697 (3.6 GiB) TX bytes:18590336476 (17.3 GiB) znet1 Link encap:Ethernet HWaddr 00:60:xx:xx:xx:99 inet addr:192.168.1.177 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 2002:xx:xx:xx:xx64 Scope:Global inet6 addr: fe80:xx:xx:xx:xx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1399 (1.3 KiB) TX bytes:1522 (1.4 KiB) $ ip -d link show 10: znet0@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT link/ether 00:60:xx:xx:xx:92 brd ff:ff:ff:ff:ff:ff macvlan mode bridge 15: znet1@eth0: mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT link/ether 00:60:xx:xx:xx:99 brd ff:ff:ff:ff:ff:ff macvlan mode bridge the macvlan interface cannot ping each other no matter network cable is plugged or not $ ping -I 192.168.1.2 192.168.1.177 PING 192.168.1.177 (192.168.1.177) from 192.168.1.2 : 56(84) bytes of data. --- 192.168.1.177 ping statistics --- 6 packets transmitted, 0 received, 100% packet loss, time 4999ms I also perform an additional test: the guests (macvtap bridge mode) CAN communicate each other no matter network cable is plugged or not.
