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 d
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 gu
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
---
block-migration.c | 61 +++-
1 files changed, 18
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
---
block-migration.c | 79 +++--
1 files changed, 70 insertions(+), 9 deletions(-)
diff --
This will manage dirty counter for each device and will allow to get the
dirty counter from above.
Signed-off-by: Liran Schour
---
block.c | 16 ++--
block.h |1 +
block_int.h |1 +
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
in
From: Paolo Bonzini
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
---
qemu-timer.h |1 +
vl.c | 21 +++--
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. What'
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 no
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 ne
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 c
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_mmi
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 ne
On Mon, 25 Jan 2010 17:38:38 +0200
"Michael S. Tsirkin" 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 wrote:
> >
> > > Luiz Capitulino writes:
> > >
> > > > On Mon, 25 Jan 2010 12:09:06 +0200
> > > > "Mic
On Mon, 25 Jan 2010 15:33:40 +0100
Markus Armbruster wrote:
> Anthony Liguori writes:
>
> > On 01/21/2010 03:09 PM, Luiz Capitulino wrote:
> >> """
> >> {"QMP": {"capabilities": ["async messages"]}}
> >>
> >> { "execute": "query-qmp-mode" }
> >> {"return": {"mode": "handshake"}}
> >>
> >> { "ex
Start transfer dirty blocks during the iterative stage. That will
reduce the time that the guest will be suspended
Signed-off-by: Liran Schour
---
block-migration.c | 135 +++--
1 files changed, 99 insertions(+), 36 deletions(-)
diff --git a/bloc
Start transfer dirty blocks during the iterative stage. That will
reduce the time that the guest will be suspended
Signed-off-by: Liran Schour
---
block-migration.c | 135 +++--
1 files changed, 99 insertions(+), 36 deletions(-)
diff --git a/bloc
On Mon, 25 Jan 2010 12:18:44 -0600
Adam Litke 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
> to be s
Luiz Capitulino writes:
> On Mon, 25 Jan 2010 17:38:38 +0200
> "Michael S. Tsirkin" 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
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
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 m
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 jus
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 i
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, that
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": tr
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 wouldn'
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 th
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 JS
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.
As I mentioned in IRC, I'm not opposed to making this feature of
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
actual
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 J
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 t
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 an
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 n
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 et
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 shou
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 ;-) Se
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 clobb
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 t
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
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
>>
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_MA
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 ca
On Tue, 26 Jan 2010 12:57:54 +
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": "ba
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 t
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 s
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
rev
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 i
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
---
configure | 25 +
1 files chan
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 functionali
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"
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 libvi
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 enab
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 meani
On 26.01.2010, at 15:37, Avi Kivity wrote:
> 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,
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 exits without creating a VM. We could then
introdu
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 is actually used. Anyone came across
this be
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 exit
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.
>>
>> Fi
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 thin
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:
> > >
> > > [ {
From: Riku Voipio
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
---
target-arm/helper.c | 27 ++-
1 files changed, 26 insert
From: Riku Voipio
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
linux-user: remove sign
From: Riku Voipio
Signed-off-by: Riku Voipio
---
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 cpu_unlink_tb(CPUState *env)
TranslationBlock *tb;
From: Loïc Minier
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
Signed-off-by: Riku Voipio
---
Makefile.target|2 +-
linux-user/cpu-uname.c | 72
From: Riku Voipio
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
---
target-arm/helper.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/target-arm/helper.c b/
From: Riku Voipio
Qemu may hang in host_signal_handler after qemu has done a
seppuku with cpu_abort(). But at this stage we are not really
interested in target process coredump anymore, so unregister
host_signal_handler to die grafefully.
Signed-off-by: Riku Voipio
---
exec.c |9 +
On 26.01.2010, at 15:44, 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 displ
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
Acked-by: Juan Quintela
---
changes from v1:
remove
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 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 wo
On Tue, Jan 26, 2010 at 5:00 PM, Riku Voipio wrote:
> From: Riku Voipio
>
> 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
> ---
> target-arm/he
On Tue, Jan 26, 2010 at 5:00 PM, Riku Voipio wrote:
> From: Riku Voipio
>
> 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
> ---
> target-arm/helper.c | 12
> 1 files changed,
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 brcond
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 th
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 :
> On Sun, Jan 24, 2010 at 2:02 AM, Artyom Tarasenko
> 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 stuff, so it is possible that
>> the
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 +020
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
"Michael S. Tsirkin" 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
> Acked-by: Juan Qui
On Tue, Jan 26, 2010 at 6:47 PM, Loïc Minier 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 whatever "i
On Tue, Jan 26, 2010 at 7:03 PM, Artyom Tarasenko
wrote:
> 2010/1/24 Blue Swirl :
>> On Sun, Jan 24, 2010 at 2:02 AM, Artyom Tarasenko
>> wrote:
>>> All solaris versions which currently boot (from cd) regularly produce
>>> buckets of
>>> "hsfs_putpage: dirty HSFS page" messages.
>>>
>>> High Sie
2010/1/26 Måns Rullgård :
> "Michael S. Tsirkin" 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: Micha
On Tue, Jan 26, 2010 at 05:27:27PM +0100, Laurent Desnogues wrote:
> On Tue, Jan 26, 2010 at 5:00 PM, Riku Voipio wrote:
> > From: Riku Voipio
> >
> > If you compile applications with gcc -mtp=cp15, __thread
> > access's will generate an abort. Implement accessing allowed
> > cp15.c13 registers o
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 sin
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 Armbruster
Breaks check_qdict's build. Need to update the Makefile. You can just
send a v4 of this patch.
Regards,
Anthony Liguori
On 01/20/2010 06:07 AM, Markus Armbruster wrote:
Signed-off-by: Markus Armbruster
---
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
+++ b/monitor.c
@@
On 01/19/2010 05:56 PM, Juan Quintela wrote:
From: Kirill A. Shutemov
A variant of write(2) which handles partial write.
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Juan Quintela
Applied all. Thanks.
Regards,
Anthony Liguori
---
osdep.c | 27 +++
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 Armbruster
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 Wolf
Applied all. Thanks.
Do you think this is stable-0.12 material? Is there any reasonable
scenario wher
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 Quintela
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 it since this
one
Michael S. Tsirkin schrieb:
> Verify that stdio.h supports %lld %zd.
> Some migw variants don't unless requested explicitly (see
migw -> mingw
I don't know any ming32 variant which supports %lld, %zd.
There is a new mingw-w64 were people are addressing the
problem, but that variant is unsupported
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 tables
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 e820
1 - 100 of 144 matches
Mail list logo
