On Wed, 9 Nov 2011 11:55:51 +0530, Harsh Prateek Bora
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:
>
> RERROR (tag = 1
* 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 have to disagree; my main worry is that integration mak
* Ted Ts'o 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 familia
* John Kacur 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 h
On 11/09/2011 01:43 PM, Aneesh Kumar K.V wrote:
On Wed, 9 Nov 2011 11:55:51 +0530, Harsh Prateek
Bora 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
Just for cleanliness; it would take a truly gigantic cursor to break.
Signed-off-by: Markus Armbruster
---
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
--- a/hw/qxl-render.c
+++ b/hw/qxl-
* Gerd Hoffmann 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 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 colors I
* Steven Rostedt 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 and
> > res
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 t
On Wed, Nov 9, 2011 at 5:14 AM, Deepak Shetty 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 mail. Please
On Wed, Nov 9, 2011 at 1:09 AM, Rob White 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 to submit pa
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-tes
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
> ---
> ui/vnc-auth-sasl.c | 19 +--
> 1 files changed, 5 insertions(+)
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 chan
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
> ---
> hw/qxl-render.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks, applied to the trivial pa
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 i
On 11/09/2011 09:03 AM, Aneesh Kumar K.V wrote:
> On Tue, 8 Nov 2011 16:23:50 +0200, Avi Kivity 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
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-com
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
---
v2: try for libc first, libattr second
c
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
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 te
> 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
ana
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 de
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 w
On Wed, 9 Nov 2011 12:33:58 +0200, Avi Kivity 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.
>
> Signe
The non-dynticks timer variations are broken, so they can be
removed.
Signed-off-by: Paolo Bonzini
---
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
+++ b/qemu-timer.c
@@ -183,
On Wed, 09 Nov 2011 17:14:23 +0530, "Aneesh Kumar K.V"
wrote:
> On Wed, 9 Nov 2011 12:33:58 +0200, Avi Kivity 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 qe
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
> > o
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.
- Ar
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
unix:'/tmp/monitor-humanmonitor1-2
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
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
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 defaul
On 11/09/2011 01:44 PM, Aneesh Kumar K.V wrote:
> On Wed, 9 Nov 2011 12:33:58 +0200, Avi Kivity 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
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
ppm_s
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
---
v3: fix misspelling of "qemu-xattr.h"
v2:
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 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 errors:
> >>
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 :
> 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, Institute of
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
---
linux-user/elfload.c | 31 +++
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 ch
* Arnaldo Carvalho de Melo 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 thin
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
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
---
linux-user/elfload.c | 31 +++
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
---
Causes endless ooms for the linux driver, but it's mainly meant for the
windows driver, where it
On Tue, Nov 8, 2011 at 5:32 PM, Ingo Molnar 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 are prea
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
instea
> 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 :
> +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 |= ARM_HWCAP_ARM_FAST_MULT;
> + hwcap
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
---
console.c | 45 +
console.h |2 ++
hw/omap
2011/11/9 Andreas Färber :
> 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 will be adding
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
> ---
> Makefile.objs |1 +
> block.c|2 +-
> block.h|1 +
> block/add-cow.
> 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 se
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 memory
Signed-off-by: Benoit Canet
---
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 {
#define ARM_IWMMXT_wC
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
---
linux-user/elfload.c | 38 +++
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 ARM_HWCAP_A
Am 09.11.2011 15:06, schrieb Peter Maydell:
> 2011/11/9 Andreas Färber :
>> 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 h
2011/11/9 Benoît Canet :
> +/* 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 linux-user/elfload.c:get_elf_hwcap()
2011/11/9 Benoît Canet :
> + 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
---
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 arm_cpu_mode {
#define ARM_IWMMXT
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
---
linux-user/elfload.c | 43 +++
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_HWCA
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 c
On 9 November 2011 15:05, 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
>
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 already-e
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 opt
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
>
> Sig
>>> On 11/9/2011 at 02:46 AM, in message <4eba4bec.5040...@redhat.com>, Kevin
>>> Wolf
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
>> only
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
---
linux-user/elfload.c | 46 +++
Signed-off-by: Benoit Canet
---
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 arm_cpu_mode {
#define ARM_IWMMXT
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 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 applies to
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
> 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
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.
https://bugs.launchpad.net/b
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
> 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
Date: Fri Nov 4 10:45:58 2011 +0800
reenable vm_clock when resuming all vcpus
We disable vm_clock when pausing all vcpus, but we forget to
r
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 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:
Q
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 Congy
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 stres
>>> On 11/9/2011 at 08:58 AM, in message <4ebaa30d.1090...@redhat.com>, Kevin
>>> Wolf
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 actually
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
> 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_c
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 n
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, when
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
> 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_c
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
---
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 arm_cpu_mode {
#define ARM_IWMMXT
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
---
linux-user/elfload.c | 46
On Tue, Nov 8, 2011 at 12:57, Stefano Stabellini
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 to
> implement here.
>
> I se
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-
1 - 100 of 218 matches
Mail list logo
