On 01/25/10 23:35, Dor Laor wrote:
On 01/25/2010 04:21 PM, Anthony Liguori wrote:
Another way to look at this is that implementing a somewhat arbitrary
policy within QEMU's .c files is something we should try to avoid.
Implementing arbitrary policy in our default config file is a fine thing
to
This series of patches reduce the down time of the guest during a migration
without shared storage. It does that by start transfer dirty blocks in the
iterative phase. In the current code transferring of dirty blocks begins only
during the full phase while the guest is suspended. Therefore the
blk_mig_save_bulked_block is never called with sync flag. Remove the sync
flag. Calculate bulk completion during blk_mig_save_bulked_block.
Remove unused constants.
Signed-off-by: Liran Schour lir...@il.ibm.com
---
block-migration.c | 61 +++-
1
Move to stage3 only when remaining work can be done below max downtime.
Use qemu_get_clock_ns for measuring read performance.
Signed-off-by: Liran Schour lir...@il.ibm.com
---
block-migration.c | 79 +++--
1 files changed, 70 insertions(+), 9
This will manage dirty counter for each device and will allow to get the
dirty counter from above.
Signed-off-by: Liran Schour lir...@il.ibm.com
---
block.c | 16 ++--
block.h |1 +
block_int.h |1 +
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git
From: Paolo Bonzini pbonz...@redhat.com
Some places use get_clock directly because they want to access the
rt_clock with nanosecond precision. Add a function to do exactly that
instead of using internal interfaces.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-timer.h |1 +
On 01/25/2010 11:05 PM, Paolo Bonzini wrote:
I'm not sure about the choice for Windows. Do we want possibly a
dozen of .conf files all in the same directory as the binaries, or
maybe it's better to set sysconfdir = ${prefix}/conf,
confdir=${sysconfdir} on Windows?
I honestly don't know.
On 26.01.2010, at 07:49, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
KVM Hardware Inquiry Tool
One of the things I have on my todo list is a tool you can run on your machine
that tells you which virtualization features it supports. Imaginary output of
On Wed, Jan 20, 2010 at 12:37:51PM +0100, Kevin Wolf wrote:
To underline that it's a backend/platform dependent thing: Your patch
breaks the mingw build for me.
Actually that's because mingw is the usual piece of crap and doesn't
actually have any of the vector support you can expect from a
The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO content is small.
2. The writing interval is big.
3. No
On 26.01.2010, at 10:41, Sheng Yang wrote:
The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO
On Tue, Jan 26, 2010 at 10:59:17AM +0100, Alexander Graf wrote:
On 26.01.2010, at 10:41, Sheng Yang wrote:
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -59,6 +59,7 @@ struct KVMState
int vmfd;
int regs_modified;
int coalesced_mmio;
+struct kvm_coalesced_mmio_ring
The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO content is small.
2. The writing interval is big.
3. No
On Mon, 25 Jan 2010 17:38:38 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Jan 25, 2010 at 01:27:19PM -0200, Luiz Capitulino wrote:
On Mon, 25 Jan 2010 15:35:53 +0100
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
On Mon, 25
On Mon, 25 Jan 2010 15:33:40 +0100
Markus Armbruster arm...@redhat.com wrote:
Anthony Liguori anth...@codemonkey.ws writes:
On 01/21/2010 03:09 PM, Luiz Capitulino wrote:
{QMP: {capabilities: [async messages]}}
{ execute: query-qmp-mode }
{return: {mode: handshake}}
{ execute:
Start transfer dirty blocks during the iterative stage. That will
reduce the time that the guest will be suspended
Signed-off-by: Liran Schour lir...@il.ibm.com
---
block-migration.c | 135 +++--
1 files changed, 99 insertions(+), 36 deletions(-)
Start transfer dirty blocks during the iterative stage. That will
reduce the time that the guest will be suspended
Signed-off-by: Liran Schour lir...@il.ibm.com
---
block-migration.c | 135 +++--
1 files changed, 99 insertions(+), 36 deletions(-)
On Mon, 25 Jan 2010 12:18:44 -0600
Adam Litke a...@us.ibm.com wrote:
Changes since V1:
- Miscellaneous code cleanups (Thanks Luiz)
Qemu has a number of commands that can operate asynchronously (savevm,
migrate,
etc) and it will be getting more. For these commands, the user monitor needs
Luiz Capitulino lcapitul...@redhat.com writes:
On Mon, 25 Jan 2010 17:38:38 +0200
Michael S. Tsirkin m...@redhat.com wrote:
[...]
The issue I see isn't related to unsigned. Apparently we currently
accept values such as 'a' as valid strings. Since this is not valid json
we probably should
On Tue, Jan 26, 2010 at 07:21:16PM +0800, Sheng Yang wrote:
The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write
On 01/26/2010 05:43 AM, Luiz Capitulino wrote:
The issue I see isn't related to unsigned. Apparently we currently
accept values such as 'a' as valid strings. Since this is not valid json
we probably should reject it just in case we will want to switch to
another json library, otherwise clients
On Tue, Jan 26, 2010 at 06:47:12AM -0600, Anthony Liguori wrote:
On 01/26/2010 05:43 AM, Luiz Capitulino wrote:
The issue I see isn't related to unsigned. Apparently we currently
accept values such as 'a' as valid strings. Since this is not valid json
we probably should reject it just in case
On 01/26/2010 02:26 AM, Gerd Hoffmann wrote:
On 01/25/10 23:35, Dor Laor wrote:
On 01/25/2010 04:21 PM, Anthony Liguori wrote:
Another way to look at this is that implementing a somewhat arbitrary
policy within QEMU's .c files is something we should try to avoid.
Implementing arbitrary policy
On 01/26/2010 06:37 AM, Markus Armbruster wrote:
This extension is only used internally by QEMU
Let me elaborate: when a QEMP client sends us 'a' over the wire, the
parser rejects that as an error. At least that's what we've been
promised when the extension was discussed.
No,
Luiz Capitulino wrote:
capability_enable [ foo, bar ]
Now, only one command is not terrible difficult, but we would
have to accept an array of objects, like:
[ { name: foo, enabled: true }, { name: bar, enabled: true } ]
That looks like XML-itis.
Why not { foo: true, bar: true }?
--
On 01/26/2010 06:46 AM, Michael S. Tsirkin wrote:
Yes, I agree we are comnpliant.
But I also think we should be strict and reject non-JSON
input just so that clients do not come to depend on it.
If we can make JSON better while preserving compatibility and adhering
to the spec, why
On Tue, Jan 26, 2010 at 06:56:10AM -0600, Anthony Liguori wrote:
On 01/26/2010 06:37 AM, Markus Armbruster wrote:
This extension is only used internally by QEMU
Let me elaborate: when a QEMP client sends us 'a' over the wire, the
parser rejects that as an error. At least that's what
On Tue, Jan 26, 2010 at 06:58:32AM -0600, Anthony Liguori wrote:
On 01/26/2010 06:46 AM, Michael S. Tsirkin wrote:
Yes, I agree we are comnpliant.
But I also think we should be strict and reject non-JSON
input just so that clients do not come to depend on it.
If we can make JSON better
On 01/26/2010 03:21 AM, Christoph Hellwig wrote:
On Wed, Jan 20, 2010 at 12:37:51PM +0100, Kevin Wolf wrote:
To underline that it's a backend/platform dependent thing: Your patch
breaks the mingw build for me.
Actually that's because mingw is the usual piece of crap and doesn't
On Tue, Jan 26, 2010 at 06:58:32AM -0600, Anthony Liguori wrote:
On 01/26/2010 06:46 AM, Michael S. Tsirkin wrote:
Yes, I agree we are comnpliant.
But I also think we should be strict and reject non-JSON
input just so that clients do not come to depend on it.
If we can make JSON better
On 01/26/2010 03:09 AM, Alexander Graf wrote:
On 26.01.2010, at 07:49, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
KVM Hardware Inquiry Tool
Avi beat you to it ;-) See vmxcap in the tree.
One of the things I have on my todo list is a
On 01/26/2010 07:01 AM, Michael S. Tsirkin wrote:
For instance, at some point in time, we're going to do have to do
something about floating point representation.
What's the issue? There's '.' and there's 'e' ...
And maybe we won't need floating point ever ...
You cannot represent
On 01/26/2010 07:08 AM, Daniel P. Berrange wrote:
On Tue, Jan 26, 2010 at 06:58:32AM -0600, Anthony Liguori wrote:
On 01/26/2010 06:46 AM, Michael S. Tsirkin wrote:
Yes, I agree we are comnpliant.
But I also think we should be strict and reject non-JSON
input just so that clients do
On Tue, Jan 26, 2010 at 07:05:01AM -0600, Anthony Liguori wrote:
On 01/26/2010 06:56 AM, Michael S. Tsirkin wrote:
Then we'll have to support it forever. Asking clients to only depend on
valid JSON will make sure we can use json library in the future, as well
as allow easier debugging etc.
On 01/26/2010 03:11 PM, Anthony Liguori wrote:
On 01/26/2010 03:09 AM, Alexander Graf wrote:
On 26.01.2010, at 07:49, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
KVM Hardware Inquiry Tool
Avi beat you to it ;-) See vmxcap in the tree.
I knew I
On 26.01.2010, at 14:11, Anthony Liguori wrote:
On 01/26/2010 03:09 AM, Alexander Graf wrote:
On 26.01.2010, at 07:49, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
KVM Hardware Inquiry Tool
Avi beat you to it ;-) See vmxcap in the
Hi,
While emulating a small MMU-less CRIS system I ran into an -icount
related problem. Without icount the emulation runs fine, with icount
I get stuff like:
qemu: fatal: cpu_io_recompile: could not find TB for pc=0x4be7fd
IIUC, there is a recursion bug in the slow_ldx() calls that ends
up
On 01/26/2010 03:18 PM, Alexander Graf wrote:
The main question is where does it belong?
a) built into qemu
b) built as separate tool, but shipped with qemu
c) completely separate
I'm personally leaning towards a. That way we can reuse the detection code and
give help when an option is used
On Tue, Jan 26, 2010 at 03:24:50PM +0200, Avi Kivity wrote:
On 01/26/2010 03:18 PM, Alexander Graf wrote:
The main question is where does it belong?
a) built into qemu
b) built as separate tool, but shipped with qemu
c) completely separate
I'm personally leaning towards a. That way we
On 26.01.2010, at 14:33, Daniel P. Berrange wrote:
On Tue, Jan 26, 2010 at 03:24:50PM +0200, Avi Kivity wrote:
On 01/26/2010 03:18 PM, Alexander Graf wrote:
The main question is where does it belong?
a) built into qemu
b) built as separate tool, but shipped with qemu
c) completely
On Tue, Jan 26, 2010 at 07:08:20AM -0600, Anthony Liguori wrote:
I can either throw in an #ifdef IOV_MAX around the check or fake one up
for mingw. Does any of the maintainers have a preference for either
variant?
grep for CONFIG_IOVEC in qemu-common.h and add a #define IOV_MAX.
On 01/26/2010 03:33 PM, Daniel P. Berrange wrote:
Me too, especially as the whole stack is involved, and qemu is the
topmost part from our perspective (no doubt libvirt will want to
integrate that functionality as well).
FYI, libvirt already exposes this kind of functionality. The API
On Tue, 26 Jan 2010 12:57:54 +
Jamie Lokier ja...@shareable.org wrote:
Luiz Capitulino wrote:
capability_enable [ foo, bar ]
Now, only one command is not terrible difficult, but we would
have to accept an array of objects, like:
[ { name: foo, enabled: true }, { name: bar,
If we go over the maximum number of iovecs support by syscall we get
back EINVAL from the kernel which translate to I/O errors for the guest.
Add a MAX_IOV defintion for platforms that don't have it. For now we use
the same 1024 define that's used on Linux and various other platforms,
but until
On 01/26/2010 02:47 PM, Anthony Liguori wrote:
On 01/26/2010 05:43 AM, Luiz Capitulino wrote:
The issue I see isn't related to unsigned. Apparently we currently
accept values such as 'a' as valid strings. Since this is not valid
json
we probably should reject it just in case we will want to
On 01/26/2010 07:55 AM, Avi Kivity wrote:
The risk is that if we support a private extension (like '') and then
json is officially extended to support a conflicting or similar syntax
with a different meaning, then we cannot advance to the next revision
of json without breaking compatibility.
On 01/26/2010 04:05 PM, Anthony Liguori wrote:
On 01/26/2010 07:55 AM, Avi Kivity wrote:
The risk is that if we support a private extension (like '') and then
json is officially extended to support a conflicting or similar
syntax with a different meaning, then we cannot advance to the next
On 01/26/2010 07:24 AM, Avi Kivity wrote:
On 01/26/2010 03:18 PM, Alexander Graf wrote:
The main question is where does it belong?
a) built into qemu
b) built as separate tool, but shipped with qemu
c) completely separate
I'm personally leaning towards a. That way we can reuse the detection
On 01/26/2010 04:13 PM, Anthony Liguori wrote:
Me too, especially as the whole stack is involved, and qemu is the
topmost part from our perspective (no doubt libvirt will want to
integrate that functionality as well).
I'm not sure I agree. It would use no code from qemu and really
benefit
Verify that stdio.h supports %ll and %z
Some migw variants don't unless requested explicitly (see
http://www.mail-archive.com/mingw-w64-pub...@lists.sourceforge.net/msg00417.html)
), detect them early.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
configure | 25
On 01/26/2010 08:15 AM, Avi Kivity wrote:
On 01/26/2010 04:13 PM, Anthony Liguori wrote:
Me too, especially as the whole stack is involved, and qemu is the
topmost part from our perspective (no doubt libvirt will want to
integrate that functionality as well).
I'm not sure I agree. It would
On 01/26/2010 04:22 PM, Anthony Liguori wrote:
On 01/26/2010 08:15 AM, Avi Kivity wrote:
On 01/26/2010 04:13 PM, Anthony Liguori wrote:
Me too, especially as the whole stack is involved, and qemu is the
topmost part from our perspective (no doubt libvirt will want to
integrate that
On Tue, Jan 26, 2010 at 12:57:54PM +, Jamie Lokier wrote:
Luiz Capitulino wrote:
capability_enable [ foo, bar ]
Now, only one command is not terrible difficult, but we would
have to accept an array of objects, like:
[ { name: foo, enabled: true }, { name: bar, enabled: true } ]
On 01/26/2010 08:26 AM, Avi Kivity wrote:
On 01/26/2010 04:22 PM, Anthony Liguori wrote:
On 01/26/2010 08:15 AM, Avi Kivity wrote:
On 01/26/2010 04:13 PM, Anthony Liguori wrote:
Me too, especially as the whole stack is involved, and qemu is the
topmost part from our perspective (no doubt
On 01/26/2010 04:32 PM, Anthony Liguori wrote:
It would need to know which cpuid bits qemu supports. Only qemu
knows that.
I'm not sure I understand why. Can you elaborate?
If qemu doesn't recognize -cpu qemu64,+nx, then no amount of hardware
and kvm.ko support will allow the user to
On 01/26/2010 08:12 AM, Avi Kivity wrote:
On 01/26/2010 04:05 PM, Anthony Liguori wrote:
On 01/26/2010 07:55 AM, Avi Kivity wrote:
The risk is that if we support a private extension (like '') and
then json is officially extended to support a conflicting or similar
syntax with a different
On 01/26/2010 04:42 PM, Anthony Liguori wrote:
On 01/26/2010 08:37 AM, Avi Kivity wrote:
People who use discovery tools are probably setting up a migration
cluster. They aren't going to use -cpu host.
BTW, it might be neat to introduce a qemu command line that runs a
monitor command and
On 01/26/2010 04:42 PM, Alexander Graf wrote:
That's /proc/cpuinfo, we should just extend it, maybe that's what Alex meant,
but I'd like to see something more capable.
I think we're all looking at different use-cases.
First and frontmost the one type of user I'm concerned with in this
On 26.01.2010, at 15:47, Avi Kivity wrote:
On 01/26/2010 04:42 PM, Alexander Graf wrote:
That's /proc/cpuinfo, we should just extend it, maybe that's what Alex
meant, but I'd like to see something more capable.
I think we're all looking at different use-cases.
First and frontmost
On 01/26/2010 08:50 AM, Alexander Graf wrote:
On 26.01.2010, at 15:47, Avi Kivity wrote:
On 01/26/2010 04:42 PM, Alexander Graf wrote:
That's /proc/cpuinfo, we should just extend it, maybe that's what Alex meant,
but I'd like to see something more capable.
I
Daniel P. Berrange wrote:
On Tue, Jan 26, 2010 at 12:57:54PM +, Jamie Lokier wrote:
Luiz Capitulino wrote:
capability_enable [ foo, bar ]
Now, only one command is not terrible difficult, but we would
have to accept an array of objects, like:
[ { name: foo, enabled: true
From: Riku Voipio riku.voi...@nokia.com
If you compile applications with gcc -mtp=cp15, __thread
access's will generate an abort. Implement accessing allowed
cp15.c13 registers on ARMv6K+ in linux-user.
Signed-off-by: Riku Voipio riku.voi...@nokia.com
---
target-arm/helper.c | 27
From: Riku Voipio riku.voi...@nokia.com
Some fixes to avoid hanging, make arm uname match selected
cpu, and fixes to cp15.c13 registers for linux-user tls register
access.
Loïc Minier (1):
linux-user: adapt uname machine to emulated CPU
Riku Voipio (4):
fix locking error with current_tb
From: Riku Voipio riku.voi...@nokia.com
Signed-off-by: Riku Voipio riku.voi...@nokia.com
---
exec.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/exec.c b/exec.c
index 1190591..71f655f 100644
--- a/exec.c
+++ b/exec.c
@@ -1537,15 +1537,15 @@ static void
From: Loïc Minier l...@dooz.org
This patch for linux-user adapts the output of the emulated uname()
syscall to match the configured CPU. Tested with x86, x86-64 and arm
emulation.
Signed-off-by: Loïc Minier l...@dooz.org
Signed-off-by: Riku Voipio riku.voi...@nokia.com
---
Makefile.target
Verify that stdio.h supports %lld %zd.
Some migw variants don't unless requested explicitly (see
http://www.mail-archive.com/mingw-w64-pub...@lists.sourceforge.net/msg00417.html)
), detect them early.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Acked-by: Juan Quintela quint...@trasno.org
Jan Kiszka wrote:
Toralf Förster wrote:
Hi,
under a mostly stable Gentoo I observed this new msg :
tfoer...@n22 ~/virtual/kvm $ qemu -hda gentoo_kdevm.img -hdb
portage_kdeprefix.img -hdd swap.img -smp 2 -m 768 -vga std -soundhw es1370
On Tue, 26 Jan 2010 15:57:46 +
Jamie Lokier ja...@shareable.org wrote:
Daniel P. Berrange wrote:
On Tue, Jan 26, 2010 at 12:57:54PM +, Jamie Lokier wrote:
Luiz Capitulino wrote:
capability_enable [ foo, bar ]
Now, only one command is not terrible difficult, but we
On Tue, Jan 26, 2010 at 5:00 PM, Riku Voipio riku.voi...@iki.fi wrote:
From: Riku Voipio riku.voi...@nokia.com
If you compile applications with gcc -mtp=cp15, __thread
access's will generate an abort. Implement accessing allowed
cp15.c13 registers on ARMv6K+ in linux-user.
Signed-off-by:
On Tue, Jan 26, 2010 at 5:00 PM, Riku Voipio riku.voi...@iki.fi wrote:
From: Riku Voipio riku.voi...@nokia.com
Change the system-emulation code also to only support accessing
the cp15.c13 Thread ID registers on ARMv6K and newer.
Signed-off-by: Riku Voipio riku.voi...@nokia.com
---
On 01/26/10 07:46, Gleb Natapov wrote:
On Mon, Jan 25, 2010 at 06:13:35PM +0100, Jes Sorensen wrote:
I am fine with having QEMU build the e820 tables completely if there is
a consensus to take that path.
QEMU can't build the e820 map completely. There are things it doesn't
know. Like how much
Ping?
r~
On 01/20/2010 09:18 AM, Richard Henderson wrote:
Changes v5-v6:
* Update x86-64 post P_REXB changes.
Changes v4-v5:
* Document double-word support opcodes in a new section of the README,
as requested by Aurelien.
* Shorten the branch-to-next in the EQ case of i386
Ping?
r~
On 01/04/2010 02:46 PM, Richard Henderson wrote:
I've split up the FPCR as requested by Aurelien. We no longer
set anything in FP_STATUS after the execution of the operation,
only copy data from FP_STATUS to some env-fpcr field.
I have totally rewritten the patch to be more along
On Thu, Jan 21, 2010, Måns Rullgård wrote:
I think that entire test is wrong, in fact. It is perfectly possible
for someone on Solaris to install a working install command in
/usr/bin. It is better, if possible, to test whatever install
command is in the path, and complain only if it
On 01/26/2010 08:44 AM, Jan Kiszka wrote:
Hi,
just received some Linux guest kernel that refuses to properly use its
framebuffer console under QEMU (probably any version, tried down to some
0.10.x). It turned out that it has CONFIG_FB_CIRRUS enabled and fails to
initialize the display when this
2010/1/24 Blue Swirl blauwir...@gmail.com:
On Sun, Jan 24, 2010 at 2:02 AM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
All solaris versions which currently boot (from cd) regularly produce
buckets of
hsfs_putpage: dirty HSFS page messages.
High Sierra is a pretty old and stable
Hi,
I saw that some pretty long time ago, but didn't care enough to investigate,
just disabled the cirrus fb in T2 (http://t2-project.org):
r...@8way:t2-trunk-clean$ svn log -r29093
r29093 | rene | 2008-05-27 09:37:57
Anthony Liguori wrote:
On 01/26/2010 08:44 AM, Jan Kiszka wrote:
Hi,
just received some Linux guest kernel that refuses to properly use its
framebuffer console under QEMU (probably any version, tried down to some
0.10.x). It turned out that it has CONFIG_FB_CIRRUS enabled and fails to
Michael S. Tsirkin m...@redhat.com writes:
Verify that stdio.h supports %lld %zd.
Some migw variants don't unless requested explicitly (see
http://www.mail-archive.com/mingw-w64-pub...@lists.sourceforge.net/msg00417.html)
), detect them early.
Signed-off-by: Michael S. Tsirkin
On Tue, Jan 26, 2010 at 6:47 PM, Loïc Minier l...@dooz.org wrote:
On Thu, Jan 21, 2010, Måns Rullgård wrote:
I think that entire test is wrong, in fact. It is perfectly possible
for someone on Solaris to install a working install command in
/usr/bin. It is better, if possible, to test
On Tue, Jan 26, 2010 at 7:03 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
2010/1/24 Blue Swirl blauwir...@gmail.com:
On Sun, Jan 24, 2010 at 2:02 AM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
All solaris versions which currently boot (from cd) regularly produce
buckets of
2010/1/26 Måns Rullgård m...@mansr.com:
Michael S. Tsirkin m...@redhat.com writes:
Verify that stdio.h supports %lld %zd.
Some migw variants don't unless requested explicitly (see
http://www.mail-archive.com/mingw-w64-pub...@lists.sourceforge.net/msg00417.html)
), detect them early.
On Tue, Jan 26, 2010 at 05:27:27PM +0100, Laurent Desnogues wrote:
On Tue, Jan 26, 2010 at 5:00 PM, Riku Voipio riku.voi...@iki.fi wrote:
From: Riku Voipio riku.voi...@nokia.com
If you compile applications with gcc -mtp=cp15, __thread
access's will generate an abort. Implement accessing
The changes in V8 of this patch are related to the monitor infrastructure. No
changes to the virtio interface core have been made since V4. This is intended
to apply on top of my API for asynchronous monitor commands patch.
Changes since V7:
- Ported to the asynchronous monitor API
Changes
On 01/25/2010 07:23 AM, Markus Armbruster wrote:
Helper function just like qdict_get_int(), just for QFloat/double.
Signed-off-by: Markus Armbrusterarm...@redhat.com
Breaks check_qdict's build. Need to update the Makefile. You can just
send a v4 of this patch.
Regards,
Anthony
On 01/20/2010 06:07 AM, Markus Armbruster wrote:
Signed-off-by: Markus Armbrusterarm...@redhat.com
---
monitor.c |4 ++--
qemu-monitor.hx |3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index 816f6fd..b9166c3 100644
--- a/monitor.c
On 01/19/2010 05:56 PM, Juan Quintela wrote:
From: Kirill A. Shutemovkir...@shutemov.name
A variant of write(2) which handles partial write.
Signed-off-by: Kirill A. Shutemovkir...@shutemov.name
Signed-off-by: Juan Quintelaquint...@redhat.com
Applied all. Thanks.
Regards,
Anthony
On 01/20/2010 06:07 AM, Markus Armbruster wrote:
mon_get_cpu() can't return null pointer, because it passes its return
value to cpu_synchronize_state() first, which crashes if its argument
is null.
Remove the (pretty cheesy) handling of this non-existing error.
Signed-off-by: Markus
On 01/20/2010 08:02 AM, Kevin Wolf wrote:
Return the appropriate error value instead of always using EIO. Don't free the
L1 table on errors, we still need it.
Signed-off-by: Kevin Wolfkw...@redhat.com
Applied all. Thanks.
Do you think this is stable-0.12 material? Is there any
On 01/20/2010 11:41 AM, Juan Quintela wrote:
It really sets uname string. It don't make sense a --disable option
Signed-off-by: Juan Quintelaquint...@redhat.com
Patch 3/7 doesn't apply. It's an annoying one to rebase too. Please
send out a new series and ping me and I'll quickly apply
Hi,
Based on the feedback I received over the e820 reserve patch, I have
changed it to have QEMU pass in a list of entries that can cover more
than just the TSS/EPT range. This should provide the flexibility that
people were asking for.
The Seabios portion should allow for unlimited sized
Hi,
This is the QEMU-KVM part of the patch. If we can agree on this
approach, I will do a version for upstream QEMU as well.
Cheers,
Jes
Use qemu-cfg to provide the BIOS with an optional table of e820 entries.
Notify the BIOS of the location of the TSS+EPT range to by reserving
it via the
On 26.01.2010, at 22:53, Jes Sorensen wrote:
Hi,
This is the QEMU-KVM part of the patch. If we can agree on this
approach, I will do a version for upstream QEMU as well.
It shows as attachment again :(.
Alex
Cheers,
Jes
0011-qemu-kvm-e820-table.patch
Applied. Thanks.
Regards,
Anthony Liguori
On 01/20/2010 10:26 AM, Marcelo Tosatti wrote:
savevm without id or tag segfaults in:
(gdb) bt
#0 0x7f600a83bf8a in __strcmp_sse42 () from /lib64/libc.so.6
#1 0x004745b6 in bdrv_snapshot_find (bs=value optimized out,
On 01/20/2010 11:01 AM, Juan Quintela wrote:
From: Marcelo Tosattimtosa...@redhat.com
If migration takes place between write of the bmdma address register and
write of the command register (to initiate DMA), the destination will
not properly start the DMA op, hanging the guest:
ata1.00:
On 01/20/2010 11:13 AM, Christoph Hellwig wrote:
Check the whitelist as early as possible instead of continuing the
setup, and move all the error handling code to the end of the
function.
Signed-off-by: Christoph Hellwigh...@lst.de
Applied all. Thanks.
Regards,
Anthony Liguori
Index:
On 01/20/2010 01:54 PM, Juan Quintela wrote:
This patch improves Anthony patch a6a853c86275efd89996ce59612a000c5873db5d
Once there, it improves handling of object files for qemu tools
cc: Andreas Färberandreas.faer...@web.de
Signed-off-by: Juan Quintelaquint...@redhat.com
Applied.
On 01/20/2010 03:25 PM, Stefan Weil wrote:
Some more command line options had entries for command line help,
but documentation for texi and derived formats (man, html, info)
was missing.
For conditional options, the texi documentation was added
unconditionally.
This seems reasonable because
On 01/21/2010 04:13 AM, Amit Shah wrote:
This file was renamed to ease the reviews of the recent changes
that went in.
Now that the changes are done, rename the file back to its original
name.
Signed-off-by: Amit Shahamit.s...@redhat.com
Applied. Thanks.
Regards,
Anthony Liguori
---
On 01/21/2010 04:49 AM, Amit Shah wrote:
These hunks got dropped off mysteriously during the rebasing of my
virtio-serial series. Thanks go to Markus for noticing it.
Without these fixes, -virtioconsole doesn't actually have any effect.
Signed-off-by: Amit Shahamit.s...@redhat.com
Reported-by:
1 - 100 of 134 matches
Mail list logo
