On Wed, 9 Nov 2011 11:55:51 +0530, Harsh Prateek Bora
ha...@linux.vnet.ibm.com wrote:
Currently, we just print the numerical value of 9p operation identifier in
case of RERROR which is less meaningful for readability. Mapping 9p
operation ids to symbolic names provides a better tracelog:
* Ted Ts'o ty...@mit.edu wrote:
On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
I guess you can do well with a split project as well - my main
claim is that good compatibility comes *naturally* with
integration.
Here I have to disagree; my main worry is that integration
* Ted Ts'o ty...@mit.edu wrote:
On Tue, Nov 08, 2011 at 07:14:57PM +0200, Anca Emanuel wrote:
@Ten Ts'o: you are sponsored by something like microsoft (joking)
? Stop trolling. If you are not familiar with perf, or other
tools, save your time and do some useful things.
I am quite
* John Kacur jka...@redhat.com wrote:
On Tue, 8 Nov 2011, Ted Ts'o wrote:
On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
I guess you can do well with a split project as well - my main
claim is that good compatibility comes *naturally* with
integration.
Here I
On 11/09/2011 01:43 PM, Aneesh Kumar K.V wrote:
On Wed, 9 Nov 2011 11:55:51 +0530, Harsh Prateek
Boraha...@linux.vnet.ibm.com wrote:
Currently, we just print the numerical value of 9p operation identifier in
case of RERROR which is less meaningful for readability. Mapping 9p
operation ids to
Just for cleanliness; it would take a truly gigantic cursor to break.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/qxl-render.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/qxl-render.c b/hw/qxl-render.c
index 2c51ba9..133d093 100644
---
* Gerd Hoffmann kra...@redhat.com wrote:
For reference, the default set of colors now is (from
tools/perf/util/ui/browser.c):
static struct ui_browser__colorset {
const char *name, *fg, *bg;
int colorset;
} ui_browser__colorsets[] = {
{
* Arnaldo Carvalho de Melo a...@redhat.com wrote:
sure the colors have enougth contrast so they are readable.
Problem is figuring out something that is considered a good default
:-\ There will always be somebody that will complain.
When doing the coding to allow using the default xterm
* Steven Rostedt rost...@goodmis.org wrote:
On Tue, Nov 08, 2011 at 10:32:25AM +0100, Ingo Molnar wrote:
None of the perf developers with whom i'm working complained
about the shared repo so far - publicly or privately. By all
means they are enjoying it and if you look at the stats
Am 08.11.2011 20:25, schrieb Charles Arnold:
The Data Offset field in the Dynamic Disk Header is an 8 byte field.
Although the specification (2006-10-11) gives an example of initializing
only the first 4 bytes, images generated by Microsoft on Windows initialize
all 8 bytes.
Failure to
On Wed, Nov 9, 2011 at 5:14 AM, Deepak Shetty dpkshe...@gmail.com wrote:
I get the following error when i created a account on wiki.qemu.org
My email id is correctly mentioned, but it still says unable to send mail
for confirmation to my given email ID.
QEMU could not send your confirmation
On Wed, Nov 9, 2011 at 1:09 AM, Rob White rwh...@pobox.com wrote:
The attached patch (against qemu-0.12.3) allows me to convert a raw
image into a scsi vmdk image:
qemu-img convert -O vmdk -o scsi rootfs.raw rootfs.vmdk
Please rebase onto qemu.git/master.
Please see this wiki page on how
On Tue, 2011-11-08 at 13:59 +0100, Ingo Molnar wrote:
Also the self monitor stuff, perf-tool doesn't use that for obvious
reasons.
Indeed, and that's PAPI's strong point.
We could try to utilize it via some clever LD_PRELOAD trickery?
Wouldn't be really meaningful, a perf-test case
On Tue, Nov 08, 2011 at 03:26:19PM +0100, Markus Armbruster wrote:
Fixes protocol_client_auth_sasl_mechname() not to crash when malloc()
fails. Spotted by Coverity.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
ui/vnc-auth-sasl.c | 19 +--
1 files changed, 5
On Tue, Nov 08, 2011 at 03:36:47PM +0100, Markus Armbruster wrote:
Markus Armbruster (3):
x86/cpuid: Convert remaining strdup() to g_strdup()
x86/cpuid: Plug memory leak in cpudef_setfield()
x86/cpuid: Fix crash on -cpu
target-i386/cpuid.c | 13 +++--
1 files changed, 7
On Wed, Nov 09, 2011 at 09:52:55AM +0100, Markus Armbruster wrote:
Just for cleanliness; it would take a truly gigantic cursor to break.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/qxl-render.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Thanks, applied to
On 11/08/2011 11:52 PM, Max Filippov wrote:
With kernel command line of 'console=ttyS0 noapic=1 panic=1' patched
qemu boots up successfully with -icount, whereas unpatched qemu loops
infinitely.
Looks like APIC emulation issue to me.
I'm trying to test issue using a 2.6.38 vmlinuz image.
The
On 11/09/2011 09:03 AM, Aneesh Kumar K.V wrote:
On Tue, 8 Nov 2011 16:23:50 +0200, Avi Kivity a...@redhat.com wrote:
Modern distributions place xattr.h in /usr/include/sys, and fold
libattr.so into libc. They also don't have an ENOATTR.
Make configure detect this, and add a
Am 09.11.2011 06:58, schrieb Stefan Weil:
Am 09.11.2011 02:38, schrieb Alexander Graf:
Commit 79627472db3 introduced breakage in compiling the s390x-softmmu
target. Instead of compiling, it just throws a lot of errors:
In file included from /dev/shm/qemu/hw/pci-stub.c:24:
./qmp-commands.h:3:
Modern distributions place xattr.h in /usr/include/sys, and fold
libattr.so into libc. They also don't have an ENOATTR.
Make configure detect this, and add a qemu-xattr.h file that
directs the #include to the right place.
Signed-off-by: Avi Kivity a...@redhat.com
---
v2: try for libc first,
Am 09.11.2011 15:53, schrieb Benjamin:
On 11/09/11 15:26, Benjamin wrote:
Oh, I forgot to remove a line from the old patch, when I wanted to
introduce -netdev udp. Now it's just -net[dev] socket.
Here's the updated patch, my apologies.
It didn't break anything, it's just useless, use this
On 11/09/2011 05:41 PM, Cao,Bing Bu wrote:
On 11/08/2011 11:52 PM, Max Filippov wrote:
With kernel command line of 'console=ttyS0 noapic=1 panic=1' patched
qemu boots up successfully with -icount, whereas unpatched qemu loops
infinitely.
Looks like APIC emulation issue to me.
I'm trying to
When with option -icount,kernel message:
HPET counter not counting. HPET disabled
For the HPET please try this patch:
http://lists.nongnu.org/archive/html/qemu-devel/2011-11/msg01109.html
Maybe right,it is a ACPI issue.
I was actually talkin about the APIC one, but well, there are 24
On Wed, 09 Nov 2011 11:40:01 +0100, Gerd Hoffmann wrote:
far I know it is pretty much impossible to figure the
foreground/background colors of the terminal you are running on. You
can try some guesswork based on $TERM (linux console usually has black
background, xterm is white by
Hi,
What we want to have is to have a set of distinctive colors - just
two (background, foreground) colors are not enough - we also need
colors to highlight certain information - we need 5-6 colors for the
output to be maximally expressive. Is there a canonical way to handle
that while
On Wed, 9 Nov 2011 12:33:58 +0200, Avi Kivity a...@redhat.com wrote:
Modern distributions place xattr.h in /usr/include/sys, and fold
libattr.so into libc. They also don't have an ENOATTR.
Make configure detect this, and add a qemu-xattr.h file that
directs the #include to the right place.
The non-dynticks timer variations are broken, so they can be
removed.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-timer.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/qemu-timer.c b/qemu-timer.c
index f11a28d..cd026c6 100644
--- a/qemu-timer.c
+++
On Wed, 09 Nov 2011 17:14:23 +0530, Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
On Wed, 9 Nov 2011 12:33:58 +0200, Avi Kivity a...@redhat.com wrote:
Modern distributions place xattr.h in /usr/include/sys, and fold
libattr.so into libc. They also don't have an ENOATTR.
Make
Em Wed, Nov 09, 2011 at 11:40:01AM +0100, Gerd Hoffmann escreveu:
Hi,
What we want to have is to have a set of distinctive colors - just
two (background, foreground) colors are not enough - we also need
colors to highlight certain information - we need 5-6 colors for the
output to
Em Wed, Nov 09, 2011 at 10:21:09AM +0100, Ingo Molnar escreveu:
Eventually someone will do the right thing and implement 'perf trace'
(there's still the tip:tmp.perf/trace2 prototype branch) and users
I'm working on it, reworking its patches into the new evlist/evsel
abstractions, etc.
-
Public bug reported:
Tried to boot 6.1 guest on hs22 blade with/without vhost enabled.
With vhost enabled, guest aborted with core dump.
installed guest with autotest.
Command :
/usr/local/bin/qemu-system-x86_64 -name 'vm1' -nodefaults -vga std -monitor
Hi,
Plus allowing full .perfconfig configurability of all the relevant
colors, for those with special taste.
Sure. Maybe also allow multiple color sections and pick them by $TERM
or --colors switch, i.e. [colors xterm].
Its fully configurable as of now, what we need is a set of
Em Wed, Nov 09, 2011 at 01:26:34PM +0100, Gerd Hoffmann escreveu:
Hi,
Plus allowing full .perfconfig configurability of all the relevant
colors, for those with special taste.
Sure. Maybe also allow multiple color sections and pick them by $TERM
or --colors switch, i.e. [colors
On 11/04/11 10:34, Markus Armbruster wrote:
Spotted by Coverity.
Patch added to spice patch queue.
thanks,
Gerd
Em Wed, Nov 09, 2011 at 10:30:50AM -0200, Arnaldo Carvalho de Melo escreveu:
Em Wed, Nov 09, 2011 at 01:26:34PM +0100, Gerd Hoffmann escreveu:
Its fully configurable as of now, what we need is a set of .perfconfigs
that show how people think its better, we try it, set it as the default,
On 11/09/2011 01:44 PM, Aneesh Kumar K.V wrote:
On Wed, 9 Nov 2011 12:33:58 +0200, Avi Kivity a...@redhat.com wrote:
Modern distributions place xattr.h in /usr/include/sys, and fold
libattr.so into libc. They also don't have an ENOATTR.
Make configure detect this, and add a
I usually use qemu-system-arm only binary, and use the vexpress board.
Screendump wasn't implemented for the pl110 lcd driver of vexpress board.
So I implemented this. I simply make a call to ppm_save. It is simple,
and it works.
The bad point is that in qemu, actually, there is 2 functions
Modern distributions place xattr.h in /usr/include/sys, and fold
libattr.so into libc. They also don't have an ENOATTR.
Make configure detect this, and add a qemu-xattr.h file that
directs the #include to the right place.
Signed-off-by: Avi Kivity a...@redhat.com
---
v3: fix misspelling of
On Wed, 2011-11-09 at 10:33 -0200, Arnaldo Carvalho de Melo wrote:
Ingo, would that G+ page be useful for that?
*groan*
Can we please keep things sane?
On Wed, 09 Nov 2011 11:27:22 +0100
Andreas Färber afaer...@suse.de wrote:
Am 09.11.2011 06:58, schrieb Stefan Weil:
Am 09.11.2011 02:38, schrieb Alexander Graf:
Commit 79627472db3 introduced breakage in compiling the s390x-softmmu
target. Instead of compiling, it just throws a lot of
Em Wed, Nov 09, 2011 at 01:46:42PM +0100, Peter Zijlstra escreveu:
On Wed, 2011-11-09 at 10:33 -0200, Arnaldo Carvalho de Melo wrote:
Ingo, would that G+ page be useful for that?
*groan*
Can we please keep things sane?
ROFL, I had to ask that :-P
- Arnaldo
2011/11/9 ad...@mmri.us ad...@mmri.us:
qemu-users is dead.
You subscribe and nothing happens.
You mean http://tech.groups.yahoo.com/group/qemu-users/ is dead?
Try https://lists.nongnu.org/mailman/listinfo/qemu-discuss , then. :-)
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab,
The cpu capabilities passed by the elf loader in AT_HWCAP where
a constant.
Make AT_HWCAP reflect the emulated cpu features in order to give
correct clues to eglibc.
Fix : [Bug 887516] [NEW] VFP support reported for the PXA270
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
A VFP was detected for pxa270 causing an Illegal instruction
exception.
The eglibc was not receiving the right AT_HWCAP from elfloader.c.
Benoît Canet (1):
arm-linux-user: fix elfload.c's AT_HWCAP reflected cpu features.
linux-user/elfload.c | 31 +++
1 files
* Arnaldo Carvalho de Melo a...@redhat.com wrote:
Em Wed, Nov 09, 2011 at 10:30:50AM -0200, Arnaldo Carvalho de Melo escreveu:
Em Wed, Nov 09, 2011 at 01:26:34PM +0100, Gerd Hoffmann escreveu:
Its fully configurable as of now, what we need is a set of .perfconfigs
that show how people
Am 09.11.2011 14:04, schrieb Benoît Canet:
The cpu capabilities passed by the elf loader in AT_HWCAP where
a constant.
Make AT_HWCAP reflect the emulated cpu features in order to give
correct clues to eglibc.
Fix : [Bug 887516] [NEW] VFP support reported for the PXA270
Signed-off-by:
The cpu capabilities passed by the elf loader in AT_HWCAP where
a constant.
Make AT_HWCAP reflect the emulated cpu features in order to give
correct clues to eglibc.
Fix : [Bug 887516] [NEW] VFP support reported for the PXA270
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
A VFP was detected for pxa270 causing an Illegal instruction
exception.
The eglibc was not receiving the right AT_HWCAP from elfloader.c.
This version fix typos.
Benoît Canet (1):
arm-linux-user: fix elfload.c's AT_HWCAP to reflect cpu features.
linux-user/elfload.c | 31
This allows us to reduce the size of the surfaces bar minimally while
not breaking current drivers. To completely disable the bar, or make it
zero sized, would break them.
Signed-off-by: Alon Levy al...@redhat.com
---
Causes endless ooms for the linux driver, but it's mainly meant for the
windows
On Tue, Nov 8, 2011 at 5:32 PM, Ingo Molnar mi...@elte.hu wrote:
So i think you should seriously consider moving your projects *into*
tools/ instead of trying to get other projects to move out ...
You should at least *try* the unified model before criticising it -
because currently you guys
The fact that a host cpu supports a feature doesn't mean that QEMU and KVM
will also support it, yet -cpuid host brings host features wholesale.
We need to whitelist each feature separately to make sure we support it.
This patch adds KVM whitelisting (by simply using KVM_GET_SUPPORTED_CPUID
I assume ELF_HWCAP is being used in architecture-independent code? Or
would it be feasible to replace all occurrences with the function call?
Many architecture in elfloader.c hardcode ELF_HWCAP before putting into the
AT_HWCAP elf field which is used by glibc to guess the cpu capabilities.
I
2011/11/9 Benoît Canet benoit.ca...@gmail.com:
+static uint32_t get_elf_hwcap(void)
+{
+ CPUState *e = thread_env;
+ uint32_t hwcaps = 0;
+
+ hwcaps |= ARM_HWCAP_ARM_SWP;
+ hwcaps |= ARM_HWCAP_ARM_HALF;
+ hwcaps |= ARM_HWCAP_ARM_THUMB;
+ hwcaps |=
Just realised i made the patch a bit too fast and added a caracter on top
of console.c when reviewing code...
here is the correct patch.
Regards,
Quentin
Signed-off-by: Quentin Deldycke quentindeldy...@gmail.com
---
console.c | 45 +
2011/11/9 Andreas Färber afaer...@suse.de:
I'm wondering if this translation table were better placed in
target-arm/helper.c where we fiddle with the features in the first
place. We could loop through all features here and call a function that
returns the hwcap or 0 and |= it. Me and others
Am 27.10.2011 10:52, schrieb Dong Xu Wang:
Provide a new file format: add-cow. The usage can be found in add-cow.txt of
this patch.
Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com
---
Makefile.objs |1 +
block.c|2 +-
block.h|1
Just realised i made the patch a bit too fast and added a caracter on top
of console.c when reviewing code...
here is the correct patch.
Why do we need any device specfic code for this?
Surely the console layer is the only thing that needs to care, and should just
make the appropriate set
On 11/08/2011 11:19 AM, Avi Kivity wrote:
On 11/08/2011 05:32 PM, Anthony Liguori wrote:
If the question is, how do we restore the immutable state, that should
be happening as part of device creation, no?
The way I see it, we create a link between some device state (a
register) and a
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
target-arm/cpu.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index c4d742f..e51bc8a 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -353,6 +353,8 @@ enum arm_cpu_mode {
The cpu capabilities passed by the elf loader in AT_HWCAP where
a constant.
Make AT_HWCAP reflect the emulated cpu features in order to give
correct clues to eglibc.
Fix : [Bug 887516] [NEW] VFP support reported for the PXA270
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
A VFP was detected for pxa270 causing an Illegal instruction
exception.
The eglibc was not receiving the right AT_HWCAP from elfloader.c.
In this version (Andreas and Peter comments)
rename GET_FEATURE macro to SET_HWCAP
remove wrong VFP_FP16 to VFPv3-D16 mapping
remove unconditional
Am 09.11.2011 15:06, schrieb Peter Maydell:
2011/11/9 Andreas Färber afaer...@suse.de:
I'm wondering if this translation table were better placed in
target-arm/helper.c where we fiddle with the features in the first
place. We could loop through all features here and call a function that
2011/11/9 Benoît Canet benoit.ca...@gmail.com:
+/* remember to update linux-user/elfload.c get_elf_hwcap arm's
+ * version when adding a feature */
/* If adding a feature bit which corresponds to a Linux ELF
* HWCAP bit, remember to update the feature-bit-to-hwcap
* mapping in
2011/11/9 Benoît Canet benoit.ca...@gmail.com:
+ SET_HWCAP(ARM_FEATURE_V5, ARM_HWCAP_ARM_EDSP);
You've dropped the comment I suggested to go with this one.
-- PMM
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
target-arm/cpu.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index c4d742f..6639c2e 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -353,6 +353,10 @@ enum
The cpu capabilities passed by the elf loader in AT_HWCAP where
a constant.
Make AT_HWCAP reflect the emulated cpu features in order to give
correct clues to eglibc.
Fix : [Bug 887516] [NEW] VFP support reported for the PXA270
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
A VFP was detected for pxa270 causing an Illegal instruction
exception.
The eglibc was not receiving the right AT_HWCAP from elfloader.c.
In this version :
Fix reminder
Add comment regarding ARM_FEATURE_V5 to ARM_HWCAP_ARM_EDSP mapping
Benoît Canet (2):
arm-linux-user: fix elfload.c's AT_HWCAP
On 11/09/2011 04:40 PM, Anthony Liguori wrote:
typedef struct {
SysBusDevice busdev;
uint32_t memsz;
MemoryRegion flash;
bool flash_mapped;
Both flash.has_parent and flash_mapped are slaved to a bit of one of the
registers below.
uint32_t cm_osc;
uint32_t cm_ctrl;
On 9 November 2011 15:05, Avi Kivity a...@redhat.com wrote:
On 11/09/2011 04:40 PM, Anthony Liguori wrote:
typedef struct {
SysBusDevice busdev;
uint32_t memsz;
MemoryRegion flash;
bool flash_mapped;
Both flash.has_parent and flash_mapped are slaved to a bit of one of the
On 11/09/2011 05:20 PM, Peter Maydell wrote:
From a really quick glance at Avi's memory/mutators branch I think
the long term plan would be that rather than mapping/unmapping the
region we just call memory_region_set_enabled() which would cope
happily with being asked to enable an
Hi,
I've created a Google+ page for QEMU[1]. You'll also notice a button on the
qemu.org wiki that links to the Google+ page.
I'll be posting release information to this page along with any QEMU news. If
you find qemu-devel too busy to follow, then following the G+ page might be a
good
Am 09.11.2011 16:02, schrieb Benoît Canet:
The cpu capabilities passed by the elf loader in AT_HWCAP where
were
a constant.
Make AT_HWCAP reflect the emulated cpu features in order to give
correct clues to eglibc.
Fix : [Bug 887516] [NEW] VFP support reported for the PXA270
On 11/9/2011 at 02:46 AM, in message 4eba4bec.5040...@redhat.com, Kevin
Wolf
kw...@redhat.com wrote:
Am 08.11.2011 20:25, schrieb Charles Arnold:
The Data Offset field in the Dynamic Disk Header is an 8 byte field.
Although the specification (2006-10-11) gives an example of initializing
The cpu capabilities passed by the elf loader in AT_HWCAP where
a constant.
Make AT_HWCAP reflect the emulated cpu features in order to give
correct clues to eglibc.
Fix : [Bug 887516] [NEW] VFP support reported for the PXA270
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
target-arm/cpu.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index c4d742f..6639c2e 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -353,6 +353,10 @@ enum
A VFP was detected for pxa270 causing an Illegal instruction
exception.
The eglibc was not receiving the right AT_HWCAP from elfloader.c.
In this version :
Fix macro coding style issue
Benoît Canet (2):
arm-linux-user: fix elfload.c's AT_HWCAP to reflect cpu features.
target-arm: remind to
On 9 November 2011 15:34, Andreas Färber afaer...@suse.de wrote:
Am 09.11.2011 16:02, schrieb Benoît Canet:
+#define SET_HWCAP(feat, hwcap) \
+ do {if (arm_feature(e, feat)) { hwcaps |= hwcap; } } while (0)
Small nit: I notice there's a space missing after do {.
I wonder if Coding Style
On 11/09/2011 09:05 AM, Avi Kivity wrote:
On 11/09/2011 04:40 PM, Anthony Liguori wrote:
typedef struct {
SysBusDevice busdev;
uint32_t memsz;
MemoryRegion flash;
bool flash_mapped;
Both flash.has_parent and flash_mapped are slaved to a bit of one of the
registers below.
Am 09.11.2011 16:42, schrieb Charles Arnold:
On 11/9/2011 at 02:46 AM, in message 4eba4bec.5040...@redhat.com, Kevin
Wolf
kw...@redhat.com wrote:
Am 08.11.2011 20:25, schrieb Charles Arnold:
The Data Offset field in the Dynamic Disk Header is an 8 byte field.
Although the specification
On 11/09/2011 05:49 PM, Anthony Liguori wrote:
VMSTATE_MEMORY_REGION(integratorcm, flash),
Therefore this line is 100% redundant.
Yes, but the problem is that it's not obvious *why*. That's what I'm
trying to get at here. If you have a VMSTATE_MEMORY_REGION() that has
all of it's fields
This is fixed by commits 754fd932/8a5f7b03a/b3c4bbe5 in master, and this
fix will go into QEMU 1.0.
** Changed in: qemu
Status: New = Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Am 09.11.2011 16:42, schrieb Charles Arnold:
On 11/9/2011 at 02:46 AM, in message 4eba4bec.5040...@redhat.com, Kevin
Wolf
kw...@redhat.com wrote:
Am 08.11.2011 20:25, schrieb Charles Arnold:
The Data Offset field in the Dynamic Disk Header is an 8 byte field.
Although the specification
We've identified that the following commit resolved the issue
commit 47113ab6b8c5659ad94c69aacca572f731ebb0ac
Author: Wen Congyang we...@cn.fujitsu.com
Date: Fri Nov 4 10:45:58 2011 +0800
reenable vm_clock when resuming all vcpus
We disable vm_clock when pausing all vcpus,
We seriously miss having a logo.
El 09/11/2011, a las 15:24, Anthony Liguori escribió:
Hi,
I've created a Google+ page for QEMU[1]. You'll also notice a button on the
qemu.org wiki that links to the Google+ page.
I'll be posting release information to this page along with any QEMU
On 9 November 2011 15:56, Avi Kivity a...@redhat.com wrote:
On 11/09/2011 05:49 PM, Anthony Liguori wrote:
Avi wrote:
clear-on-read mask
Really? Is that all that common outside of PCI config?
Yes, ISR fields often have it (like virtio).
Write-one-to-clear is pretty popular too.
-- PMM
** Summary changed:
- Qemu master branch - RHEL 6.1 guest failing to start network
+ Qemu master branch - RHEL 6.1 guest fails to boot
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/886255
Title:
On Tue, Nov 08, 2011 at 11:24:30AM -0600, Anthony Liguori wrote:
On 11/03/2011 09:45 PM, Wen Congyang wrote:
We disable vm_clock when pausing all vcpus, but we forget to
reenable it when resuming all vcpus. It will cause that the
guest can not be rebooted.
Signed-off-by: Wen
On 11/09/2011 10:04 AM, Natalia Portillo wrote:
We seriously miss having a logo.
Yes, I'll announce something about that tomorrow ;-)
Regards,
Anthony Liguori
El 09/11/2011, a las 15:24, Anthony Liguori escribió:
Hi,
I've created a Google+ page for QEMU[1]. You'll also notice a button
Hi guys, here I am, reporting yet another issue with qemu. This time,
it's something that was first reported in January, and Juan proposed a
patch for it:
http://comments.gmane.org/gmane.comp.emulators.qemu/89009
[PATCH 4/5] Reopen files after migration
The symptom is, when running disk
On 11/9/2011 at 08:58 AM, in message 4ebaa30d.1090...@redhat.com, Kevin
Wolf
kw...@redhat.com wrote:
Right, I'm not arguing that your change is wrong. What I'm asking for is
just something like:
-dyndisk_header-data_offset = be64_to_cpu(0x);
+/* Note: The spec is
Am 09.11.2011 17:32, schrieb Charles Arnold:
On 11/9/2011 at 08:58 AM, in message 4ebaa30d.1090...@redhat.com, Kevin
Wolf
kw...@redhat.com wrote:
Right, I'm not arguing that your change is wrong. What I'm asking for is
just something like:
-dyndisk_header-data_offset =
On 11/09/2011 10:29 AM, Lucas Meneghel Rodrigues wrote:
Hi guys, here I am, reporting yet another issue with qemu. This time, it's
something that was first reported in January, and Juan proposed a patch for it:
http://comments.gmane.org/gmane.comp.emulators.qemu/89009
Migration with qcow2 is
Public bug reported:
Hi guys, here I am, reporting yet another issue with qemu. This time,
it's something that was first reported in January, and Juan proposed a
patch for it:
http://comments.gmane.org/gmane.comp.emulators.qemu/89009
[PATCH 4/5] Reopen files after migration
The symptom is,
Am 09.11.2011 17:32, schrieb Charles Arnold:
On 11/9/2011 at 08:58 AM, in message 4ebaa30d.1090...@redhat.com, Kevin
Wolf
kw...@redhat.com wrote:
Right, I'm not arguing that your change is wrong. What I'm asking for is
just something like:
-dyndisk_header-data_offset =
On 11/09/2011 06:39 PM, Anthony Liguori wrote:
Migration with qcow2 is not a supported feature for 1.0. Migration is
only supported with raw images using coherent shared storage[1].
[1] NFS is only coherent with close-to-open which right now is not
good enough for migration.
Say what?
--
A VFP was detected for pxa270 causing an Illegal instruction
exception.
The eglibc was not receiving the right AT_HWCAP from elfloader.c.
In this version :
Fix macro coding style issue
Benoît Canet (2):
arm-linux-user: fix elfload.c's AT_HWCAP to reflect cpu features.
target-arm: remind to
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
target-arm/cpu.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index c4d742f..6639c2e 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -353,6 +353,10 @@ enum
The cpu capabilities passed by the elf loader in AT_HWCAP were
a constant.
Make AT_HWCAP reflect the emulated cpu features in order to give
correct clues to eglibc.
Fix : [Bug 887516] [NEW] VFP support reported for the PXA270
Signed-off-by: Benoit Canet benoit.ca...@gmail.com
---
On Tue, Nov 8, 2011 at 12:57, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
Obviously passthrough cannot work without this patch, but qemu should be
able to compile anyway. Please add to the previous patch empty stub
implementations for all the exported functions that you are going
Am 09.11.2011 18:03, schrieb Benoît Canet:
The cpu capabilities passed by the elf loader in AT_HWCAP were
a constant.
Make AT_HWCAP reflect the emulated cpu features in order to give
correct clues to eglibc.
Fix : [Bug 887516] [NEW] VFP support reported for the PXA270
Signed-off-by:
1 - 100 of 218 matches
Mail list logo
