Gleb Natapov g...@redhat.com wrote:
On Wed, Jan 20, 2010 at 09:14:03PM +0100, Juan Quintela wrote:
From: Kirill A. Shutemov kir...@shutemov.name
CCblock/vvfat.o
cc1: warnings being treated as errors
block/vvfat.c: In function 'commit_one_file':
block/vvfat.c:2259: error: ignoring
On Thu, Jan 21, 2010 at 09:17:27AM +0100, Juan Quintela wrote:
Gleb Natapov g...@redhat.com wrote:
On Wed, Jan 20, 2010 at 09:14:03PM +0100, Juan Quintela wrote:
From: Kirill A. Shutemov kir...@shutemov.name
CCblock/vvfat.o
cc1: warnings being treated as errors
block/vvfat.c: In
On Wed, Jan 20, 2010, Måns Rullgård wrote:
If you make that IFS=${local_ifs:-$(printf ' \t\n')} it should be safe.
Likewise if you set the value first.
Ok; see attached patches
--
Loïc Minier
From cccdcaeacc2214390c0c6c198ed875ac59d10669 Mon Sep 17 00:00:00 2001
From:
Loïc Minier l...@dooz.org wrote:
On Wed, Jan 20, 2010, Måns Rullgård wrote:
If you make that IFS=${local_ifs:-$(printf ' \t\n')} it should be safe.
Likewise if you set the value first.
Ok; see attached patches
I still think that path_of is a complication that we don't really need.
type
Amit, what about renaming hw/virtio-serial.c to a less misleading name
now?
On (Thu) Jan 21 2010 [10:53:36], Markus Armbruster wrote:
Amit, what about renaming hw/virtio-serial.c to a less misleading name
now?
I'm going to push that upstream; Anthony in the past indicated he was ok
with it.
Amit
This file was renamed to ease the reviews of the recent changes
that went in.
Now that the changes are done, rename the file back to its original
name.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
Makefile.objs|2 +-
hw/{virtio-serial.c = virtio-console.c} |
These hunks got dropped off mysteriously during the rebasing of my
virtio-serial series. Thanks go to Markus for noticing it.
Without these fixes, -virtioconsole doesn't actually have any effect.
Signed-off-by: Amit Shah amit.s...@redhat.com
Reported-by: Markus Armbruster arm...@redhat.com
---
On (Wed) Jan 13 2010 [12:32:54], Amit Shah wrote:
I'd be very interested in the results of Sparc32 and Sparc64 analyses.
OK, I added the two targets to the run and got the following result:
http://amitshah.fedorapeople.org/clang-output/2010-01-13-1/
The bug count went up from 95 for
Juan Quintela quint...@redhat.com writes:
Loïc Minier l...@dooz.org wrote:
On Wed, Jan 20, 2010, Måns Rullgård wrote:
If you make that IFS=${local_ifs:-$(printf ' \t\n')} it should be safe.
Likewise if you set the value first.
Ok; see attached patches
I still think that path_of is a
A comment from Christoph Hellwig made me check (and fix) some stuff.
I'm afraid there are some more callers that needs to explicitly ask for
read-write permissions.
I'd like to get comments about that.
P.S. The qcow2 bug (I introduced) in pre-allocate showed me there's a need to
check return
*** BLURB HERE ***
Naphtali Sprei (3):
No need anymoe for bdrv_set_read_only
Ask for read-write permissions when opening files
Read-only device changed to opens it's file for read-only.
block.c |7 ---
block.h |1 -
block/bochs.c |6 ++
*** BLURB HERE ***
Naphtali Sprei (3):
No need anymore for bdrv_set_read_only
Ask for read-write permissions when opening files where needed
Read-only device changed to opens it's file for read-only.
block.c |7 ---
block.h |1 -
block/bochs.c |6
Signed-off-by: Naphtali Sprei nsp...@redhat.com
---
block.c |7 ---
block.h |1 -
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/block.c b/block.c
index 73c26ec..8378c18 100644
--- a/block.c
+++ b/block.c
@@ -1009,13 +1009,6 @@ int bdrv_is_read_only(BlockDriverState
Signed-off-by: Naphtali Sprei nsp...@redhat.com
---
block.c |7 ---
block.h |1 -
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/block.c b/block.c
index 73c26ec..8378c18 100644
--- a/block.c
+++ b/block.c
@@ -1009,13 +1009,6 @@ int bdrv_is_read_only(BlockDriverState
Found some places that seems needs this explicitly, now that
read-write is not the default.
Signed-off-by: Naphtali Sprei nsp...@redhat.com
---
block/qcow2.c |2 +-
block/vvfat.c |2 +-
qemu-img.c|4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Found some places that seems needs this explicitly, now that
read-write is not the default.
Signed-off-by: Naphtali Sprei nsp...@redhat.com
---
block/qcow2.c |2 +-
block/vvfat.c |2 +-
qemu-img.c|4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Signed-off-by: Naphtali Sprei nsp...@redhat.com
---
block/bochs.c |6 ++
block/parallels.c |6 ++
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/block/bochs.c b/block/bochs.c
index 3489258..fb83594 100644
--- a/block/bochs.c
+++ b/block/bochs.c
@@ -116,11
On Wed, 20 Jan 2010 17:08:17 +0100
Markus Armbruster arm...@redhat.com wrote:
This is a double value with optional suffixes G, g, M, m, K, k. We'll
need this to get migrate_set_speed() QMP-ready.
Nice, not only good for QMP: we're moving this kind of handling
from the handlers to common
Christoph Hellwig wrote:
Looking at the version of this that landed in git I don't think the
read-only handling is entirely clean after this.
I fixed what I could, still I got some questions below.
- we now normally set the read_only flag from bdrv_open2 when we do
not have the O_RDWR
On Wed, 20 Jan 2010 19:22:48 +
Blue Swirl blauwir...@gmail.com wrote:
On Wed, Jan 20, 2010 at 6:11 PM, Luiz Capitulino lcapitul...@redhat.com
wrote:
On Wed, 20 Jan 2010 18:57:56 +0100
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
Luiz Capitulino lcapitul...@redhat.com writes:
On Wed, 20 Jan 2010 17:08:20 +0100
Markus Armbruster arm...@redhat.com wrote:
This is a double value with optional suffixes ms, us, ns. We'll need
this to get migrate_set_downtime() QMP-ready.
Signed-off-by: Markus Armbruster
Luiz Capitulino lcapitul...@redhat.com writes:
On Wed, 20 Jan 2010 17:08:17 +0100
Markus Armbruster arm...@redhat.com wrote:
This is a double value with optional suffixes G, g, M, m, K, k. We'll
need this to get migrate_set_speed() QMP-ready.
Nice, not only good for QMP: we're moving
Luvalley is a lightweight type-1 Virtual Machine Monitor (VMM).
Its part of source codes are derived from KVM to virtualize
CPU instructions and memory management unit (MMU). However, its
overall architecture is completely different from KVM, but somewhat
like Xen. Luvalley runs outside of Linux,
On Thu, 21 Jan 2010 14:54:51 +0100
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
On Wed, 20 Jan 2010 17:08:20 +0100
Markus Armbruster arm...@redhat.com wrote:
This is a double value with optional suffixes ms, us, ns. We'll need
this to get
On Thu, 21 Jan 2010 15:04:43 +0100
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
On Wed, 20 Jan 2010 17:08:17 +0100
Markus Armbruster arm...@redhat.com wrote:
This is a double value with optional suffixes G, g, M, m, K, k. We'll
need this
john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu name' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme document
Luiz Capitulino lcapitul...@redhat.com writes:
On Thu, 21 Jan 2010 15:04:43 +0100
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
On Wed, 20 Jan 2010 17:08:17 +0100
Markus Armbruster arm...@redhat.com wrote:
This is a double value with
On 01/20/2010 07:18 PM, john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpuname' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a
On 21.01.2010, at 15:19, Xiaodong Yi wrote:
Luvalley is a lightweight type-1 Virtual Machine Monitor (VMM).
Its part of source codes are derived from KVM to virtualize
CPU instructions and memory management unit (MMU). However, its
overall architecture is completely different from KVM, but
The n member is not very descriptive and very hard to grep, rename it to
cur_nr_sectors to better indicate what it is used for. Also rename
nb_sectors to remaining_sectors as that is what it is used for.
Signed-off-by: Christoph Hellwig h...@lst.de
Index: qemu/block/qcow2.c
This series of patches reduce the down time of the guest during a migration
without shared storage. It does that by start transfer dirty blocks in the
iterative phase. In the current code transferring of dirty blocks begins only
during the full phase while the guest is suspended. Therefore the
blk_mig_save_bulked_block is never called with sync flag. Remove the sync
flag. Calculate bulk completion during blk_mig_save_bulked_block.
Changes from v1: remove trailing whitespaces and minor cleanups.
Signed-off-by: Liran Schour lir...@il.ibm.com
---
block-migration.c | 59
This will manage dirty counter for each device and will allow to get the
dirty counter from above.
Changes from v1: remove trailing whitespaces.
Signed-off-by: Liran Schour lir...@il.ibm.com
---
block.c | 16 ++--
block.h |1 +
block_int.h |1 +
3 files changed, 16
Move to stage3 only when remaining work can be done below max downtime.
Changes from v1: remove max iterations. Try to infer storage performance and by
that calculate remaining work.
Signed-off-by: Liran Schour lir...@il.ibm.com
---
block-migration.c | 136
Start transfer dirty blocks during the iterative stage. That will
reduce the time that the guest will be suspended
Changes from v1: remove trailing whitespaces and remove max iterations limit.
Signed-off-by: Liran Schour lir...@il.ibm.com
---
block-migration.c | 135
Hi,
under a mostly stable Gentoo I observed this new msg :
tfoer...@n22 ~/virtual/kvm $ qemu -hda gentoo_kdevm.img -hdb
portage_kdeprefix.img -hdd swap.img -smp 2 -m 768 -vga std -soundhw es1370
BUG:
Stefan Weil w...@mail.berlios.de writes:
When called with property ?, a list of supported
properties will be printed (instead of an error message).
This is useful for command lines like
qemu -device e1000,?
and was already standard for other options like model=?
Signed-off-by:
Markus Armbruster arm...@redhat.com writes:
Stefan Weil w...@mail.berlios.de writes:
When called with property ?, a list of supported
properties will be printed (instead of an error message).
This is useful for command lines like
qemu -device e1000,?
and was already standard for
Stefan Weil w...@mail.berlios.de writes:
Markus Armbruster schrieb:
Stefan Weil w...@mail.berlios.de writes:
Markus Armbruster schrieb:
[...]
While there, would you mind improving --help for -device a bit? It's
too terse, and it doesn't start the help text in column 16 like the
other
Måns Rullgård wrote:
If IFS is not set, the shell shall behave as if the value of IFS is
space, tab, and newline
If you make that IFS=${local_ifs:-$(printf ' \t\n')} it should be safe.
Likewise if you set the value first.
Remove the colon. The above will wrongly change empty IFS, which
On Thu, Jan 21, 2010 at 1:52 PM, Luiz Capitulino lcapitul...@redhat.com wrote:
On Wed, 20 Jan 2010 19:22:48 +
Blue Swirl blauwir...@gmail.com wrote:
On Wed, Jan 20, 2010 at 6:11 PM, Luiz Capitulino lcapitul...@redhat.com
wrote:
On Wed, 20 Jan 2010 18:57:56 +0100
Markus Armbruster
On Thu, Jan 21, 2010 at 2:39 PM, Andre Przywara andre.przyw...@amd.com wrote:
john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu name' are just as
unfriendly as each other. The only user friendly
On 01/21/10 17:44, Markus Armbruster wrote:
Markus Armbrusterarm...@redhat.com writes:
-fprintf(stderr, property \%s.%s\ not found\n,
-dev-info-name, name);
+fprintf(stderr, %s.%s\n, dev-info-name, props-name);
+props++;
malc av1...@comtv.ru writes:
On Tue, 29 Dec 2009, Jamie Lokier wrote:
malc wrote:
On Mon, 28 Dec 2009, Jamie Lokier wrote:
Aurelien Jarno wrote:
This fixes the loading of a stripped kernel with zero malloc disabled.
*Raises an eyebrow*
Even though there's different
john cooper wrote:
kvm itself can modify flags exported from qemu to a guest.
I would hope for an option to request that qemu doesn't run if the
guest won't get the cpuid flags requested on the command line.
-- Jamie
john cooper wrote:
I foresee wanting to iterate over the models and pick the latest one
which a host supports - on the grounds that you have done the hard
work of ensuring it is a reasonably good performer, while probably
working on another host of similar capability when a new host is
On 21 janv. 2010, at 16:24, Liran Schour wrote:
Move to stage3 only when remaining work can be done below max downtime.
Changes from v1: remove max iterations. Try to infer storage performance and
by that calculate remaining work.
Signed-off-by: Liran Schour lir...@il.ibm.com
---
On Thu, 21 Jan 2010, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Tue, 29 Dec 2009, Jamie Lokier wrote:
malc wrote:
On Mon, 28 Dec 2009, Jamie Lokier wrote:
Aurelien Jarno wrote:
This fixes the loading of a stripped kernel with zero malloc
disabled.
john cooper wrote:
I can appreciate the argument above, however the goal was
choosing names with some basis in reality. These were
recommended by our contacts within Intel, are used by VmWare
to describe their similar cpu models, and arguably have fallen
to defacto usage as evidenced by such
identifier scorpio schrieb:
Thank Mr. Weil for your reply.
Maybe you can also try the TCG interpreter (TCI) from
http://repo.or.cz/w/qemu/ar7.git.
In theory, it supports any host architecture with or
without native TCG
support.
It was tested successful with some basic tests on
Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Tue, 29 Dec 2009, Jamie Lokier wrote:
malc wrote:
On Mon, 28 Dec 2009, Jamie Lokier wrote:
Aurelien Jarno wrote:
This fixes the loading of a stripped kernel with zero malloc
disabled.
*Raises an
On Thu, 21 Jan 2010, Jamie Lokier wrote:
Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Tue, 29 Dec 2009, Jamie Lokier wrote:
malc wrote:
On Mon, 28 Dec 2009, Jamie Lokier wrote:
Aurelien Jarno wrote:
This fixes the loading of a stripped kernel with
Jamie Lokier wrote:
Do you mean that more powerful management tools to support safe
migration will maintain _their own_ processor model tables, and
perform their calculations using their own tables instead of querying
qemu, and therefore not have any need of qemu's built in table?
I would
Jamie Lokier wrote:
I think we can all agree that there is no point looking for a familiar
-cpu naming scheme because there aren't any familiar and meaningful names
these days.
Even if we dismiss the Intel coined names as internal
code names, there is still VMW's use of them in this
space
Jamie Lokier ja...@shareable.org writes:
Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Tue, 29 Dec 2009, Jamie Lokier wrote:
malc wrote:
On Mon, 28 Dec 2009, Jamie Lokier wrote:
Aurelien Jarno wrote:
This fixes the loading of a stripped kernel with zero malloc
malc av1...@comtv.ru writes:
On Thu, 21 Jan 2010, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Tue, 29 Dec 2009, Jamie Lokier wrote:
malc wrote:
On Mon, 28 Dec 2009, Jamie Lokier wrote:
Aurelien Jarno wrote:
This fixes the loading of a stripped kernel with
A new option, -nodefconfig is introduced to prevent loading from the default
config location. Otherwise, two configuration files will be searched for,
qemu.conf and target-TARGET_NAME.conf.
The ordering is a little troubling. Command line options are parsed before
loading the default configs
This series introduces global config files stored in /etc/qemu. There is both
a common config (qemu.conf) and a per-target config (target-TARGET_NAME.conf).
To demonstrate what can be done with global config, I've also made some
enhancements to the default device code that allows many of the
This option can be used to toggle whether each default device is enabled or
disabled. For character devices, the default backend can also be overridden.
For devices, we'll have to take a different approach to changing the defaults
which will be covered in the next patch.
N.B. I took special
Introduce a default option to the network device which specifies that this is
a default network device. This approach should generalize to any other device.
The meaning of a default device is as follows: a default device is added to a
machine IIF defaults aren't disable (via -default or
The default value is ${prefix}/etc/qemu. --confdir can be used to override the
default to an absolute path. The expectation is that when installed to /usr,
--confdir=/etc/qemu will be used.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
configure | 10 ++
1 files changed, 10
On 01/21/2010 10:43 AM, john cooper wrote:
Anthony Liguori wrote:
On 01/20/2010 07:18 PM, john cooper wrote:
I can appreciate the concern of wanting to get this
as correct as possible.
This is the root of the trouble. At the qemu layer, we try to focus on
being correct.
On Thu, 21 Jan 2010, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Thu, 21 Jan 2010, Markus Armbruster wrote:
[..snip..]
No, this is a misinterpretation of the C99 standard, made possible by
its poor wording. The C99 Rationale is perfectly clear, though:
You have to
On 01/21/2010 05:53 PM, Jamie Lokier wrote:
If you make that IFS=${local_ifs:-$(printf ' \t\n')} it should be safe.
Likewise if you set the value first.
Remove the colon. The above will wrongly change empty IFS, which
is not the same as unset IFS.
local_ifs would never be unset anyway,
Feature negotiation allows clients to enable QMP capabilities they are
interested in using. This allows QMP to envolve without breaking old clients.
A capability is a new QMP feature and/or protocol change which is not part of
the core protocol as defined in the QMP spec.
Feature negotiation
In order to support feature negotiation in QMP, the Monitor
has to be modified to support different modes of operation.
We need two modes:
o Handshake: where features are negotiated. Only commands
which deal with protocol configuration are allowed, async
messages (as any other protocol
Only valid in QMP and allowed to run in both handshake and
operational modes.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 42 ++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/monitor.c b/monitor.c
index
Two new errors:
- QERR_QMP_INVALID_MODE_NAME
- QERR_QMP_INVALID_MODE_TRANSACTION
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
qerror.c |8
qerror.h |6 ++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 5f8fc5d..9dd729a
It will be used to switch between handshake and operational
modes. Currently it doesn't have any practical effect, as
mode-oriented support is not enforced yet.
Usage example:
{ execute: qmp_switch_mode, arguments: { mode: operational } }
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
With feature negotiation support asynchronous messages are
going to behave like any protocol capability, that is, it
is disabled by default, it can be negotiated and has to be
advertised.
TODO: update spec.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 18
This commit moves the asynchronous messages names to an array
of structs, so that it can be indexed and searched.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 67 +++--
1 files changed, 34 insertions(+), 33
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 9dd729a..12dcc8f 100644
--- a/qerror.c
+++ b/qerror.c
@@ -41,6 +41,10 @@ static const QType qerror_type = {
This commit disables asynchronous messages by default and
introduces two new QMP commands: async_msg_enable and
async_msg_disable.
Each QMP Monitor has its own set of asynchronous messages,
so for example, if QEMU is run with two QMP Monitors async
messages setup in one of them doesn't affect the
Move the code used to locate an info command entry to its
own function, as it's going to be used by other functions.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/monitor.c
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 12dcc8f..526 100644
--- a/qerror.c
+++ b/qerror.c
@@ -109,6 +109,10 @@ static const QErrorStringTable
This is done by enforcing the following mode-oriented rules:
- QMP is started in handshake mode
- In handshake mode all protocol capabilities are disabled
and (apart of a few exceptions) only commands which
query/enable/disable them are allowed
- Asynchronous messages are now considered a
Hi,
This new version fixes the printing of PCI bridge information,
as I was able to test it after some help from Blue Swirl.
Only the printing of PCI bridge attached devices remains
untested, but according to Blue Swirl attaching devices to it
is broken so I don't think it matters much.
Iterate over QList entries, it's needed to call qlist_entry_obj()
to retrieve the stored QObject.
I'm not sure if it's ok to have this, because it's not as easy as
qlist_iter() and the QListEntry data type is now exposed to the
users, which means we have one more struct to be maintained when
we
A helper to retrieve a QDict from a QDict.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
qdict.c | 13 +
qdict.h |1 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/qdict.c b/qdict.c
index ba8eef0..c6a5a42 100644
--- a/qdict.c
+++ b/qdict.c
@@
The returned QObject is a QList of all buses. Each bus is
represented by a QDict, which has a key with a QList of all
PCI devices attached to it. Each device is represented by
a QDict.
As has happended to other complex conversions, it's hard to
split this commit as part of it are new functions
This commit completes the do_pci_info() conversion to
QObject by adding support to PCI bridge devices.
This is done by recursively adding devices in the
pci_bridge key.
IMPORTANT: This code is being added separately because I could
NOT test it properly. According to Michael Tsirkin, it depends
Aborting without an error message when memory is short
is not helpful, so print the reason for the abort.
Try
qemu -m 100
or
qemu -m 2000 (win32)
to force an out-of-memory error.
v2:
* Fix error message for win32.
* Fix error message for posix_memalign.
Thanks to malc for
Markus Armbruster wrote:
I didn't claim there's *no* difference between C89 and C99. In fact,
the Rationale nicely documents the change:
[snipped]
Also, implementations that support an
actual allocation when the size is zero do not necessarily return a
null pointer for
84 matches
Mail list logo
