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 corruption of 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
Gerd Hoffmann wrote:
On 11/27/09 12:08, Gerd Hoffmann wrote:
On 11/26/09 16:50, Hannes Reinecke wrote:
So indeed, this approach would only work if we signal some sense code
back to the host.
I, OTOH, don't have any qualms with returning HARDWARE_ERROR,
0x26/0x08(TOO MANY SEGMENT DESCRIPTORS)
Am 06.12.2009 13:00, schrieb malc:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
[..snip..]
read(fd, malloc(0), 0) is just fine, because read() doesn't touch the
buffer when the
On 12/07/2009 10:24 AM, Jan Kiszka wrote:
I applied this to qemu-kvm since it missed 0.12-rc1.
OK, but this part is unused in qemu-kvm as we use our own (unaffected)
implementation there so far.
#include toldyouso.h
Will unapply.
--
error compiling committee.c: too many
Am 05.12.2009 18:27, schrieb Anthony Liguori:
If qemu_malloc() didn't carry the name malloc() then semantics with
size=0 would be a different discussion. But so far, all qemu_*
functions tend to behave almost exactly like their C counterparts.
Relying on the result of size=0 with malloc()
On 12/07/09 09:28, Hannes Reinecke wrote:
Hmm. Well. Seems to work out at least for linux, i.e. it figures it
got a bunch of sectors and tries to continue. Linux logs an I/O error.
Also I didn't try other guests (yet).
Using that as a way to limit scsi-disk request sizes probably isn't a
The culprit seems to be a soft lockup during shutdown because of the smp
code. Adding nosmp command line option to the guest kernel does not cause
this problem.
2009/10/30 Purna Chandar purnachandar.m...@oneconvergence.com
Can somebody out there please help me with this issue.
Thanks,
On Fri, Dec 04, 2009 at 02:50:49PM +0900, Isaku Yamahata wrote:
Split out apm register emulation for acpi.c into pc_apm.c.
The apm emulation will be used later.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
I don't know much about acpi.
One general comment below.
---
On Fri, Dec 04, 2009 at 08:09:35AM -0600, Anthony Liguori wrote:
Isaku Yamahata wrote:
This is the preparation patch for q35 chipset and PCIE support.
Anthony, any chance to merge? Can you please give me comments?
I'd like to see Michael review the PCI changes and Gerd review the pc
On 12/04/09 06:50, Isaku Yamahata wrote:
remove a global variable, RTCState *rtc_state.
Only the cmos_set_s3_resume_init() needs it global.
So introduce a registering function and make it local.
As for other function which references the variable, pass it
as a function argument.
Signed-off-by:
On 12/04/09 06:51, Isaku Yamahata wrote:
initialize ioapic before use.
This patch looks like it should be moved up in the series or merged into
another one to keep it fully bisectable.
I assume qemu broken with that one not applied?
cheers,
Gerd
Jamie Lokier wrote:
Ian Molton wrote:
Besides, not all entropy comes from /dev/random.
Those arguments are weak.
No worse than the counterarguments.
If nothing else, qemu is a useful tool for testing kernel subsystems and
in fact the virtio code triggered and caused to be fixed a number of
On Fri, Dec 04, 2009 at 11:15:12AM -0600, Anthony Liguori wrote:
Richard W.M. Jones wrote:
[from the commit message ...]
Allow qemu to acquire shared and exclusive locks on disk images.
This is done by extending the -drive option with an additional,
optional parameter:
-drive
Sorry, I missed this the first time this was posted, and I see this in
staging now. Gerd, could you please explain the motivation for this
patch?
I assumed console/baloon interrupts are not performance critical, so
would we not be better off using a shared interrupt for these,
reserving MSI
Jamie Lokier wrote:
If the system as a whole runs out of memory so that no-overcommit
malloc() fails on a small alloc, there's a good chance that you won't
be able to send a message to the host
Send what message to the host? If the malloc in the socet reconnect code
fails, its the code on the
On 12/05/09 01:20, Isaku Yamahata wrote:
On Fri, Dec 04, 2009 at 08:09:35AM -0600, Anthony Liguori wrote:
Isaku Yamahata wrote:
This is the preparation patch for q35 chipset and PCIE support.
Anthony, any chance to merge? Can you please give me comments?
I'd like to see Michael review the
malc av1...@comtv.ru writes:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
[..snip..]
read(fd, malloc(0), 0) is just fine, because read() doesn't touch the
buffer when
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 pretty annoying ...
Also:
$ make defconfig
GEN x86_64-softmmu/config-devices.mak
Ian Molton ian.mol...@collabora.co.uk writes:
Markus Armbruster wrote:
p = malloc(n * sizeof(struct foo);
if (n !p)
exit_no_mem();
for (i = 0; i n; i++)
compute_one(p, i);
With qemu_malloc(), the error handling moves into qemu_malloc():
p =
On 12/06/2009 08:41 PM, malc wrote:
Sure. My point is that sometimes failure to allocate is due to bugs,
invalid input etc, and conversion to OOM aborts en masse, might have
not been the best possible route to take, but most likely it was better
than doing nothing.
I agree. Early oom
On 12/07/2009 10:39 AM, Ian Molton wrote:
Send what message to the host? If the malloc in the socet reconnect code
fails, its the code on the host thats going to flag up that malloc failed.
He means to management code.
and if it does manage to receive the message, you can be almost
Jamie Lokier ja...@shareable.org writes:
Ian Molton wrote:
Read the beginning of the thread. Basically it's for arrays, malloc(n *
sizeof(x)).
well, make sure n is not 0. Its not that hard. I dont think I've *ever*
had a situation where I wanted to pass 0 to malloc.
I would like to
On Mon, 7 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
[..snip..]
read(fd, malloc(0), 0)
Am 07.12.2009 11:00, schrieb malc:
Misunderstanding? Such behavior is indeed permissible, and I can't see
where I restricted it away. An implementation that behaves as you
describe returns pointer to allocated space. That the pointer has
some funny bit set doesn't matter. That it can't be
Am 07.12.2009 10:47, schrieb Avi Kivity:
On 12/06/2009 08:41 PM, malc wrote:
Sure. My point is that sometimes failure to allocate is due to bugs,
invalid input etc, and conversion to OOM aborts en masse, might have
not been the best possible route to take, but most likely it was better
than
Anthony Liguori wrote:
I'm not sure whether it's best to enable it by default because, as I
said earlier, I'm not comfortable with the lack of correctness wrt
advisory vs. mandatory locking.
In my experience, disk images are accessed in one of five ways:
qemu-img
qemu
qemu-nbd
On 12/07/09 10:37, Michael S. Tsirkin wrote:
Sorry, I missed this the first time this was posted, and I see this in
staging now. Gerd, could you please explain the motivation for this
patch?
I assumed console/baloon interrupts are not performance critical, so
would we not be better off using a
malc av1...@comtv.ru writes:
On Mon, 7 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
[..snip..]
Hi. There's a connected discussion on the sheepdog list about locking, and I
have a patch there which could complement this one quite well.
Sheepdog is a distributed, replicated block store being developed
(primarily) for Qemu. Images have a mandatory exclusive locking requirement,
enforced by
Am 07.12.2009 11:31, schrieb Jamie Lokier:
So the distinction read/write makes more sense. Can anyone think of a
situation where a shared lock on an image opened for writing is useful?
I think there are people using shared writable images with cluster file
systems.
Kevin
On Mon, Dec 07, 2009 at 10:31:28AM +, Jamie Lokier wrote:
Anthony Liguori wrote:
I'm not sure whether it's best to enable it by default because, as I
said earlier, I'm not comfortable with the lack of correctness wrt
advisory vs. mandatory locking.
In my experience, disk images are
On 12/07/2009 12:42 PM, Kevin Wolf wrote:
I think there are people using shared writable images with cluster file
systems.
Hopefully not with qcow2.
--
error compiling committee.c: too many arguments to function
Am 07.12.2009 11:48, schrieb Avi Kivity:
On 12/07/2009 12:42 PM, Kevin Wolf wrote:
I think there are people using shared writable images with cluster file
systems.
Hopefully not with qcow2.
Right, it doesn't make sense with all of the image formats. But it does
with some of them
The multicore CPUID code detects whether the guest is an Intel or an
AMD CPU, because the Linux kernel is picky about the CmpLegacy bit.
KVM by default passes through the host's vendor, which was not
catched by the code. So fork out the vendor determining bits into a
separate function to be used
On Sat, Dec 05, 2009 at 11:47:11AM -0600, Anthony Liguori wrote:
I think I made my point poorly. Consider the following:
qemu-img create -f raw base.img 10G
qemu-img create -f qcow2 -b base.img cow1.img
qemu-img create -f qcow2 -b base.img cow2.img
qemu -drive file=cow1.img,lock=exclusive
On Mon, Dec 07, 2009 at 11:32:36AM +0100, Gerd Hoffmann wrote:
On 12/07/09 10:37, Michael S. Tsirkin wrote:
Sorry, I missed this the first time this was posted, and I see this in
staging now. Gerd, could you please explain the motivation for this
patch?
I assumed console/baloon interrupts
On Mon, Dec 07, 2009 at 10:31:28AM +, Jamie Lokier wrote:
Anthony Liguori wrote:
I'm not sure whether it's best to enable it by default because, as I
said earlier, I'm not comfortable with the lack of correctness wrt
advisory vs. mandatory locking.
In my experience, disk images are
The CPUID features QEMU presented to the guest were not up-to-date
with QEMU's emulated feature set.
Add the missing bits of recent (and not so recent) additions to
QEMU's emulation engine.
For stability reasons only the user mode usable bits are exposed for
now, features like Monitor or CR8LEG
Daniel P. Berrange wrote:
Sometimes shared access to a raw image (partitioned or whole disk
filesystem) is ok, and sometimes it is not ok. Only the user knows
the difference, because only the user knows if the guests they are
running use distinct partitions in the same raw image, or
On 12/07/09 11:59, Michael S. Tsirkin wrote:
The motivation was to move them away from the ioapic, to reduce irq
sharing of *other* devices which are connected to the ioapic too (i.e.
usb, e1000, lsi, ...)
Let's convert these to MSI instead?
This will likely pay off long term,
e.g. with nested
Kevin Wolf wrote:
Am 07.12.2009 11:31, schrieb Jamie Lokier:
So the distinction read/write makes more sense. Can anyone think of a
situation where a shared lock on an image opened for writing is useful?
I think there are people using shared writable images with cluster file
systems.
On Mon, Dec 07, 2009 at 11:19:54AM +, Jamie Lokier wrote:
Daniel P. Berrange wrote:
Sometimes shared access to a raw image (partitioned or whole disk
filesystem) is ok, and sometimes it is not ok. Only the user knows
the difference, because only the user knows if the guests they are
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), because that's another
On Mon, Dec 07, 2009 at 11:30:14AM +, Daniel P. Berrange wrote:
On Mon, Dec 07, 2009 at 11:19:54AM +, Jamie Lokier wrote:
Daniel P. Berrange wrote:
Sometimes shared access to a raw image (partitioned or whole disk
filesystem) is ok, and sometimes it is not ok. Only the user
Richard W.M. Jones wrote:
On Sat, Dec 05, 2009 at 11:47:11AM -0600, Anthony Liguori wrote:
I think I made my point poorly. Consider the following:
qemu-img create -f raw base.img 10G
qemu-img create -f qcow2 -b base.img cow1.img
qemu-img create -f qcow2 -b base.img cow2.img
qemu
Richard W.M. Jones wrote:
That doesn't work in the case of setting up a clustered filesystem
shared between guests. That requires that the disk be opened writable,
but with a shared (F_RDLOCK) lock.
I think Jamie's point is that you might as well use no locking at all
in this
On Mon, Dec 07, 2009 at 11:31:47AM +, Richard W.M. Jones wrote:
On Mon, Dec 07, 2009 at 11:30:14AM +, Daniel P. Berrange wrote:
On Mon, Dec 07, 2009 at 11:19:54AM +, Jamie Lokier wrote:
No, the question is whether it makes sense to provide a 'shared'
option on the command
Am 07.12.2009 12:28, schrieb Jamie Lokier:
Kevin Wolf wrote:
Am 07.12.2009 11:31, schrieb Jamie Lokier:
So the distinction read/write makes more sense. Can anyone think of a
situation where a shared lock on an image opened for writing is useful?
I think there are people using shared
On Mon, Dec 07, 2009 at 11:49:32AM +, Daniel P. Berrange wrote:
On Mon, Dec 07, 2009 at 11:31:47AM +, Richard W.M. Jones wrote:
On Mon, Dec 07, 2009 at 11:30:14AM +, Daniel P. Berrange wrote:
On Mon, Dec 07, 2009 at 11:19:54AM +, Jamie Lokier wrote:
No, the question
On Mon, Dec 07, 2009 at 11:28:34AM +, Jamie Lokier wrote:
Kevin Wolf wrote:
Am 07.12.2009 11:31, schrieb Jamie Lokier:
So the distinction read/write makes more sense. Can anyone think of a
situation where a shared lock on an image opened for writing is useful?
I think there are
Hi,
Qemu creates a bunch of default devices (serial, parallel, vga, ...) if
the user didn't specify one on the command line. Unfortunaly this
doesn't work well with the qdev way of doing things because this logic
is tied to the -serial, -parallel, ... command line switches. Devices
created
This reverts commit 93d434b4aec0702b87ebf52449a3cdf2c3596825.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
vl.c | 26 --
1 files changed, 0 insertions(+), 26 deletions(-)
diff --git a/vl.c b/vl.c
index 86171d0..74b608f 100644
--- a/vl.c
+++ b/vl.c
@@ -4710,20
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
console.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/console.c b/console.c
index 2aeb5b3..8086bd6 100644
--- a/console.c
+++ b/console.c
@@ -1388,8 +1388,10 @@ static void text_console_do_init(CharDriverState *chr,
Make the 'vc' chardev backend print a title line with the chardev name
after initialization, using CharDriverState-label.
This replaces the banner printing code in vl.c.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
console.c |8
vl.c | 24
2
This reverts commit adcb181afe5a951c521411c7a8e9d9b791aa6742.
Conflicts:
monitor.h
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
monitor.c | 18 --
monitor.h |1 -
qemu-options.hx |5 ++---
vl.c| 11 ---
4 files changed,
Add a default_net variable which specified whenever a default network
should be created. It is cleared in case any -net option is specified
and it is also added to the new -nodefaults switch.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
net.c |5 -
net.h |1 +
vl.c |1 +
Add a default_drive variable which specified whenever the default drives
(cdrom, floppy, sd) should be created. It is cleared when the new
-nodefaults switch is specified on the command line.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
vl.c | 16 ++--
1 files changed, 10
The logic in this code obviously predates the multiple monitor
capability of qemu and looks increasingly silly these days.
I think the intention of this piece of code is to get a reasonable
default for the -nographic case: have monitor and serial line muxed
on stdio.
With the new default_serial
Qemu creates a vga display for you in case you didn't specify one on the
command line. Right now this is tied to the '-vga type' command line
switch, which in turn causes trouble if you are creating your gfx card
using '-device VGA,props'.
This patch adds a variable default_vga which says
This patch makes the monitor default device configuration work like the
default serial and parallel port devices. It adds a variable
default_monitor which says whenever a default monitor should be added.
It is enabled by default. It is cleared when qemu finds '-monitor' on
the command line.
Add global command line option to disable default devices.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
qemu-options.hx |5 +
vl.c|6 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index b65fd74..70929fa
The patch decuples the -chardev switch and the actual chardev
initialization. Without this patch qemu ignores chardev entries
coming via -readconfig.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
vl.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git
Qemu creates a default parallel port for you in case you didn't specify
one on the command line. Right now this is tied to the '-parallel
chardev' command line switch, which in turn causes trouble if you are
creating your parallel port via '-device isa-parallel,props'.
This patch adds a variable
This patch adds a variable default_virtcon which says whenever a default
virtio console should be added. It is disabled by default, followup
patch will enable it for s390. It is cleared when qemu finds
'-virtiocon', '-device virtio-console-s390' or '-device
virtio-console-pci' on the command
This patch renames the compat properties into global properties and
makes them more generic. The compatibility stuff is only one of
multiple possible users now.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/boards.h |2 +-
hw/pc.c |2 +-
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
qemu-char.c |2 +-
qemu-char.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index da5c15c..c6008c3 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2231,7 +2231,7 @@ static CharDriverState
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 everything and removes the
All normal system emulation targets in qemu I'm aware of display
output on either VGA or serial output.
Our S390x virtio machine doesn't have such kind of legacy hardware. So
instead we need to default to a virtio console.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
vl.c | 11
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
qemu-options.hx |2 ++
vl.c| 14 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 7234447..b8cc375 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@
This patch adds infrastructure and command line option for setting
global defaults for device properties, i.e. you can for example use
-global virtio-blk-pci.vectors=0
to turn off msi by default for all virtio block devices. The config
file syntax is:
[global]
driver = virtio-blk-pci
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
qemu-options.hx |7 +++
vl.c|8
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index e05b2a0..7234447 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@
On Sun, 06 Dec 2009 16:43:03 -0600
Anthony Liguori aligu...@linux.vnet.ibm.com 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.12.0 release.
This release is not intended for production use.
Testing
On 07.12.2009, at 13:42, Gerd Hoffmann wrote:
Qemu creates a default serial line for you in case you didn't specify
one on the command line. Right now this is tied to the '-serial
chardev' command line switch, which in turn causes trouble if you are
creating your serial line via '-device
On 07.12.2009, at 13:42, Gerd Hoffmann wrote:
Qemu creates a default serial line for you in case you didn't specify
one on the command line. Right now this is tied to the '-serial
chardev' command line switch, which in turn causes trouble if you are
creating your serial line via '-device
On Mon, Dec 07, 2009 at 12:24:02PM +0100, Gerd Hoffmann wrote:
On 12/07/09 11:59, Michael S. Tsirkin wrote:
The motivation was to move them away from the ioapic, to reduce irq
sharing of *other* devices which are connected to the ioapic too (i.e.
usb, e1000, lsi, ...)
Let's convert these to
On 07.12.2009, at 13:42, Gerd Hoffmann wrote:
This patch adds a variable default_virtcon which says whenever a default
virtio console should be added. It is disabled by default, followup
patch will enable it for s390. It is cleared when qemu finds
'-virtiocon', '-device
On 12/07/09 14:03, Michael S. Tsirkin wrote:
Also - why not simply use virtio? I assume you are talking about
guests with virtio support otherwise MSI support in virtio
won't matter for them.
Point. Guests with virtio-console+balloon most likely can use virtio
for storage+net too, so nothing
On 12/07/09 13:52, Alexander Graf wrote:
diff --git a/vl.c b/vl.c index 24d5d92..eca4eee 100644 --- a/vl.c
+++ b/vl.c @@ -271,6 +271,30 @@ uint8_t qemu_uuid[16]; static
QEMUBootSetHandler *boot_set_handler; static void
*boot_set_opaque;
+static int default_serial = 1;
Default variables belong
On 12/07/2009 11:55 AM, Paolo Bonzini wrote:
OTOH, If all it does it log it to a file, theres a fair chance it might
succeed.
Not necessarily, for example fprintf may fail. There _may_ be a fair
chance to succeed if you use write(2) directly, but that's it
basically, and ENOMEM is always
On 12/07/09 13:54, Alexander Graf wrote:
On 07.12.2009, at 13:42, Gerd Hoffmann wrote:
Qemu creates a default serial line for you in case you didn't specify
one on the command line. Right now this is tied to the '-serial
chardev' command line switch, which in turn causes trouble if you are
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:
cause an interrupt
nop * N
check whether the interrupt happened
What I observe
Chris Webb wrote:
Hi. There's a connected discussion on the sheepdog list about locking, and I
have a patch there which could complement this one quite well.
Sheepdog is a distributed, replicated block store being developed
(primarily) for Qemu. Images have a mandatory exclusive locking
On 12/07/09 14:07, Alexander Graf wrote:
+static int default_virtcon = 1;
Hm, what does this do? Create both virtio-console-pci and virtio-console-s390
when default_virtcon=1?
No. Make qemu *not* create a default virtio console in case one was
added via '-device virtio-console-pci'.
Anthony Liguori anth...@codemonkey.ws writes:
I've resisted this because I'm concerned that if we delay the
opening of the file on the destination, it could fail. That's a
very late failure and that makes me uncomfortable as just a work
around for NFS.
I don't know much about NFS's
Daniel P. Berrange wrote:
That doesn't work in the case of setting up a clustered filesystem
shared between guests. That requires that the disk be opened writable,
but with a shared (F_RDLOCK) lock.
If you'd like data corruption :-)
qemu -drive file=/dev/hda,lock=shared # clustered file
Luiz Capitulino wrote:
On Sun, 06 Dec 2009 16:43:03 -0600
Anthony Liguori aligu...@linux.vnet.ibm.com 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.12.0 release.
This release is not intended for
Chris Webb wrote:
Anthony Liguori anth...@codemonkey.ws writes:
I've resisted this because I'm concerned that if we delay the
opening of the file on the destination, it could fail. That's a
very late failure and that makes me uncomfortable as just a work
around for NFS.
I don't know
On Mon, 07 Dec 2009 07:45:49 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Luiz Capitulino wrote:
On Sun, 06 Dec 2009 16:43:03 -0600
Anthony Liguori aligu...@linux.vnet.ibm.com wrote:
The QEMU team is pleased to announce the availability of the 0.12.0-rc1
release. This is
On Mon, Dec 07, 2009 at 07:43:53AM -0600, Anthony Liguori wrote:
Daniel P. Berrange wrote:
That doesn't work in the case of setting up a clustered filesystem
shared between guests. That requires that the disk be opened writable,
but with a shared (F_RDLOCK) lock.
If you'd like data
On 07.12.2009, at 14:27, Gerd Hoffmann wrote:
On 12/07/09 13:52, Alexander Graf wrote:
diff --git a/vl.c b/vl.c index 24d5d92..eca4eee 100644 --- a/vl.c
+++ b/vl.c @@ -271,6 +271,30 @@ uint8_t qemu_uuid[16]; static
QEMUBootSetHandler *boot_set_handler; static void
*boot_set_opaque;
On Mon, Dec 07, 2009 at 07:39:11AM -0600, Anthony Liguori wrote:
Richard W.M. Jones wrote:
Also if we only acquire the lock during the commit operation then
we'll end up with disk corruption.
Why do we end up with disk corruption?
Forget about locking for a minute, I don't think this is safe
Daniel P. Berrange wrote:
Better to stick with on/off. That gives much easier to understand
semantics.
The 3rd invocation is not changing the backing file, so it is not causing
data corruption on the master file. Sure the 3rd OS instance will probably
crash get confused because its
On Mon, Dec 07, 2009 at 02:16:33PM +0100, Gerd Hoffmann wrote:
On 12/07/09 14:03, Michael S. Tsirkin wrote:
Also - why not simply use virtio? I assume you are talking about
guests with virtio support otherwise MSI support in virtio
won't matter for them.
Point. Guests with
Jan Kiszka wrote:
Kevin Wolf wrote:
Hi Jan,
Am 19.11.2009 13:19, schrieb Jan Kiszka:
(gdb) print ((BDRVQcowState *)bs-opaque)-cluster_allocs.lh_first
$5 = (struct QCowL2Meta *) 0xcb3568
(gdb) print *((BDRVQcowState *)bs-opaque)-cluster_allocs.lh_first
$6 = {offset = 7417176064, n_start =
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 shared
locking type.
For any
Richard W.M. Jones wrote:
On Mon, Dec 07, 2009 at 07:39:11AM -0600, Anthony Liguori wrote:
Richard W.M. Jones wrote:
Also if we only acquire the lock during the commit operation then
we'll end up with disk corruption.
Why do we end up with disk corruption?
Forget about
On Mon, Dec 07, 2009 at 08:15:51AM -0600, Anthony Liguori wrote:
Daniel P. Berrange wrote:
Better to stick with on/off. That gives much easier to understand
semantics.
The 3rd invocation is not changing the backing file, so it is not causing
data corruption on the master file. Sure
On Mon, Dec 07, 2009 at 08:22:24AM -0600, Anthony Liguori wrote:
Richard W.M. Jones wrote:
On Mon, Dec 07, 2009 at 07:39:11AM -0600, Anthony Liguori wrote:
Richard W.M. Jones wrote:
Also if we only acquire the lock during the commit operation then
we'll end up with disk corruption.
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 aligu...@linux.vnet.ibm.com wrote:
The QEMU team is pleased to announce the availability of the 0.12.0-rc1
release. This is the first release
1 - 100 of 195 matches
Mail list logo
