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 gu
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 caus
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 SEGMEN
Am 06.12.2009 13:00, schrieb malc:
> On Sun, 6 Dec 2009, Markus Armbruster wrote:
>
>> malc writes:
>>
>>> On Sun, 6 Dec 2009, Markus Armbruster wrote:
>>>
malc writes:
>>>
>>> [..snip..]
>>>
read(fd, malloc(0), 0) is just fine, because read() doesn't touch the
buffer wh
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
Will unapply.
--
error compiling committee.c: too many arguments to functi
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 mal
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
go
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
> Can somebody out there please help me with this issue.
>
> Thanks,
> PurnaChandar M
>
> 2009/10/26 Purna Cha
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
I don't know much about acpi.
One general comment below.
> ---
> Makefile.target |4 +-
> h
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
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: I
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
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:
> >
> > -d
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 vecto
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 t
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 PC
malc writes:
> On Sun, 6 Dec 2009, Markus Armbruster wrote:
>
>> malc writes:
>>
>> > On Sun, 6 Dec 2009, Markus Armbruster wrote:
>> >
>> >> malc writes:
>> >>
>> >
>> > [..snip..]
>> >
>> >>
>> >> read(fd, malloc(0), 0) is just fine, because read() doesn't touch the
>> >> buffer when the s
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 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 = qemu_malloc(n
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 handl
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
> cert
Jamie Lokier 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 remind
On Mon, 7 Dec 2009, Markus Armbruster wrote:
> malc writes:
>
> > On Sun, 6 Dec 2009, Markus Armbruster wrote:
> >
> >> malc writes:
> >>
> >> > On Sun, 6 Dec 2009, Markus Armbruster wrote:
> >> >
> >> >> malc writes:
> >> >>
> >> >
> >> > [..snip..]
> >> >
> >> >>
> >> >> read(fd, malloc(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.
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
>
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 writes:
> On Mon, 7 Dec 2009, Markus Armbruster wrote:
>
>> malc writes:
>>
>> > On Sun, 6 Dec 2009, Markus Armbruster wrote:
>> >
>> >> malc writes:
>> >>
>> >> > On Sun, 6 Dec 2009, Markus Armbruster wrote:
>> >> >
>> >> >> malc 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 the
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 im
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 the
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 fr
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=excl
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
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 im
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 are
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, o
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
> system
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
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 anoth
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 th
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
>
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 con
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 t
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 sh
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,
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 thin
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 via
This reverts commit 93d434b4aec0702b87ebf52449a3cdf2c3596825.
Signed-off-by: Gerd Hoffmann
---
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 +4710,6 @@ int main(i
Signed-off-by: Gerd Hoffmann
---
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,
DisplayState *ds
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
---
console.c |8
vl.c | 24
2 files changed, 8 in
This reverts commit adcb181afe5a951c521411c7a8e9d9b791aa6742.
Conflicts:
monitor.h
Signed-off-by: Gerd Hoffmann
---
monitor.c | 18 --
monitor.h |1 -
qemu-options.hx |5 ++---
vl.c| 11 ---
4 files changed, 6 insertions(+), 2
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
' command line switch, which in turn causes trouble if you are
creating your serial line via '-device isa-serial,'.
This patch adds a variable default_serial which
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
---
net.c |5 -
net.h |1 +
vl.c |1 +
3 files changed, 6
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
---
vl.c | 16 ++--
1 files changed, 10 insertions(+), 6 del
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 a
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 ' command line
switch, which in turn causes trouble if you are creating your gfx card
using '-device VGA,'.
This patch adds a variable default_vga which says whenever a defau
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.
Sign
Add global command line option to disable default devices.
Signed-off-by: Gerd Hoffmann
---
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 100644
--- a/qemu-opti
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
---
vl.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/vl.c b/vl.c
index
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
' command line switch, which in turn causes trouble if you are
creating your parallel port via '-device isa-parallel,'.
This patch adds a variable default_para
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 line
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
---
hw/boards.h |2 +-
hw/pc.c |2 +-
hw/qdev-properties.c | 22 +
Signed-off-by: Gerd Hoffmann
---
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 *qemu_chr_open_soc
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
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
---
vl.c | 11 ++-
1 files chan
Signed-off-by: Gerd Hoffmann
---
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
@@ -1588,6 +1588,8 @@ ser
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"
pr
Signed-off-by: Gerd Hoffmann
---
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
@@ -1589,6 +1589,13 @@ The
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.12.0 release.
> This release is not intended for production use.
>
> Testing release candidates is a grea
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
> ' command line switch, which in turn causes trouble if you are
> creating your serial line via '-device isa-se
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
> ' command line switch, which in turn causes trouble if you are
> creating your serial line via '-device isa-se
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 conv
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 virtio-console-s
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 th
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
' command line switch, which in turn causes trouble if you are
creating
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
What I observe is that the proper interrupt does take a place, but
aft
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 requirem
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'.
ch
Anthony Liguori 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 semantics with cache-coher
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 -drive fil
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 s
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.12.0 release.
This release is not intended for production use.
Testing release
Chris Webb wrote:
Anthony Liguori 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 sema
On Mon, 07 Dec 2009 07:45:49 -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
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
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_opaq
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 i
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 back
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 virtio-co
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 =
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 qem
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 lo
On Mon, Dec 07, 2009 at 07:32:16AM -0600, Anthony Liguori wrote:
> 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 d
1 - 100 of 202 matches
Mail list logo
