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 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
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 by
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
On Sun, Dec 06, 2009 at 03:44:59PM +, Blue Swirl wrote:
> On Sun, Dec 6, 2009 at 11:59 AM, Aurelien Jarno wrote:
> > On Sat, Dec 05, 2009 at 08:07:13PM +, Blue Swirl wrote:
> >> On Sat, Dec 5, 2009 at 8:05 PM, Aurelien Jarno
> >> wrote:
> >> > On Thu, Dec 03, 2009 at 10:03:18PM +0200, Bl
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 ne
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 br
Signed-off-by: Markus Armbruster
---
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 QDict *qdict,
QOb
From: Luiz Capitulino
The do_cont() function will ask the user to enter a password if a
device is encrypted.
This is invalid under QMP, so we raise a QERR_DEVICE_ENCRYPTED
error.
Signed-off-by: Luiz Capitulino
Signed-off-by: Markus Armbruster
---
monitor.c | 10 +-
1 files changed,
Signed-off-by: Markus Armbruster
---
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 qerror_table[] = {
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
http://lists.gnu.org/archive/html/qe
Signed-off-by: Markus Armbruster
---
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, const char
*devic
Also affects do_change(), because the two share eject_device().
Signed-off-by: Markus Armbruster
---
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
@@ -778,11 +778,12 @@
Signed-off-by: Markus Armbruster
---
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 @@ static void do_ch
Signed-off-by: Markus Armbruster
---
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 qerror_table[] = {
From: Luiz Capitulino
Signed-off-by: Luiz Capitulino
Signed-off-by: Markus Armbruster
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index eb4ce33..d90529c 100644
--- a/qerror.c
+++ b/qerror.c
@@ -45,6 +45,10 @@
Signed-off-by: Markus Armbruster
---
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 qerror_table[] = {
Signed-off-by: Markus Armbruster
---
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 qerror_table[] = {
Signed-off-by: Markus Armbruster
---
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 qerror_table[] = {
Also fix the odd typoe and clean up whitespace.
Signed-off-by: Markus Armbruster
---
qerror.c | 28 ++--
qerror.h | 30 +++---
2 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/qerror.c b/qerror.c
index d90529c..03e3b34 100644
--
Signed-off-by: Markus Armbruster
---
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 *qdict,
QObject **
Signed-off-by: Markus Armbruster
---
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 8429789..1cbd21c 100
Signed-off-by: Markus Armbruster
---
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 qerror_table[] = {
Signed-off-by: Markus Armbruster
---
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 qerror_table[] = {
Signed-off-by: Markus Armbruster
---
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 qerror_table[] = {
Signed-off-by: Markus Armbruster
---
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 qerror_table[] = {
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
> >>
> >>P
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 change
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 th
Luiz Capitulino wrote:
New monitor commands should always return values in bytes.
Signed-off-by: Luiz Capitulino
---
monitor.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index 5bf32f0..8cedfa9 100644
--- a/monitor.c
+++ b/monitor.c
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 to
Luiz Capitulino wrote:
Return a QString with kvm status information.
Signed-off-by: Luiz Capitulino
---
monitor.c | 31 +--
1 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/monitor.c b/monitor.c
index 03f5d7a..d3ab2ab 100644
--- a/monitor.c
+++ b/mo
Luiz Capitulino wrote:
Return a QString with status information.
Signed-off-by: Luiz Capitulino
---
monitor.c | 33 +++--
1 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/monitor.c b/monitor.c
index 8cedfa9..03f5d7a 100644
--- a/monitor.c
+++ b/moni
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
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
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
---
rules.mak |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/rules.mak b/rules.mak
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.
3)
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 p
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
te
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 candida
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 qemu.
On Mon, Dec 7, 2009 at 5:50 PM, Anthony Liguori 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 (it's
>> im
On Mon, Dec 7, 2009 at 3:30 PM, 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?
>
> I see one test pattern which fails on qemu:
>
>
> nop * N
>
> > 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 c
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
2009/12/7 Paul Brook :
> 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
> 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
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 unrelate
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.
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
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 goo
On Mon, 7 Dec 2009, Anthony Liguori wrote:
> 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 d
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
qe
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 qemu
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 buil
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 th
On Mon, 7 Dec 2009, Anthony Liguori 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 (it's
> > implementatio
On Mon, 7 Dec 2009, Markus Armbruster wrote:
> malc 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, lik
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 discussio
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
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 so
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
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 us
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 no
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 funct
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 Marku
> 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
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 a
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 mak
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
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
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 to
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* creating
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 the
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.
Whil
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
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_fin
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) d
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
Richard W.M. Jones wrote:
Here's a second go at this patch. The only change is that we add a
second parameter (backinglock=none|shared|exclusive) which can be used
to control locking on the first level (only) of backing disk.
Dan Berrange convinced me there was a case to retain a distinct share
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
>>
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() in
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
> th
On Mon, 7 Dec 2009 13:42:49 +0100
Gerd Hoffmann 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 = qemu_opt_get(opts, "
"Daniel P. Berrange" 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 assumption being that
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/ :
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 fairly
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
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 F_RDLC
i.e. -global PCI.= will set a default property for all
PCi devices. Also works for the compat properties used by machine
types.
Signed-off-by: Gerd Hoffmann
---
hw/qdev-properties.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-propert
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
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:
gi
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 c
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
malc 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 defined)
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 u
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
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
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 li
On Mon, Dec 07, 2009 at 07:45:49AM -0600, Anthony Liguori wrote:
> Luiz Capitulino wrote:
>> On Sun, 06 Dec 2009 16:43:03 -0600
>> Anthony Liguori wrote:
>>
>>
>>> The QEMU team is pleased to announce the availability of the 0.12.0-rc1
>>> release. This is the first release candidate for the 0
1 - 100 of 202 matches
Mail list logo
