Now an admin comes along with with libguestfs and attempts to access
the disk containing the GFS volume. libguestfs isn't part of the
cluster but that doesn't matter because you can happily access a GFS
filesystem in standalone mode provided it is not in use by any other
nodes.
We need to stop
Michael S. Tsirkin wrote:
I hope this also includes the -global patches currently in staging as
well?
There's nothing in staging.
But yes, the -global bits are part of Gerd's default devices series.
Regards,
Anthony Liguori
On 12/07/09 15:07, Alexander Graf wrote:
On 07.12.2009, at 14:27, Gerd Hoffmann wrote:
Default variables belong in the machine description IMHO. On
S390, we can't create serial, parallel or vga (or any MMIO/PIO
requiring) devices.
See last patch of this series. Moving that into the machine
On 12/07/2009 02:39 PM, Anthony Liguori wrote:
That's a use-case that needs to be thought through. Maybe commit should
attempt to force the lower level to acquire a write lock first?
Yes. This is an argument in favor of a DWIM lock option instead of
giving shared/exclusive choice to the
malc av1...@comtv.ru writes:
On Mon, 30 Nov 2009, Markus Armbruster wrote:
Commit a7d27b53 made zero-sized allocations a fatal error, deviating
from ISO C's malloc() friends. Revert that, but take care never to
return a null pointer, like malloc() friends may do (it's
implementation
On Mon, Dec 07, 2009 at 03:30:09PM +0100, Gerd Hoffmann wrote:
On 12/07/09 15:13, Michael S. Tsirkin wrote:
Gerd, any idea whether one MSI-X vector feature is worth pursuing?
I'd rate it low priority. First because virtio-enabled guests can use
virtio-net+blk. Also because with the
Avi Kivity wrote:
On 12/06/2009 04:51 PM, Jan Kiszka wrote:
KVM_GET_MSR_INDEX_LIST returns -E2BIG when the provided space is too
small for all MSRs. But this is precisely the error we trigger with the
initial request in order to obtain that size. Do not fail in that case.
This caused a subtle
On Mon, Dec 07, 2009 at 08:36:07AM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
I hope this also includes the -global patches currently in staging as
well?
There's nothing in staging.
There isn't?
I fetched:
git://repo.or.cz/qemu/aliguori-queue.git master
and I see:
git log
Jan Kiszka wrote:
And now it happened again (qemu-kvm head, during kernel installation
from network onto local qcow2-disk). Any clever idea how to proceed with
this?
I could try to run the step in a loop, hopefully retriggering it once in
a (likely longer) while. But then we need some good
i.e. -global PCI.property=value will set a default property for all
PCi devices. Also works for the compat properties used by machine
types.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/qdev-properties.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
Daniel P. Berrange wrote:
It is safe if you assume that no one else has tried to modify the disk
since you opened it, otherwise you'd be commiting changes against a
base state which no longer exists.
1) first user opens cow1.qcow, acquires F_WRLCK
2) first user opens base.qcow, acquires
On 12/07/09 15:13, Michael S. Tsirkin wrote:
Gerd, any idea whether one MSI-X vector feature is worth pursuing?
I'd rate it low priority. First because virtio-enabled guests can use
virtio-net+blk. Also because with the upcoming p35 support we'll get a
more modern pc emulation including a
Richard W.M. Jones wrote:
So to be clear, the use case is that all the other VMs must be shut
down, then the VM which wants to commit will upgrade its lock and
commit, and then all the other VMs will restart? I agree this should
avoid corruption, although it sounds like something which is
Michael S. Tsirkin wrote:
On Mon, Dec 07, 2009 at 08:36:07AM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
I hope this also includes the -global patches currently in staging as
well?
There's nothing in staging.
There isn't?
s/staging/my local staging/
Daniel P. Berrange berra...@redhat.com writes:
The only other alternative would be for the destination to open the disks,
but not immediately acquire the locks. In the final stage of migration have
the source release its lock signal to the dest that it can now acquire
the lock. The
On Mon, 7 Dec 2009 13:42:49 +0100
Gerd Hoffmann kra...@redhat.com wrote:
+static int mon_init_func(QemuOpts *opts, void *opaque)
+{
+CharDriverState *chr;
+const char *chardev;
+const char *mode;
+int flags;
+
+qemu_opts_print(opts, NULL);
+
+mode =
Am 07.12.2009 15:16, schrieb Jan Kiszka:
Likely not. What I did was nothing special, and I did not noticed such a
crash in the last months.
And now it happened again (qemu-kvm head, during kernel installation
from network onto local qcow2-disk). Any clever idea how to proceed with
this?
I
On 12/07/2009 04:50 PM, Jan Kiszka wrote:
Maybe I'm seeing ghosts, and I don't even have a minimal clue about what
goes on in the code, but this looks fishy:
Plenty of ghosts in qcow2, of all those explorers who tried to brave the
code. Only Kevin has ever come back.
preallocate()
Am 07.12.2009 15:50, schrieb Jan Kiszka:
Jan Kiszka wrote:
And now it happened again (qemu-kvm head, during kernel installation
from network onto local qcow2-disk). Any clever idea how to proceed with
this?
I could try to run the step in a loop, hopefully retriggering it once in
a (likely
On Monday 07 December 2009, Artyom Tarasenko wrote:
Can it be that qemu (-system-sparc in my case, but I guess it's more
or less similar on all platforms) reacts to irqs slower than a real
hardware due to tcg optimizations?
Interrupts generally only trigger at branch instructions, or similar.
On 07.12.2009, at 15:39, Gerd Hoffmann wrote:
On 12/07/09 15:07, Alexander Graf wrote:
On 07.12.2009, at 14:27, Gerd Hoffmann wrote:
Default variables belong in the machine description IMHO. On
S390, we can't create serial, parallel or vga (or any MMIO/PIO
requiring) devices.
See
On 12/07/09 15:59, Luiz Capitulino wrote:
+chardev = qemu_opt_get(opts, chardev);
+chr = qemu_chr_find(chardev);
+if (chardev == NULL) {
+fprintf(stderr, chardev \%s\ not found\n, chardev);
+exit(1);
+}
We should check for NULL before calling qemu_chr_find().
Kevin Wolf wrote:
Am 07.12.2009 15:50, schrieb Jan Kiszka:
Jan Kiszka wrote:
And now it happened again (qemu-kvm head, during kernel installation
from network onto local qcow2-disk). Any clever idea how to proceed with
this?
I could try to run the step in a loop, hopefully retriggering it
Markus Armbruster wrote:
Commit a7d27b53 made zero-sized allocations a fatal error, deviating
from ISO C's malloc() friends. Revert that, but take care never to
return a null pointer, like malloc() friends may do (it's
implementation defined), because that's another source of bugs.
While
On 12/07/2009 05:50 PM, Anthony Liguori wrote:
While it's always fun to argue about standards interpretation, I
wanted to capture some action items from the discussion that I think
there is agreement about. Since I want to make changes for 0.12, I
think it would be best to try and settle
On 12/07/09 16:12, Alexander Graf wrote:
Well I was basically thinking of moving default_list inside the
machine description. That way you can easily choose what default
devices there are available.
Doesn't make sense. The list is not about *creating* default devices,
but about *not*
Avi Kivity wrote:
On 12/07/2009 05:50 PM, Anthony Liguori wrote:
While it's always fun to argue about standards interpretation, I
wanted to capture some action items from the discussion that I think
there is agreement about. Since I want to make changes for 0.12, I
think it would be best
Kevin Wolf wrote:
Am 07.12.2009 15:16, schrieb Jan Kiszka:
Likely not. What I did was nothing special, and I did not noticed such a
crash in the last months.
And now it happened again (qemu-kvm head, during kernel installation
from network onto local qcow2-disk). Any clever idea how to
On 07.12.2009, at 17:05, Gerd Hoffmann wrote:
On 12/07/09 16:12, Alexander Graf wrote:
Well I was basically thinking of moving default_list inside the
machine description. That way you can easily choose what default
devices there are available.
Doesn't make sense. The list is not about
On 12/07/2009 06:06 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 12/07/2009 05:50 PM, Anthony Liguori wrote:
While it's always fun to argue about standards interpretation, I
wanted to capture some action items from the discussion that I think
there is agreement about. Since I want to
Avi Kivity wrote:
Covering every qemu_malloc instance this close to the GA is too
risky. I agree that having separate behavior is less than ideal but
I think it's the only sane way forward.
I don't understand why. What's so insane about Markus' patch?
Allowing size=0 for both developer
type *qemu_new(type, n_types);
type *qemu_new0(type, n_types);
type *qemu_renew(type, mem, n_types);
type *qemu_renew0(type, mem, n_types);
It always annoys me having to specify element count for things that aren't
arrays.
I suggestion a single object allocation function, and an array
On 12/07/2009 06:20 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Covering every qemu_malloc instance this close to the GA is too
risky. I agree that having separate behavior is less than ideal but
I think it's the only sane way forward.
I don't understand why. What's so insane about
Paul Brook wrote:
type *qemu_new(type, n_types);
type *qemu_new0(type, n_types);
type *qemu_renew(type, mem, n_types);
type *qemu_renew0(type, mem, n_types);
It always annoys me having to specify element count for things that aren't
arrays.
I suggestion a single object allocation
Am 07.12.2009 17:09, schrieb Jan Kiszka:
Kevin Wolf wrote:
In qcow_aio_write_cb there isn't much happening between these calls. The
only thing that could somehow become dangerous is the
qcow_aio_write_cb(req, 0); for queued requests in run_dependent_requests.
If m-nb_clusters is not, the
On 12/07/2009 06:24 PM, Paul Brook wrote:
Note that conversion to object/type based allocation is not always
straightforward because inheritance means we don't have the final object type
when doing the allocation.
Instead of specifying the size, we can specify a constructor function
(we
On 12/07/2009 04:47 PM, Anthony Liguori wrote:
Don't know when 0.11.2 will happen but I'll also push it to the
stable-0.11 branch.
I think this is worthy of a 0.11.2 all by itself.
--
error compiling committee.c: too many arguments to function
Avi Kivity wrote:
On 12/07/2009 06:20 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Covering every qemu_malloc instance this close to the GA is too
risky. I agree that having separate behavior is less than ideal
but I think it's the only sane way forward.
I don't understand why. What's
Avi Kivity wrote:
On 12/07/2009 04:47 PM, Anthony Liguori wrote:
Don't know when 0.11.2 will happen but I'll also push it to the
stable-0.11 branch.
I think this is worthy of a 0.11.2 all by itself.
Understood. I'll see what I can do today.
--
Regards,
Anthony Liguori
On 12/07/2009 06:32 PM, Anthony Liguori wrote:
If we apply the patch, the callers are no longer incorrect. Since
we're winding down development on that tree, I see no reason for the
production build to be correct and the development tree to be incorrect.
The problem with this whole
On Mon, 7 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Mon, 30 Nov 2009, Markus Armbruster wrote:
Commit a7d27b53 made zero-sized allocations a fatal error, deviating
from ISO C's malloc() friends. Revert that, but take care never to
return a null pointer,
Avi Kivity wrote:
What about developers that hit the assert? Do they send patches that
fix code that works in production just so they can run in developer mode?
Sounds like a good way to get developers to help convert from
qemu_malloc() to qemu_new*() :-)
If it helps, we can do a grep -l
malc wrote:
Does anyone object to this moving forward?
Yeah, i object to the split production/development qemu_malloc[z].
It's clear to me that there are still improper callers of qemu_malloc()
in the tree. How do you propose we address this for 0.12?
Aborting in a production
On 12/07/2009 06:59 PM, Anthony Liguori wrote:
Avi Kivity wrote:
What about developers that hit the assert? Do they send patches that
fix code that works in production just so they can run in developer
mode?
Sounds like a good way to get developers to help convert from
qemu_malloc() to
Avi Kivity wrote:
On 12/07/2009 06:59 PM, Anthony Liguori wrote:
Avi Kivity wrote:
What about developers that hit the assert? Do they send patches
that fix code that works in production just so they can run in
developer mode?
Sounds like a good way to get developers to help convert from
On 12/07/2009 07:09 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 12/07/2009 06:59 PM, Anthony Liguori wrote:
Avi Kivity wrote:
What about developers that hit the assert? Do they send patches
that fix code that works in production just so they can run in
developer mode?
Sounds like a
Avi Kivity wrote:
I don't understand. People will develop patches for 0.12 for a while
as bugs are reported and fixed.
What's the exact problem here?
Regards,
Anthony Liguori
Michael S. Tsirkin wrote:
OK, I got the Run make defconfig message again.
I think it used to be re-run automatically: why
are we asking the user to do it manually now?
It's buggy. defconfig should only be needed when a new config option is
added and the old config doesn't contain it yet.
On 12/07/2009 07:17 PM, Anthony Liguori wrote:
Avi Kivity wrote:
I don't understand. People will develop patches for 0.12 for a while
as bugs are reported and fixed.
What's the exact problem here?
Bug reported against qemu. Developer develops patch, while testing qemu
crashes on
So the only correct way would be to write:
array = malloc(size);
if (array == NULL size != 0) {
return -ENOMEM;
}
Of course we can differentiate. A failed malloc will abort, a successful one
will not.
If you were writing portable code. But that's not what people write. You
can
2009/12/7 Paul Brook p...@codesourcery.com:
On Monday 07 December 2009, Artyom Tarasenko wrote:
Can it be that qemu (-system-sparc in my case, but I guess it's more
or less similar on all platforms) reacts to irqs slower than a real
hardware due to tcg optimizations?
Interrupts generally
Avi Kivity wrote:
On 12/07/2009 07:17 PM, Anthony Liguori wrote:
Avi Kivity wrote:
I don't understand. People will develop patches for 0.12 for a
while as bugs are reported and fixed.
What's the exact problem here?
Bug reported against qemu. Developer develops patch, while testing
qemu
Using -icount should give you precise interrupt delivery.
That's what I thought, but as I reported a few days ago, I couldn't
find a good value for icount when using OBP.
I tried a few values but keep getting qemu: fatal: Raised interrupt
while not in I/O function.
That's almost certainly
On Mon, Dec 7, 2009 at 3:30 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
Can it be that qemu (-system-sparc in my case, but I guess it's more
or less similar on all platforms) reacts to irqs slower than a real
hardware due to tcg optimizations?
I see one test pattern which fails on
On Mon, Dec 7, 2009 at 5:50 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Markus Armbruster wrote:
Commit a7d27b53 made zero-sized allocations a fatal error, deviating
from ISO C's malloc() friends. Revert that, but take care never to
return a null pointer, like malloc() friends may do
On 12/07/2009 07:40 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 12/07/2009 07:17 PM, Anthony Liguori wrote:
Avi Kivity wrote:
I don't understand. People will develop patches for 0.12 for a
while as bugs are reported and fixed.
What's the exact problem here?
Bug reported against
On Sun, Dec 06, 2009 at 04:43:03PM -0600, Anthony Liguori wrote:
It can be downloaded from Savannah at:
http://download.savannah.gnu.org/releases/qemu/qemu-0.12.0-rc1.tar.gz
Please send testing feedback (positive or negative) to qemu-devel and
file bugs against the release candidate at:
Avi Kivity wrote:
My problem is with stable-0.12. Consider upstream fixed.
1) Bug reported against qemu-0.12.0.
2) Developer writes patch against master, submits, all is well except
for the CODING_STYLE argument it triggers.
3) Developer writes patch against stable-0.12, can't test because
On 12/07/2009 08:59 PM, Anthony Liguori wrote:
Avi Kivity wrote:
My problem is with stable-0.12. Consider upstream fixed.
1) Bug reported against qemu-0.12.0.
2) Developer writes patch against master, submits, all is well except
for the CODING_STYLE argument it triggers.
3) Developer writes
Avi Kivity wrote:
On 12/07/2009 08:59 PM, Anthony Liguori wrote:
Avi Kivity wrote:
My problem is with stable-0.12. Consider upstream fixed.
1) Bug reported against qemu-0.12.0.
2) Developer writes patch against master, submits, all is well
except for the CODING_STYLE argument it triggers.
Instruct make to remove any rule target on error. This prevetns
situation where there was an error during build but generated file still
stays behind.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
rules.mak |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git
Gerd Hoffmann wrote:
This patch reworks the -monitor handling:
- It adds a new mon QemuOpts list for the monitor(s).
- It adds a monitor_parse() function to parse the -monitor switch.
- It adds a mon_init function to initialize the monitor(s) from the
mon QemuOpts list.
- It winds up
On Mon, Dec 07, 2009 at 11:19:26AM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
OK, I got the Run make defconfig message again.
I think it used to be re-run automatically: why
are we asking the user to do it manually now?
It's buggy. defconfig should only be needed when a new
Luiz Capitulino wrote:
Return a QString with status information.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 33 +++--
1 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/monitor.c b/monitor.c
index 8cedfa9..03f5d7a 100644
---
Luiz Capitulino wrote:
Return a QString with kvm status information.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 31 +--
1 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/monitor.c b/monitor.c
index 03f5d7a..d3ab2ab 100644
Luiz Capitulino wrote:
Return a QDict, which may contain more two QDicts, depending on
the type of migration we're performing.
IMPORTANT: as a QInt stores a int64_t integer, RAM values are going
to be stored as int64_t and not as uint64_t as they are today. If
this is a problem QInt will have
Luiz Capitulino wrote:
New monitor commands should always return values in bytes.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index 5bf32f0..8cedfa9 100644
---
Daniel P. Berrange wrote:
On Sun, Dec 06, 2009 at 04:43:03PM -0600, Anthony Liguori wrote:
It can be downloaded from Savannah at:
http://download.savannah.gnu.org/releases/qemu/qemu-0.12.0-rc1.tar.gz
Please send testing feedback (positive or negative) to qemu-devel and
file bugs against
Anthony, two patchsets with pci compliance fixes are now on my pci
tree. They fix WHQL errors. We should also consider them for 0.12.
I think that msi function mask fix is definitely safe for that,
interrupt status fixes might be slightly more risky as they affect
all devices.
The following
On Mon, Dec 07, 2009 at 01:43:01PM -0600, Anthony Liguori wrote:
Daniel P. Berrange wrote:
On Sun, Dec 06, 2009 at 04:43:03PM -0600, Anthony Liguori wrote:
It can be downloaded from Savannah at:
http://download.savannah.gnu.org/releases/qemu/qemu-0.12.0-rc1.tar.gz
Please send testing
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index aa89a3d..8ffe4f6 100644
--- a/qerror.c
+++ b/qerror.c
@@ -109,6 +109,10 @@ static const QErrorStringTable
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 17532b0..56083c4 100644
--- a/qerror.c
+++ b/qerror.c
@@ -65,6 +65,10 @@ static const QErrorStringTable
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 128a91e..d75c69a 100644
--- a/qerror.c
+++ b/qerror.c
@@ -65,6 +65,10 @@ static const QErrorStringTable
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 1bb68c4..128a91e 100644
--- a/qerror.c
+++ b/qerror.c
@@ -100,6 +100,10 @@ static const QErrorStringTable
Signed-off-by: Markus Armbruster arm...@redhat.com
---
QMP/qmp-spec.txt |5 -
monitor.c|1 +
qerror.c | 21 -
qerror.h |2 ++
4 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/QMP/qmp-spec.txt b/QMP/qmp-spec.txt
index
Signed-off-by: Markus Armbruster arm...@redhat.com
---
monitor.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/monitor.c b/monitor.c
index 05233cc..c35a31e 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2195,8 +2195,7 @@ static void do_closefd(Monitor *mon, const QDict
Also fix the odd typoe and clean up whitespace.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c | 28 ++--
qerror.h | 30 +++---
2 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/qerror.c b/qerror.c
index
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index d75c69a..e6b7f62 100644
--- a/qerror.c
+++ b/qerror.c
@@ -69,6 +69,10 @@ static const QErrorStringTable
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 56083c4..1bb68c4 100644
--- a/qerror.c
+++ b/qerror.c
@@ -93,6 +93,10 @@ static const QErrorStringTable
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 37e8072..17532b0 100644
--- a/qerror.c
+++ b/qerror.c
@@ -61,6 +61,10 @@ static const QErrorStringTable
From: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 03e3b34..37e8072 100644
--- a/qerror.c
+++ b/qerror.c
@@ -49,6 +49,10 @@ static const QErrorStringTable
Signed-off-by: Markus Armbruster arm...@redhat.com
---
monitor.c | 19 +++
qemu-monitor.hx |3 ++-
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/monitor.c b/monitor.c
index 62d2ef5..05233cc 100644
--- a/monitor.c
+++ b/monitor.c
@@ -830,13 +830,13 @@
Also affects do_change(), because the two share eject_device().
Signed-off-by: Markus Armbruster arm...@redhat.com
---
monitor.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index b9d3d92..62d2ef5 100644
--- a/monitor.c
+++ b/monitor.c
@@
Signed-off-by: Markus Armbruster arm...@redhat.com
---
monitor.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index 50c616d..b9d3d92 100644
--- a/monitor.c
+++ b/monitor.c
@@ -845,12 +845,17 @@ static void do_change_block(Monitor *mon,
This patch series converts monitor commands eject, change, closefd,
getfd to QError.
There's a simple bonus fix in PATCH 3.
Finally, PATCH 18 puts a human-readable error description into the QMP
error response. For background, see the lengthy thread ending at
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index e6b7f62..aa89a3d 100644
--- a/qerror.c
+++ b/qerror.c
@@ -77,6 +77,10 @@ static const QErrorStringTable
Signed-off-by: Markus Armbruster arm...@redhat.com
---
monitor.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
index c35a31e..0bcffbe 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2145,19 +2145,21 @@ static void do_getfd(Monitor *mon, const
SCSI controllers have no trouble existing without any attached
disks. This could be achieved with the (legacy) monitor syntax
pci_add pci_addr=auto storage if=scsi
This is now denied with
scsi requires a backing file/device.
failed to add if=scsi
There is no need for this denial and it
Daniel P. Berrange wrote:
SCSI controllers have no trouble existing without any attached
disks. This could be achieved with the (legacy) monitor syntax
pci_add pci_addr=auto storage if=scsi
This is now denied with
scsi requires a backing file/device.
failed to add if=scsi
There is no
On Sun, Dec 06, 2009 at 03:44:59PM +, Blue Swirl wrote:
On Sun, Dec 6, 2009 at 11:59 AM, Aurelien Jarno aurel...@aurel32.net wrote:
On Sat, Dec 05, 2009 at 08:07:13PM +, Blue Swirl wrote:
On Sat, Dec 5, 2009 at 8:05 PM, Aurelien Jarno aurel...@aurel32.net
wrote:
On Thu, Dec 03,
Any pointers for setting up an arm xip image under Qemu? I'm hoping to use
Qemu to emulate some memory constrained devices.
Thanks,
bavery
Hi, everybody,
I am a newbie to QEMU and have been reading the QEMU code for nearly one
month. I got a picture of how QEMU works, but still cannot figure out how
KQEMU works together with QEMU. Could you give me some clues to the
following questions?
1) The interrupts in QEMU are driven
I got this error while compiling qemu
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/FSEvents.h:28,
from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:218,
On Thu, 3 Dec 2009 08:28:38 pm Avi Kivity wrote:
On 12/03/2009 10:42 AM, Avishay Traeger1 wrote:
I previously submitted a patch to have the guest virtio-blk driver get the
value for the maximum I/O size from the host bdrv, rather than assume that
there is no limit. Avi requested that I
101 - 195 of 195 matches
Mail list logo
