On Thu, Nov 24, 2011 at 09:53, Michael Rolnik wrote:
> Hi all,
> I have a question regarding MMU.
> I've built a SPARC based small embedded system.
> at this system addresses 0x-0x8000 (32KB) belong to ROM and
> 0x8000 - 0x8001 to RAM.
> the problem is that when a code from fi
> "Andreas" == Andreas Färber writes:
Andreas> Am 23.11.2011 01:51, schrieb Peter Chubb:
>>> "Peter" == Peter Chubb writes:
>>
>>
Peter> All comments received so far have been addressed --- I've added
Peter> a macro, `scream' that gives at most 10 lines of output for OS
Peter> error re
Bonjour,
des nouveaux offres emplois pour vous
http://www.universfreeads.com/emplois.php
..
Hello
I am using qemu-0.14, as a part of marss cycle-accurate simulator.
When I use delvm for deleting a snapshot, it corrupts the whole image.
After it, the image no longer boots.
Is there a solution to it (a patch or a recent version that solves it).
Please let me know, I would be grateful.
Th
On 11/25/2011 05:56 PM, Fabien Chouteau wrote:
>> Is it possible to use both? Keep the select scheme for iohandlers and
>> slirp, but use g_main_context_iteration() for Glib stuff.
>
> Perhaps with two threads, but I think it's more complicated than
> merging the handle/fd sets and doing a s
On 11/17/2011 06:14 PM, Daniel P. Berrange wrote:
On Thu, Nov 17, 2011 at 09:58:33AM -0600, Adam Litke wrote:
On Thu, Nov 17, 2011 at 03:46:37AM -0500, Ayal Baron wrote:
- Original Message -
I have been following this thread pretty closely and the one sentence
summary of the current
Enables providing a backing file for the PC's ram. The file is specified by the
new -pcram-file option. The file is mmap'd shared, so the RAMBlock that it backs
doesn't need to be saved by vm_save / migration.
Signed-off-by: Peter Feiner
---
We have found this small feature very useful for expe
qcow caches L2 tables. For migration to work, they would have to be
invalidated. Block migration for now.
Signed-off-by: Kevin Wolf
---
block/qcow.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/block/qcow.c b/block/qcow.c
index adecee0..4814ed0 100644
---
VMDK caches L2 tables. For migration to work, they would have to be
invalidated. Block migration for now.
Signed-off-by: Kevin Wolf
---
block/vmdk.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 96f7d5d..f544159 100644
Signed-off-by: Kevin Wolf
Reviewed-by: Stefan Hajnoczi
---
block/vpc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/block/vpc.c b/block/vpc.c
index 75d7d4a..89a5ee2 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -362,8 +362,11 @@ static int64_t alloc_block(BlockDri
From: Paolo Bonzini
USB mass storage devices are registered twice in the boot order.
To avoid having to keep the two paths in sync, pass the bootindex
property down to the scsi-disk device and let it register itself.
Signed-off-by: Paolo Bonzini
Signed-off-by: Kevin Wolf
---
hw/pci-hotplug.c
From: Paolo Bonzini
There is no reason why a scsi-generic device cannot boot if it has
the right type, and indeed it provides already a bootindex property.
So register those devices too.
Signed-off-by: Paolo Bonzini
Signed-off-by: Kevin Wolf
---
hw/scsi-generic.c |5 +
1 files changed
vvfat caches more or less everything when in writable mode. For migration
to work, it would have to be invalidated. Block migration for now when
in writable mode (default is readonly).
Signed-off-by: Kevin Wolf
---
block/vvfat.c | 17 +
1 files changed, 17 insertions(+), 0 dele
The block map is allocated in vdi_open, but was never freed.
Signed-off-by: Kevin Wolf
---
block/vdi.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block/vdi.c b/block/vdi.c
index 7dda522..02da6b4 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -949,6 +949,9 @@ static
Don't call arm_translate_init() (which allocates TCG resources)
unless TCG is enabled.
Signed-off-by: Peter Maydell
---
First KVM related QEMU patch :-)
[without this we segfault on startup if run with -enable-kvm,
although the omission is currently harmless for upstream QEMU
where TCG is always
El 25/11/11 13:01, Andreas Färber escribió:
Hi,
Am 25.11.2011 16:23, schrieb Ignacio Geli:
Im trying to run a solaris 2.5.1 vm acording the instructions of i found
in this blog:
http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html#uds-search-result
From: Dong Xu Wang
s->lock should be unlocked before leaving add_aio_request.
Signed-off-by: Dong Xu Wang
Signed-off-by: Kevin Wolf
---
block/sheepdog.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index 9f80609..62f1f3a 100644
vpc caches the BAT. For migration to work, it would have to be
invalidated. Block migration for now.
Signed-off-by: Kevin Wolf
---
block/vpc.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/block/vpc.c b/block/vpc.c
index 39a3247..75d7d4a 100644
--- a/block
vdi caches the block map. For migration to work, it would have to be
invalidated. Block migration for now.
Signed-off-by: Kevin Wolf
---
block/vdi.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/block/vdi.c b/block/vdi.c
index 684a4a8..7dda522 100644
--- a/
From: Paolo Bonzini
The pre-1.0 firmware path for SCSI devices already included the LUN
using the suffix argument to add_boot_device_path. Avoid that it is
included twice, and convert the colons to commas for consistency with
other kinds of devices
Signed-off-by: Paolo Bonzini
Signed-off-by: K
From: Paolo Bonzini
Signed-off-by: Paolo Bonzini
Signed-off-by: Kevin Wolf
---
hw/virtio-blk.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 19e89e7..d6d1f87 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -485,6 +4
The following changes since commit 40897c9c160393df922dfdb59cfa210048d3071d:
Update version for 1.0-rc3 release (2011-11-21 15:05:59 -0600)
are available in the git repository at:
git://repo.or.cz/qemu/kevin.git for-anthony
Dong Xu Wang (1):
sheepdog: Avoid deadlock in error path
Kevi
Marking this bug invalid as per bug 894608, thanks.
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/861141
Title:
Installing libvirt-bin qemu slows
On 2011-11-25 00:35, Liu Ping Fan wrote:
> A series of patches from kvm, qemu to guest. These patches will finally
> enable vcpu destruction in kvm instance and let vcpu thread exit in qemu.
>
> Currently, the vcpu online feature enables the dynamical creation of vcpu and
> vcpu thread, while t
On 25/11/2011 16:48, Paolo Bonzini wrote:
>>> There's a fundamental impedence mismatch between glib and
>>> slirp/iohandler. Either you convert glib's pollfds to fd_sets, or
>>> you
>>> take slirp and iohandler's fd_sets and put them in pollfds.
>>> Converting slirp and iohandler to produce pollfd
Am 24.11.2011 00:59, schrieb Andreas Färber:
> Unlike PowerPC, an architecture that I'm trying to emulate does not
> store branch instructions in the reset vector but a memory address. I'm
> therefore trying to read physical address 0x0 and store its value
> into my env->pc.
>
> I've verified
Hi,
Am 25.11.2011 16:23, schrieb Ignacio Geli:
> Im trying to run a solaris 2.5.1 vm acording the instructions of i found
> in this blog:
> http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html#uds-search-results
>
> compile my qemu with:
> git clone git://git.savannah.nongnu.org/qemu.g
> > > > slirp is fd_set---thus select()---based. iohandler too,
> > > > though it would likely be simpler to switch it to poll().
> > > Right, for slirp and iohandler, but it seems wrong to take file
> > > descriptors from g_main_context_query() and put them in the
> > > fd_sets for
> >> select(
On Fri, Nov 25, 2011 at 12:37:04PM -0200, Luiz Capitulino wrote:
> On Fri, 25 Nov 2011 16:12:37 +0200
> Alon Levy wrote:
>
> > On Thu, Nov 24, 2011 at 04:03:55PM -0200, Luiz Capitulino wrote:
> > > Avi,
> > >
> >
> > I have the same panic and the same bisection result. It doesn't happen
> > wit
On 25 November 2011 15:35, Max Filippov wrote:
>> Breakpoint 7, cpu_arm_exec (env=0x102033200) at ~/qemu-0.15.0/cpu-exec.c:557
>> 557 next_tb = tcg_qemu_tb_exec(env, tc_ptr);
>> (gdb) p/x env->regs
>> $13 = {0x4002c00c, 0x20, 0x4, 0x0, 0x0, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0,
> Breakpoint 7, cpu_arm_exec (env=0x102033200) at ~/qemu-0.15.0/cpu-exec.c:557
> 557 next_tb = tcg_qemu_tb_exec(env, tc_ptr);
> (gdb) p/x env->regs
> $13 = {0x4002c00c, 0x20, 0x4, 0x0, 0x0, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x30, 0x10007fa8, 0x560d, 0x560c}
> (gdb) s
On 25/11/2011 15:49, Paolo Bonzini wrote:
> On 11/25/2011 03:46 PM, Fabien Chouteau wrote:
>>> > slirp is fd_set---thus select()---based. iohandler too, though it would
>>> > likely be simpler to switch it to poll().
>> Right, for slirp and iohandler, but it seems wrong to take file
>> descripto
hi all.
Im trying to run a solaris 2.5.1 vm acording the instructions of i
found in this blog:
http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html#uds-search-results
compile my qemu with:
git clone git://git.savannah.nongnu.org/qemu.git
cd qemu
On 11/25/2011 03:46 PM, Fabien Chouteau wrote:
> slirp is fd_set---thus select()---based. iohandler too, though it would
likely be simpler to switch it to poll().
Right, for slirp and iohandler, but it seems wrong to take file
descriptors from g_main_context_query() and put them in the fd_set
On 25/11/2011 11:46, Paolo Bonzini wrote:
> On 11/25/2011 11:24 AM, Fabien Chouteau wrote:
>>> For POSIX, it would be just a call to
>>> glib_select_fill+select+glib_select_poll. (Everything around
>>> these three would stay in the caller, and the fd_sets would be
>>> passed to os_host_main_loop_w
lets say we need to translate tcg_add rbx, rcx
we need to load rbx and rcx from the x86 CPUState and then we add them
and store the result back to rcx in the CPUState.
How is it achieved in the x86 tcg backend.
In particular, how do I load rbx/rcx from the CPUState ?
Thanks
Xin
On Fri, 25 Nov 2011 16:12:37 +0200
Alon Levy wrote:
> On Thu, Nov 24, 2011 at 04:03:55PM -0200, Luiz Capitulino wrote:
> > Avi,
> >
>
> I have the same panic and the same bisection result. It doesn't happen
> with recent (3.2.0 rc1 and rc3) kernels.
Would be nice to test a recent kernel with 6
Signed-off-by: Benoît Canet
---
hw/omap.h |7 +--
hw/omap1.c|2 +-
hw/omap_i2c.c | 45 +
3 files changed, 31 insertions(+), 23 deletions(-)
diff --git a/hw/omap.h b/hw/omap.h
index 837c73f..7ca8a42 100644
--- a/hw/omap.h
+++ b/hw/
Signed-off-by: Benoît Canet
---
hw/omap.h|1 +
hw/omap_l4.c | 35 +++
2 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/hw/omap.h b/hw/omap.h
index c04e683..837c73f 100644
--- a/hw/omap.h
+++ b/hw/omap.h
@@ -76,6 +76,7 @@ struct omap_l4_age
Signed-off-by: Benoît Canet
---
hw/omap_sx1.c | 113 ++---
1 files changed, 59 insertions(+), 54 deletions(-)
diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c
index fe53545..b056bc9 100644
--- a/hw/omap_sx1.c
+++ b/hw/omap_sx1.c
@@ -59,46 +59,42 @@
Signed-off-by: Benoît Canet
---
hw/omap_spi.c | 37 -
1 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/hw/omap_spi.c b/hw/omap_spi.c
index c20f425..4823bd0 100644
--- a/hw/omap_spi.c
+++ b/hw/omap_spi.c
@@ -24,6 +24,7 @@
/* Multichannel SPI
Signed-off-by: Benoît Canet
---
hw/omap.h |7 +--
hw/omap1.c |2 +-
hw/omap_lcdc.c | 33 +++--
3 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/hw/omap.h b/hw/omap.h
index 759e90f..c04e683 100644
--- a/hw/omap.h
+++ b/hw/omap.h
@@
These patch convert some omap devices to the memory API
Benoît Canet (5):
omap_sx1: convert to memory API
omap_spi: convert to memory API
omap_lcdc: convert to memory API
omap_l4: convert to memory API
omap_i2c: convert to memory API
hw/omap.h | 15 +--
hw/omap1.c |4
This is how it looks:
Hi,
Thanks for the help.
Breakpoint 7, cpu_arm_exec (env=0x102033200) at ~/qemu-0.15.0/cpu-exec.c:557
557 next_tb = tcg_qemu_tb_exec(env, tc_ptr);
(gdb) p/x env->regs
$13 = {0x4002c00c, 0x20, 0x4, 0x0, 0x0, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0,
0x3
On Thu, Nov 24, 2011 at 04:03:55PM -0200, Luiz Capitulino wrote:
> Avi,
>
I have the same panic and the same bisection result. It doesn't happen
with recent (3.2.0 rc1 and rc3) kernels.
> I'm getting the following panic very early on boot on a F16 VM (latest
> qemu.git head 40897c9):
>
> [0
On Fri, Nov 25, 2011 at 08:15:33AM -0500, Xin Tong wrote:
> I have 2 questions regarding self modifying code on qemu.
>
> 1. how does qemu detect self modifying code.
> 2. does qemu flush the code cache completely or partially when self
> modifying code is encountered ?
I mean qemu does NOT the
On Fri, Nov 25, 2011 at 08:15:33AM -0500, Xin Tong wrote:
> I have 2 questions regarding self modifying code on qemu.
>
> 1. how does qemu detect self modifying code.
> 2. does qemu flush the code cache completely or partially when self
> modifying code is encountered ?
>
> Thanks
>
> Xin
How
I have 2 questions regarding self modifying code on qemu.
1. how does qemu detect self modifying code.
2. does qemu flush the code cache completely or partially when self
modifying code is encountered ?
Thanks
Xin
On 24 November 2011 23:43, Alexander Graf wrote:
> ---
>
> v1 -> v2:
>
> - make prettier by just wrapping mmap in linux-user/mmap.c
Hmm. I prefer the non-wrapped version :-)
In particular, qemu_mmap() implies that (like other qemu_foo
wrappers) this is a portability wrapper that should be used f
>> Also all the registers which are pushed to the stack,
>> "r3, r4, r5, r6, r7, lr" are cleared to zero
>
> That is odd. I wonder if the processor is resetting for some reason.
Another other possibility is stack pointer pointing to a region w/o
underlying physical memory.
--
Thanks.
-- Max
On 25 November 2011 12:33, Gauresh Rane wrote:
> Thanks for the reply.
> The instruction that is causing problem is
> 436: bx lr
>
> On single stepping and logging the trace I see that the lr has been set
> correctly to jump back, in the beginning of the block and also the
> microinstructions inst
On Fri, Nov 25, 2011 at 11:51, Stefano Stabellini
wrote:
>> On Thu, Nov 24, 2011 at 18:30, Stefano Stabellini
>> wrote:
>> >
>> >> @@ -2784,9 +2796,11 @@ static void cirrus_reset(void *opaque)
>> >> }
>> >> s->vga.cr[0x27] = s->device_id;
>> >>
>> >> - /* Win2K seems to assume that t
Hey,
Thanks for the reply.
The instruction that is causing problem is
436: bx lr
On single stepping and logging the trace I see that the lr has been set
correctly to jump back, in the beginning of the block and also the
microinstructions instructions generated match the following disassembly of
This is a compatible extension to the snapshot header format that allows
saving a 64 bit VM state size.
Signed-off-by: Kevin Wolf
---
block.h|2 +-
block/qcow2-snapshot.c | 34 --
block/qcow2.h |2 +-
docs/specs/qcow2.txt |
Am 23.11.2011 12:23, schrieb Kevin Wolf:
> Am 23.11.2011 12:01, schrieb Stefan Hajnoczi:
>> On Wed, Nov 23, 2011 at 10:40 AM, Kevin Wolf wrote:
>>> Signed-off-by: Kevin Wolf
>>> ---
>>> block/vpc.c |5 -
>>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/block/vpc.
On 11/25/2011 12:56 PM, Kevin Wolf wrote:
qemu_iovec_destroy does not clear the QEMUIOVector fully, and the data
> could thus be used after free or freed again. While I do not know any
> example in the tree, I observed this using virtio-scsi (and SCSI
> scatter/gather) when canceling DMA requ
Am 25.11.2011 12:06, schrieb Paolo Bonzini:
> qemu_iovec_destroy does not clear the QEMUIOVector fully, and the data
> could thus be used after free or freed again. While I do not know any
> example in the tree, I observed this using virtio-scsi (and SCSI
> scatter/gather) when canceling DMA reque
> On Thu, Nov 24, 2011 at 18:30, Stefano Stabellini
> wrote:
> >
> >> @@ -2784,9 +2796,11 @@ static void cirrus_reset(void *opaque)
> >> Â Â Â }
> >> Â Â Â s->vga.cr[0x27] = s->device_id;
> >>
> >> - Â Â /* Win2K seems to assume that the pattern buffer is at 0xff
> >> - Â Â Â initially ! *
On 25 November 2011 10:27, Gauresh Rane wrote:
> I am working on developing a simulator on qemu. I am faced with a bug and I
> have tried solving it for three days now with no success:
> Here is my problem:
> I trying to simulate LPC 1768 cortex m3 based processor on qemu. But I am
> unable to g
On Fri, Nov 25, 2011 at 09:27:43AM +0100, Paolo Bonzini wrote:
> No, it adds support for 512b logical block sizes running on a host with 4k
> logical block size and cache=none. This is suboptimal as it requires
> bounce buffers, but it can happen with migration and until libvirt provides
> a kn
qemu_iovec_destroy does not clear the QEMUIOVector fully, and the data
could thus be used after free or freed again. While I do not know any
example in the tree, I observed this using virtio-scsi (and SCSI
scatter/gather) when canceling DMA requests.
Signed-off-by: Paolo Bonzini
---
cutils.c |
On 11/25/2011 11:24 AM, Fabien Chouteau wrote:
For POSIX, it would be just a call to
glib_select_fill+select+glib_select_poll. (Everything around
these three would stay in the caller, and the fd_sets would be
passed to os_host_main_loop_wait).
Are you sure we have to use select()?
slirp is f
VNC clients send a shared flag in the client init message. Up to now
qemu completely ignores this. This patch implements shared flag
handling. It comes with three policies: By default qemu behaves as one
would expect: Asking for a exclusive access grants exclusive access to
the client connecti
Make the control keys for terminals on the vnc display
(i.e. qemu -vnc :0 -serial vc) work. Makes the terminals
alot more usable as typing Ctrl-C in your serial console
actually has the desired effect ;)
Signed-off-by: Gerd Hoffmann
---
ui/vnc.c | 10 --
1 files changed, 8 insertions(
Hi,
I am working on developing a simulator on qemu. I am faced with a bug and I
have tried solving it for three days now with no success:
Here is my problem:
I trying to simulate LPC 1768 cortex m3 based processor on qemu. But I am
unable to get beyond the libc_init_array in the newlib.
My qemu
On 24/11/2011 18:30, Paolo Bonzini wrote:
> On 11/24/2011 06:11 PM, Fabien Chouteau wrote:
>> Hello,
>>
>> I've run into some problems with this patch on Windows. The thing is
>> that select() should be used only with socket file descriptors.
>>
>> If glib_select_fill() put a non-socket file descri
2011/11/24 Stefan Hajnoczi
> On Thu, Nov 24, 2011 at 3:38 AM, Chunyan Liu wrote:
> >
> >
> > 2011/11/23 Stefan Hajnoczi
> >>
> >> On Wed, Nov 23, 2011 at 10:14 AM, Chunyan Liu wrote:
> >> > V3:
> >> > Remove file lock in main().
> >> > Try to find new free nbd device and connect to it if conne
On Thu, Nov 24, 2011 at 02:40:07PM +0200, Dor Laor wrote:
> On 11/17/2011 09:58 PM, Michael Roth wrote:
> >On 11/17/2011 10:34 AM, Barak Azulay wrote:
> >>On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
> >>>I've tried to summarize the pros/cons, points, and proposals outlined in
> >>>thi
On 11/25/2011 04:17 AM, Peter Chubb wrote:
If I fix the problem as in the appended patch, I start seeing other
complaints:
ERROR: space prohibited after that '*' (ctx:WxW)
+#define PRIO_PER_WORD (sizeof (uint32_t) * 8 / 4)
^
This was fixed recently in
From: Florian Mickler
We should only claim that something is a cast if we did not encouter a
token before, that did set av_pending.
This fixes the operator * in the line below to be detected as binary (vs
unary).
kmalloc(sizeof(struct alphatrack_ocmd) * true_size, GFP_KERNEL);
Reported-by: Pet
于 2011/11/25,星期五 4:29, Cam Macdonell 写道:
On Thu, Nov 24, 2011 at 3:05 AM, wrote:
From: Hongyong Zang
When a guest boots with ioeventfd, an error (by gdb) occurs:
Program received signal SIGSEGV, Segmentation fault.
0x006009cc in setup_ioeventfds (s=0x171dc40)
at /home/louzhen
On 11/24/2011 08:28 PM, Stefan Weil wrote:
MS claims that putenv is a POSIX function, so I also expected
that free / f_free is not allowed.
I now wrote a short test which indicates that g_free would work:
getenv returns a pointer which is completely different from
the one passed to putenv.
Co
On 11/25/2011 08:26 AM, Mark Wu wrote:
1. This patch aims to add 4k logical support for qemu running on a host
with 4k logical block size, right?
No, it adds support for 512b logical block sizes running on a host with
4k logical block size and cache=none. This is suboptimal as it requires
bo
On 11/24/2011 06:55 PM, Michael S. Tsirkin wrote:
> Could some backend make it a hard failure?
I don't see how, there's no way to report a failure from
an io port write.
You can exit(1), or fall back to a restricted set of features like we do
for BAD_FEATURE. BAD_FEATURE is a special case o
74 matches
Mail list logo
