On 10/04/2011 07:55 AM, Stefan Weil wrote:
I learned now that ppc will need flush_icache_range() for kvm, too.
So it won't be possible to implement a uniform handling of
flush_icache_range() for all host architectures.
x86 and IIRC s390 flush_icache_range is a no-op, so it is possible to
"call
> Not doing it sometimes invokes crash penalties for us. :-)
>
> We could add some way to skip the invalidation if we know the host is an
> implementation that doesn't need it, possibly depending on the context
> (is it just DMA he wants to avoid doing this on[1], or do their chips
> have a fully
Am 03.10.2011 23:40, schrieb Scott Wood:
On 10/03/2011 04:10 PM, Stefan Weil wrote:
Am 03.10.2011 22:52, schrieb Scott Wood:
On 10/03/2011 03:43 PM, Stefan Weil wrote:
qemu_cache_utils_init() is only used by ppc / ppc64 tcg targets
to initialize the cache before flush_icache_range() is called.
Hi,
I tried executing QEMU (realview-smp ARM11MPCore) with Linux kernel 2.6.39.3,
but it failed. Kernel itself is not getting decompressed.
I am executing below command.
qemu-system-arm -M realview-eb-mpcore -cpu arm11mpcore -kernel
arch/arm/boot/zImage -m 256M -append "root=/dev/sda conso
The Buildbot has detected a new failure on builder xen_x86_64_debian_6_0 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/xen_x86_64_debian_6_0/builds/50
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
Build Rea
The Buildbot has detected a new failure on builder xen_i386_debian_6_0 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/xen_i386_debian_6_0/builds/50
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
Build Reason:
The Buildbot has detected a new failure on builder qmp_x86_64_debian_6_0 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/qmp_x86_64_debian_6_0/builds/50
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
Build Rea
The Buildbot has detected a new failure on builder qmp_i386_debian_6_0 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/qmp_i386_debian_6_0/builds/50
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
Build Reason:
Hi
Please send in any agenda items you are interested in covering.
Thanks, Juan.
I am investigating how QEMU block devices are emulated. It seems that qemu
has an important structure BlockDeviceState and I suspect the file field in
the structure points to the file qemu uses to emulate a disk. Am I right ?
Thanks
Xin
The Buildbot has detected a new failure on builder
disable_kvm_x86_64_out_of_tree while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/disable_kvm_x86_64_out_of_tree/builds/237
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Buil
The Buildbot has detected a new failure on builder disable_kvm_i386_out_of_tree
while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/disable_kvm_i386_out_of_tree/builds/237
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: y
The Buildbot has detected a new failure on builder
disable_kvm_x86_64_debian_6_0 while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/disable_kvm_x86_64_debian_6_0/builds/50
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build:
I am using qemu (kvm enabled) to debug linux, I set break-point on
schedule() ( a function i know that i can break on ) before the grub loads
the kernel. However, after the grub loads the kernel, the kernel does not
stop on that break-point. My theory is that I set the break-point before the
vmlin
The Buildbot has detected a new failure on builder default_i386_debian_6_0
while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_i386_debian_6_0/builds/50
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
Build
The Buildbot has detected a new failure on builder default_x86_64_fedora16
while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_x86_64_fedora16/builds/44
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: kraxel_fedora
The Buildbot has detected a new failure on builder default_openbsd_current
while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_openbsd_current/builds/50
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: brad_openbsd_
The Buildbot has detected a new failure on builder default_i386_rhel61 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_i386_rhel61/builds/43
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: kraxel_rhel61_32bit
On 03.10.2011, at 23:50, Scott Wood wrote:
> On 10/03/2011 04:36 PM, Alexander Graf wrote:
>> With TCG, we're never executing guest code directly, but always go
>> through TCG to emulate it. So the only case where we actually need to
>> flush the icache is in TCG code generation, never outside, r
The Buildbot has detected a new failure on builder default_x86_64_debian_6_0
while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_x86_64_debian_6_0/builds/50
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
B
On 10/03/2011 06:15 PM, q...@buildbot.b1-systems.de wrote:
The Buildbot has detected a new failure on builder default_openbsd_4.9 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_openbsd_4.9/builds/44
Buildbot URL: http://buildbot.b1-syst
On 10/03/2011 05:06 PM, Alexander Graf wrote:
>
> On 03.10.2011, at 23:50, Scott Wood wrote:
>
>> On 10/03/2011 04:36 PM, Alexander Graf wrote:
>>> With TCG, we're never executing guest code directly, but always go
>>> through TCG to emulate it. So the only case where we actually need to
>>> flus
On 04.10.2011, at 00:07, Scott Wood wrote:
> On 10/03/2011 05:06 PM, Alexander Graf wrote:
>>
>> On 03.10.2011, at 23:50, Scott Wood wrote:
>>
>>> On 10/03/2011 04:36 PM, Alexander Graf wrote:
With TCG, we're never executing guest code directly, but always go
through TCG to emulate it
The Buildbot has detected a new failure on builder default_x86_64_out_of_tree
while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_x86_64_out_of_tree/builds/236
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuk
The Buildbot has detected a new failure on builder default_openbsd_4.9 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_openbsd_4.9/builds/44
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: kraxel_openbsd49
Bui
The Buildbot has detected a new failure on builder default_mingw32 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_mingw32/builds/44
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: kraxel_rhel61
Build Reason:
On Mon, 3 Oct 2011, Stefan Weil wrote:
> qemu_cache_utils_init() is only used by ppc / ppc64 tcg targets
> to initialize the cache before flush_icache_range() is called.
>
> This patch moves the code to tcg/ppc and tcg/ppc64.
> Initialisation is called from tcg_target_init() there.
>
This can't
The Buildbot has detected a new failure on builder default_i386_out_of_tree
while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_i386_out_of_tree/builds/236
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
Bu
The Buildbot has detected a new failure on builder default_x86_64_rhel61 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_x86_64_rhel61/builds/44
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: kraxel_rhel61
Bu
On 03.10.2011, at 23:51, Scott Wood wrote:
> On 10/03/2011 04:43 PM, Alexander Graf wrote:
>>
>> On 03.10.2011, at 23:40, Scott Wood wrote:
>>
>>> On 10/03/2011 04:10 PM, Stefan Weil wrote:
Am 03.10.2011 22:52, schrieb Scott Wood:
> On 10/03/2011 03:43 PM, Stefan Weil wrote:
>> qem
On 10/03/2011 04:43 PM, Alexander Graf wrote:
>
> On 03.10.2011, at 23:40, Scott Wood wrote:
>
>> On 10/03/2011 04:10 PM, Stefan Weil wrote:
>>> Am 03.10.2011 22:52, schrieb Scott Wood:
On 10/03/2011 03:43 PM, Stefan Weil wrote:
> qemu_cache_utils_init() is only used by ppc / ppc64 tcg t
On 10/03/2011 04:36 PM, Alexander Graf wrote:
> With TCG, we're never executing guest code directly, but always go
> through TCG to emulate it. So the only case where we actually need to
> flush the icache is in TCG code generation, never outside, right?
Right.
> For KVM, I agree. We need some in
On 03.10.2011, at 23:40, Scott Wood wrote:
> On 10/03/2011 04:10 PM, Stefan Weil wrote:
>> Am 03.10.2011 22:52, schrieb Scott Wood:
>>> On 10/03/2011 03:43 PM, Stefan Weil wrote:
qemu_cache_utils_init() is only used by ppc / ppc64 tcg targets
to initialize the cache before flush_icache_
On 10/03/2011 04:10 PM, Stefan Weil wrote:
> Am 03.10.2011 22:52, schrieb Scott Wood:
>> On 10/03/2011 03:43 PM, Stefan Weil wrote:
>>> qemu_cache_utils_init() is only used by ppc / ppc64 tcg targets
>>> to initialize the cache before flush_icache_range() is called.
>>>
>>> This patch moves the cod
On 03.10.2011, at 23:10, Stefan Weil wrote:
> Am 03.10.2011 22:52, schrieb Scott Wood:
>> On 10/03/2011 03:43 PM, Stefan Weil wrote:
>>> qemu_cache_utils_init() is only used by ppc / ppc64 tcg targets
>>> to initialize the cache before flush_icache_range() is called.
>>>
>>> This patch moves the
Am 03.10.2011 22:43, schrieb Stefan Weil:
The code is unused since 8 years, so remove it.
Signed-off-by: Stefan Weil
---
linux-user/signal.c | 5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 89276eb..40c5eb1 100644
--- a/lin
Am 03.10.2011 22:52, schrieb Scott Wood:
On 10/03/2011 03:43 PM, Stefan Weil wrote:
qemu_cache_utils_init() is only used by ppc / ppc64 tcg targets
to initialize the cache before flush_icache_range() is called.
This patch moves the code to tcg/ppc and tcg/ppc64.
Initialisation is called from tc
From: "Liu, Jinsong"
KVM add emulation of lapic tsc deadline timer for guest.
This patch is co-operation work at qemu side.
Signed-off-by: Liu, Jinsong
Signed-off-by: Marcelo Tosatti
---
target-i386/cpu.h |4 +++-
target-i386/kvm.c | 14 ++
target-i386/machine.c |
The following changes since commit d11cf8cc80d946dfc9a23597cd9a0bb1c487cfa7:
etrax-dma: Remove bogus if statement (2011-10-03 10:20:13 +0200)
are available in the git repository at:
git://github.com/avikivity/qemu.git uq/master
Liu, Jinsong (1):
kvm: support TSC deadline MSR
target-i
On 10/03/2011 03:43 PM, Stefan Weil wrote:
> qemu_cache_utils_init() is only used by ppc / ppc64 tcg targets
> to initialize the cache before flush_icache_range() is called.
>
> This patch moves the code to tcg/ppc and tcg/ppc64.
> Initialisation is called from tcg_target_init() there.
>
> Signed
qemu_cache_utils_init() is only used by ppc / ppc64 tcg targets
to initialize the cache before flush_icache_range() is called.
This patch moves the code to tcg/ppc and tcg/ppc64.
Initialisation is called from tcg_target_init() there.
Signed-off-by: Stefan Weil
---
Makefile.objs |4
The code is unused since 8 years, so remove it.
Signed-off-by: Stefan Weil
---
linux-user/signal.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 89276eb..40c5eb1 100644
--- a/linux-user/signal.c
+++ b/linux-user/signa
These patches clean an issue which was discussed some weeks ago
(http://lists.nongnu.org/archive/html/qemu-devel/2011-09/msg02279.html):
Code which was only needed for the PPC* tcg targets
(flush_icache_range, qemu_cache_utils_init)
was defined in files used by all host architectures.
The 1st pat
Am 03.10.2011 22:05, schrieb Stefan Weil:
Am 16.09.2011 22:03, schrieb Stefan Weil:
These two patches fix a wrong gcc version test.
[PATCH 1/2] Move macro QEMU_GNUC_PREREQ to compiler.h
[PATCH 2/2] Fix and clean code which tests the gcc version
Ping? Maybe these patches can be applied via qem
One thing I forgot to mention is that this same guest image has no
problem when installed bare metal.
Kenton
On 10/3/2011 1:20 PM, Kenton Cabiness wrote:
In general, we have seen that during a reboot of a
running guest (by issuing a 'reboot' command in the
guest), the guest goes down normally,
Am 16.09.2011 22:03, schrieb Stefan Weil:
These two patches fix a wrong gcc version test.
[PATCH 1/2] Move macro QEMU_GNUC_PREREQ to compiler.h
[PATCH 2/2] Fix and clean code which tests the gcc version
Ping? Maybe these patches can be applied via qemu-trivial.
http://patchwork.ozlabs.org/pat
On 09/30/2011 10:26 AM, Stefan Hajnoczi wrote:
On Fri, Sep 30, 2011 at 11:39 AM, Stefan Hajnoczi
wrote:
QED's metadata caching strategy allows two parallel requests to race for
metadata lookup. The first one to complete will populate the metadata
cache and the second one will drop the data it
On Sun, Sep 25, 2011 at 10:47:46PM +0800, Liu, Jinsong wrote:
> Marcelo Tosatti wrote:
> > On Fri, Sep 23, 2011 at 04:25:51PM +0800, Liu, Jinsong wrote:
> >> Marcelo Tosatti wrote:
> >>> On Thu, Sep 22, 2011 at 04:55:52PM +0800, Liu, Jinsong wrote:
> > From 4d5b83aba40ce0d421add9a41a6c591a8590a
In general, we have seen that during a reboot of a
running guest (by issuing a 'reboot' command in the
guest), the guest goes down normally, but when coming
back up, during the udev phase, it takes anywhere from
a few seconds to a few hours to complete that part of the
boot. Then the guest seems
On 2011-10-03 18:33, Dr. David Alan Gilbert wrote:
> Make cpu_single_env thread local (Linux only for now)
> * Fixes some user space threading issues (esp those triggered
> by bug 823902)
>
> Against rev d11cf8cc..., tested on ARM user mode, and ARM Vexpress
> system mode (with Blue Swirl'
On 2011-10-03 19:30, Aneesh Kumar K.V wrote:
> On Mon, 03 Oct 2011 14:16:09 +0200, Jan Kiszka wrote:
> Non-text part: multipart/signed
>> On 2011-10-03 13:23, Harsh Prateek Bora wrote:
>>> SynthFS uses rwlocks, which raise the need of a generic QemuRWLock APIs.
>>> This patchset introduces the sam
On Mon, 03 Oct 2011 14:16:09 +0200, Jan Kiszka wrote:
Non-text part: multipart/signed
> On 2011-10-03 13:23, Harsh Prateek Bora wrote:
> > SynthFS uses rwlocks, which raise the need of a generic QemuRWLock APIs.
> > This patchset introduces the same making necessary changes to relevant code.
>
>
Hello
I am new to qemu and have a question regarding address mapping.
Can we change the virtual to physical mapping in qemu, in a particular
manner, for example, changing this mapping in a multi-core environment to
control their share? One possibility is adding page table. But I am not
sure.
If w
Public bug reported:
Create a ridiculously large qcow2 disk:
qemu-img create -f qcow2 test1.img $((2**63-513))
Attach it to a guest and try to use parted to partition it. This is
easy with virt-rescue: you just do:
virt-rescue test1.img
> parted /dev/vda mklabel gpt
<-- bang! qemu segfaults he
On Mon, Oct 03, 2011 at 11:05:02AM -0500, Anthony Liguori wrote:
> On 10/03/2011 10:45 AM, Michael S. Tsirkin wrote:
> >>BTW, putting this info properly into migration stats would probably
> >>be pretty useful.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >
> >Problem is adding anything to monitor
Make cpu_single_env thread local (Linux only for now)
* Fixes some user space threading issues (esp those triggered
by bug 823902)
Against rev d11cf8cc..., tested on ARM user mode, and ARM Vexpress
system mode (with Blue Swirl's fix from yesterday) - only
tested on Linux host. Lets me run
On Mon, Oct 03, 2011 at 11:05:02AM -0500, Anthony Liguori wrote:
> On 10/03/2011 10:45 AM, Michael S. Tsirkin wrote:
> >>BTW, putting this info properly into migration stats would probably
> >>be pretty useful.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >
> >Problem is adding anything to monitor
Add the new option [-n] for snapshot_blkdev to avoid the image creation.
The file provided as [new-image-file] is considered as already initialized
and will be used after passing a check for the backing file.
Signed-off-by: Federico Simoncelli
---
blockdev.c | 54 +
In some situations might be useful to let qemu use an image that was
prepared for a live snapshot.
The advantage is that creating the snapshot file outside of the qemu
process we can use the whole range of options provided by the format
(eg for qcow2: encryption, cluster_size and preallocation).
It
On 10/03/2011 09:15 AM, Michael S. Tsirkin wrote:
On Mon, Oct 03, 2011 at 08:43:54AM -0500, Anthony Liguori wrote:
Having the ability to ignore some fields is not enough.
But it is also really required.
I agree. It's the principle of being conservative in what you send and liberal
in what
On 10/03/2011 10:45 AM, Michael S. Tsirkin wrote:
BTW, putting this info properly into migration stats would probably
be pretty useful.
Regards,
Anthony Liguori
Problem is adding anything to monitor makes me worry
about future compatibility so much I usually just give up.
IMO we really need a
On 10/03/2011 10:58 AM, Michael S. Tsirkin wrote:
On Mon, Oct 03, 2011 at 10:44:45AM -0500, Anthony Liguori wrote:
Specifically
the case where first field in a sequence tells
you the meaning of the following ones?
Can you give me the example in ASN.1?
Regards,
Anthony Liguori
That would be
On Mon, Oct 03, 2011 at 10:44:45AM -0500, Anthony Liguori wrote:
> >>>Specifically
> >>>the case where first field in a sequence tells
> >>>you the meaning of the following ones?
> >>
> >>Can you give me the example in ASN.1?
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >
> >That would be a selecti
On Mon, Oct 03, 2011 at 10:00:48AM -0500, Anthony Liguori wrote:
> On 10/03/2011 09:41 AM, Michael S. Tsirkin wrote:
> >On Mon, Oct 03, 2011 at 08:51:10AM -0500, Anthony Liguori wrote:
> >>On 10/03/2011 08:38 AM, Michael S. Tsirkin wrote:
> >>>On Mon, Oct 03, 2011 at 07:55:48AM -0500, Anthony Liguo
On 10/03/2011 10:29 AM, Michael S. Tsirkin wrote:
On Mon, Oct 03, 2011 at 09:42:02AM -0500, Anthony Liguori wrote:
On 10/03/2011 09:11 AM, Michael S. Tsirkin wrote:
On Mon, Oct 03, 2011 at 08:43:54AM -0500, Anthony Liguori wrote:
visit_start_array(v, "entries", errp);
for (int i = 0; i
On Mon, Oct 03, 2011 at 09:56:47AM -0500, Anthony Liguori wrote:
> On 10/03/2011 09:18 AM, Michael S. Tsirkin wrote:
> >>skip_indefinite:
> >> while tag != CANARY:
> >> if tag == INT:
> >> visit_type_int(v, NULL, NULL, errp);
> >> elif tag == STRING:
> >> visit_type_str(v, NUL
On Mon, Oct 03, 2011 at 09:55:45AM -0500, Anthony Liguori wrote:
> How I see this all evolving in the future is that we would have a
> formal protocol specification. From that spec, we would generate
> Visitors. This would handle taking what's on the wire and building
> an in-memory tree. If an
On Mon, Oct 03, 2011 at 09:42:02AM -0500, Anthony Liguori wrote:
> On 10/03/2011 09:11 AM, Michael S. Tsirkin wrote:
> >On Mon, Oct 03, 2011 at 08:43:54AM -0500, Anthony Liguori wrote:
> visit_start_array(v, "entries", errp);
> for (int i = 0; i< s->size; i++) {
> visit_type_int(
On 10/03/2011 10:37 AM, Alon Levy wrote:
>
> Hi,
> won't there be an overhead for rendering on a non continuous
> surface? Will it be worthwhile comparing to not creating the
> surface?
If I use a scatter-gather list there is overhead of allocating and
copying the surface whenever I want to
hello
test with qemu-img from git tree with your patch for log :
DEV-10.98.98.1:~# /tmp/qemu-img convert -O qed
/mnt/disks/export/images/vm_import /mnt/disks/export-ns/test
qemu-img: error while reading bs_i 0 sector_num 5406720 bs_offset 0 n 4096:
Input/output error
Regards,
Nicolas
2011/10/3
On 10/03/2011 09:41 AM, Michael S. Tsirkin wrote:
On Mon, Oct 03, 2011 at 08:51:10AM -0500, Anthony Liguori wrote:
On 10/03/2011 08:38 AM, Michael S. Tsirkin wrote:
On Mon, Oct 03, 2011 at 07:55:48AM -0500, Anthony Liguori wrote:
On 10/02/2011 04:08 PM, Michael S. Tsirkin wrote:
On Sun, Oct 0
On 10/03/2011 09:18 AM, Michael S. Tsirkin wrote:
skip_indefinite:
while tag != CANARY:
if tag == INT:
visit_type_int(v, NULL, NULL, errp);
elif tag == STRING:
visit_type_str(v, NULL, NULL, errp);
elif tag == INDEFINITE:
visit_start_struct(v, NULL, NULL, err
On 10/03/2011 09:11 AM, Michael S. Tsirkin wrote:
On Mon, Oct 03, 2011 at 08:43:54AM -0500, Anthony Liguori wrote:
visit_start_array(v, "entries", errp);
for (int i = 0; i< s->size; i++) {
visit_type_int(v, NULL,&s->entry[i], errp);
}
visit_end_array(v, errp);
Sequences can encode struc
On Mon, Oct 03, 2011 at 08:51:10AM -0500, Anthony Liguori wrote:
> On 10/03/2011 08:38 AM, Michael S. Tsirkin wrote:
> >On Mon, Oct 03, 2011 at 07:55:48AM -0500, Anthony Liguori wrote:
> >>On 10/02/2011 04:08 PM, Michael S. Tsirkin wrote:
> >>>On Sun, Oct 02, 2011 at 04:21:47PM -0400, Stefan Berger
Indeed, the result is known to be always positive.
Signed-off-by: Christophe Lyon
---
target-arm/helper.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index d3a3ba2..ff5456c 100644
--- a/target-arm/helper.c
+++ b/target-arm/
On Mon, Oct 03, 2011 at 08:48:05AM -0500, Anthony Liguori wrote:
> On 10/03/2011 08:30 AM, Michael S. Tsirkin wrote:
> >On Mon, Oct 03, 2011 at 08:18:31AM -0500, Anthony Liguori wrote:
> >>On 10/03/2011 08:10 AM, Stefan Berger wrote:
> >>>I am doing that. Indefinite length encoding *would* be a pro
On Mon, Oct 03, 2011 at 08:43:54AM -0500, Anthony Liguori wrote:
> Having the ability to ignore some fields is not enough.
But it is also really required.
> We need to
> also be able to split a single field into multiple fields, and event
> split a single device into multiple devices. If we're d
On Mon, Oct 03, 2011 at 08:43:54AM -0500, Anthony Liguori wrote:
> >>visit_start_array(v, "entries", errp);
> >>for (int i = 0; i< s->size; i++) {
> >> visit_type_int(v, NULL,&s->entry[i], errp);
> >>}
> >>visit_end_array(v, errp);
> >
> >Sequences can encode structures not just arrays.
> >How
On 10/03/2011 08:38 AM, Michael S. Tsirkin wrote:
On Mon, Oct 03, 2011 at 07:55:48AM -0500, Anthony Liguori wrote:
On 10/02/2011 04:08 PM, Michael S. Tsirkin wrote:
On Sun, Oct 02, 2011 at 04:21:47PM -0400, Stefan Berger wrote:
4) Implement the BERVisitor and make this the default migration
On 10/03/2011 08:30 AM, Michael S. Tsirkin wrote:
On Mon, Oct 03, 2011 at 08:18:31AM -0500, Anthony Liguori wrote:
On 10/03/2011 08:10 AM, Stefan Berger wrote:
I am doing that. Indefinite length encoding *would* be a problem because you
cannot push the size onto the stack so that you could skip
On 10/03/2011 08:24 AM, Michael S. Tsirkin wrote:
On Mon, Oct 03, 2011 at 07:51:00AM -0500, Anthony Liguori wrote:
Here are some suggestions:
- Let's make the protocol be BER directly.
As a first step, use a single octet string for
the whole of data. Next, start splitting this up.
This
On Mon, Oct 03, 2011 at 07:55:48AM -0500, Anthony Liguori wrote:
> On 10/02/2011 04:08 PM, Michael S. Tsirkin wrote:
> >On Sun, Oct 02, 2011 at 04:21:47PM -0400, Stefan Berger wrote:
> >>
> >>>4) Implement the BERVisitor and make this the default migration protocol.
> >>>
> >>>Most of the work will
On Mon, Oct 3, 2011 at 2:01 PM, nicolas prochazka
wrote:
> sorry to bother you, i send dump of two qemu-io command .
> What can I do with this result ?
The qemu-io -c read command was successful. This means that the I/O
error was triggered by the specific request that qemu-img convert
issued, no
Hi Anthony,
> Please publish a git URI. Fetching over HTTP is painful, particularly when
> the connection to the server isn't very good.
The following changes since commit d11cf8cc80d946dfc9a23597cd9a0bb1c487cfa7:
etrax-dma: Remove bogus if statement (2011-10-03 10:20:13 +0200)
are available
On Mon, Oct 03, 2011 at 08:18:31AM -0500, Anthony Liguori wrote:
> On 10/03/2011 08:10 AM, Stefan Berger wrote:
> >I am doing that. Indefinite length encoding *would* be a problem because you
> >cannot push the size onto the stack so that you could skip to the end of the
> >structure.
>
> For an i
On Mon, Oct 03, 2011 at 07:51:00AM -0500, Anthony Liguori wrote:
> >Here are some suggestions:
> >
> >- Let's make the protocol be BER directly.
> > As a first step, use a single octet string for
> > the whole of data. Next, start splitting this up.
>
> This can't be done without breaking the
On 10/03/2011 08:10 AM, Stefan Berger wrote:
I am doing that. Indefinite length encoding *would* be a problem because you
cannot push the size onto the stack so that you could skip to the end of the
structure.
For an indefinite length encoding, you just have to keep reading the stream at
end_s
On 10/02/2011 07:14 AM, Michael S. Tsirkin wrote:
On Sun, Oct 02, 2011 at 02:01:10PM +0200, Avi Kivity wrote:
Hmm, not entirely virtio specific, some devices use stX macros to do the
conversion. E.g. stw_be_phys and stl_le_phys are used in several
places.
These are fine - explicit endianness.
Simple implementation of an stdio char device on Windows.
Signed-off-by: Fabien Chouteau
---
qemu-char.c | 227 ++-
1 files changed, 225 insertions(+), 2 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 09d2309..226ba27 100644
--
On 10/02/2011 05:25 AM, Michael S. Tsirkin wrote:
On Mon, Sep 05, 2011 at 02:34:56PM +1000, David Gibson wrote:
This patch adds functions to pci.[ch] to perform PCI DMA operations. At
present, these are just stubs which perform directly cpu physical memory
accesses.
Using these stubs, however,
On 10/03/2011 08:55 AM, Anthony Liguori wrote:
On 10/02/2011 04:08 PM, Michael S. Tsirkin wrote:
On Sun, Oct 02, 2011 at 04:21:47PM -0400, Stefan Berger wrote:
4) Implement the BERVisitor and make this the default migration
protocol.
Most of the work will be in 1), though with the implement
On 10/02/2011 04:08 PM, Michael S. Tsirkin wrote:
On Sun, Oct 02, 2011 at 04:21:47PM -0400, Stefan Berger wrote:
4) Implement the BERVisitor and make this the default migration protocol.
Most of the work will be in 1), though with the implementation in this series
we should be able to do it
On 10/03/2011 01:46 AM, Michael S. Tsirkin wrote:
On Mon, Sep 19, 2011 at 09:41:41AM -0500, Michael Roth wrote:
OVERVIEW
This patch series implements a QEMUFile Visitor class that's intended to abstract
away direct calls to qemu_put_*/qemu_get_* for save/load functions. Currently this
is done
On 2011-10-03 13:23, Harsh Prateek Bora wrote:
> SynthFS uses rwlocks, which raise the need of a generic QemuRWLock APIs.
> This patchset introduces the same making necessary changes to relevant code.
Is the impact of using a plain mutex measurable with 9pfs? Usually it
takes very heavy write sect
bdrv_open_common() is a useful point to trace since it reveals the
filename and block driver for a given BlockDriverState.
Signed-off-by: Stefan Hajnoczi
---
block.c |2 ++
trace-events |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index e3fe
Add trace events for handle_qmp_command(), which dispatches qmp
commands, and monitor_protocol_emitter(), which produces the reply to a
qmp command.
Also remove duplicate #include "trace/control.h".
Signed-off-by: Stefan Hajnoczi
---
monitor.c|5 -
trace-events |4
2 files
It is useful to know the BlockDriverState as well as the
sector_num/nb_sectors of an emulated .bdrv_co_*() request.
Signed-off-by: Stefan Hajnoczi
---
block.c |2 +-
trace-events |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index 1ae22d5..e
The following changes since commit d11cf8cc80d946dfc9a23597cd9a0bb1c487cfa7:
etrax-dma: Remove bogus if statement (2011-10-03 10:20:13 +0200)
are available in the git repository at:
ssh://repo.or.cz/srv/git/qemu/stefanha.git tracing
Michael Roth (1):
hmp: re-enable trace-file command
From: Michael Roth
Commit 31965ae27bc11e90674be12584bb201b83df5aef reverted a previous
renaming of CONFIG_SIMPLE_TRACE->CONFIG_TRACE_SIMPLE in a couple spots,
leading to trace-file currently being unavailable.
Signed-off-by: Michael Roth
Signed-off-by: Stefan Hajnoczi
---
hmp-commands.hx |
SynthFS introduced in
http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg01206.html
uses pthread_rwlock_* APIs for rwlocks, which raise the need of a generic
Qemu specific, os independent rwlock APIs. This patch introduces the same.
Another patch to switch pthread_rwlock_* into qemu_rwlock_* f
1 - 100 of 119 matches
Mail list logo