On 04/22/2010 08:37 AM, Gerhard Wiesinger wrote:
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/21/2010 09:14 PM, Gerhard Wiesinger wrote:
Can you explain which code files/functions of KVM is involved in
handling VGA memory window and page switching through the port write
to the VGA window re
On Wed, 21 Apr 2010, Kevin O'Connor wrote:
On Wed, Apr 21, 2010 at 09:16:54PM +0200, Gerhard Wiesinger wrote:
On Mon, 19 Apr 2010, Kevin O'Connor wrote:
SeaBIOS will lock parts of ram from 0xc-0xf so that the option
roms aren't writable. I wonder if that is confusing qemm when it
trie
On Wed, 21 Apr 2010, Jamie Lokier wrote:
Gerhard Wiesinger wrote:
Hmmm. I'm very new to QEMU and KVM but at least accessing the virtual HW
of QEMU even from KVM must be possible (e.g. memory and port accesses are
done on nearly every virtual device) and therefore I'm ending in C code in
the QEM
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/21/2010 09:50 PM, Gerhard Wiesinger wrote:
I don't think changing VGA window is a problem because there are
500.000-1Mio changes/s possible.
1MB/s, 500k-1M changes/s Coincidence? Is it taking a page fault
or trap on every write?
To clarify:
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/21/2010 09:39 PM, Jamie Lokier wrote:
Avi Kivity wrote:
Writes to vga in 16-color mode don't change set a memory location to a
value, instead they change multiple memory locations.
While code is just writing to the VGA memory, not reading(*) and
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/21/2010 09:14 PM, Gerhard Wiesinger wrote:
Can you explain which code files/functions of KVM is involved in handling
VGA memory window and page switching through the port write to the VGA
window register (or is that part handled through QEMU), so
On 14 March 2010 15:56, Benjamin Bagland wrote:
> Hi,
>
> I'm having an issue while trying to use the lm3s811 board emulation with
> qemu 0.12.3 or git. It works fine however with qemu-0.11.1.
>
> The problem comes from hw/armv7m.c, around line 231, the initial PC and SP
> are set by reading from
On 26 March 2010 18:06, Riku Voipio wrote:
> From: Riku Voipio
>
> Signed-Off-By: Riku Voipio
>
> ---
> sysemu.h | 1 +
> vl.c | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/sysemu.h b/sysemu.h
> index 525efd1..5b4ddd8 100644
> --- a/sysemu.h
> +++ b/sysemu
On 18 April 2010 10:52, Blue Swirl wrote:
> Fix clang error:
> CC bt-sdp.o
> /src/qemu/hw/bt-sdp.c:174:17: error: if statement has empty body
> [-Wempty-body]
> if (len > 1);
>
> However, fixing this means that some code that was previously
> ignored by the compiler now gets compiled, resu
Hi,
On 20 April 2010 11:38, Bernhard Kauer wrote:
> If a terminal is resized or the VGA model issues a full refresh,
> curses_update()
> is called, which uses mvwaddchnstr() to draw a full line of characters.
> Unfortunatelly
> this routine expects a null-terminated string and early aborts if
On Mon, Apr 19, 2010 at 04:34:54PM -0300, Lucas Meneghel Rodrigues wrote:
> After doing some reading it seems to me that the reason why that is not
> happening is because SeaBIOS still doesn't have code to support CPU hot
> plugging as BochsBIOS did.
As I understand it, the hotplug support was onl
On Wed, Apr 21, 2010 at 09:16:54PM +0200, Gerhard Wiesinger wrote:
> On Mon, 19 Apr 2010, Kevin O'Connor wrote:
> >SeaBIOS will lock parts of ram from 0xc-0xf so that the option
> >roms aren't writable. I wonder if that is confusing qemm when it
> >tries to locate the ebda into that area.
What is actually the closest sun4u model that qemu emulates?
Since it's a pci one I gave Ultra-5's OBP a shot, but it also dies
before the serial console is initialized:
$ sparc64-softmmu/qemu-system-sparc64 -bios
/home/tyom/sparc/prom/u5_v3.19.4.bin -nographic -d in_asm,int,cpu
skip unassign
Gerhard Wiesinger wrote:
> Hmmm. I'm very new to QEMU and KVM but at least accessing the virtual HW
> of QEMU even from KVM must be possible (e.g. memory and port accesses are
> done on nearly every virtual device) and therefore I'm ending in C code in
> the QEMU hw/*.c directory. Therefore also
Avi Kivity wrote:
> On 04/21/2010 09:39 PM, Jamie Lokier wrote:
> >Avi Kivity wrote:
> >
> >>Writes to vga in 16-color mode don't change set a memory location to a
> >>value, instead they change multiple memory locations.
> >>
> >While code is just writing to the VGA memory, not reading(*)
2010/4/21 Blue Swirl :
> On 4/21/10, Artyom Tarasenko wrote:
>> 2010/4/16 Artyom Tarasenko :
>>
>> > 2010/4/15 Artyom Tarasenko :
>> >> 2010/4/15 Blue Swirl :
>> >>> On 4/15/10, Artyom Tarasenko wrote:
>> 2010/4/15 Artyom Tarasenko :
>>
>> > One of LX's tests crashes pretty ha
On 04/21/2010 09:50 PM, Gerhard Wiesinger wrote:
I don't think changing VGA window is a problem because there are
500.000-1Mio changes/s possible.
1MB/s, 500k-1M changes/s Coincidence? Is it taking a page fault
or trap on every write?
To clarify:
Memory Performance writing to segmen A00
On 04/21/2010 09:39 PM, Jamie Lokier wrote:
Avi Kivity wrote:
Writes to vga in 16-color mode don't change set a memory location to a
value, instead they change multiple memory locations.
While code is just writing to the VGA memory, not reading(*) and not
touching the VGA I/O register
On 04/21/2010 09:14 PM, Gerhard Wiesinger wrote:
Can you explain which code files/functions of KVM is involved in
handling VGA memory window and page switching through the port write
to the VGA window register (or is that part handled through QEMU), so
a little bit architecture explaination w
Stefan Weil schrieb:
> configure adds the macro WIN32_LEAN_AND_MEAN to
> QEMU_CFLAGS, and SDL_syswm.h defines it, too.
>
> This results in a compiler warning (redefinition of
> WIN32_LEAN_AND_MEAN in SDL_syswm.h. That warning prevents
> compilations for win32 with warning = error).
>
> Fix this by
A new iovec array is allocated when creating a merged write request.
This patch ensures that the iovec array is deleted in addition to its
qiov owner.
Reported-by: Leszek Urbanski
Signed-off-by: Stefan Hajnoczi
---
This fixes the virtio-blk memory leak that has recently been reported by Leszek
Jan Kiszka schrieb:
> Alexander Graf wrote:
>
>> On 21.04.2010, at 12:04, Jun Koi wrote:
>>
>>
>>> On Tue, Apr 20, 2010 at 8:44 PM, Alexander Graf wrote:
>>>
On 20.04.2010, at 13:38, Jan Kiszka wrote:
> Alexander Graf wrote:
>
>> On 20.
On Mon, 19 Apr 2010, Kevin O'Connor wrote:
On Mon, Apr 19, 2010 at 08:19:55AM +0200, Gerhard Wiesinger wrote:
Kevin O'Connor wrote:
The SeaBIOS log would really help. This can be done by adding:
-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
to the qemu command
Apologies, I wasn't on the latest KVM HEAD and so missed that Michael had added
an irqfd assignment function (and a more correct one at that). So now this
patch has just one function.
---
kvm-all.c | 26 ++
kvm.h |7 +++
2 files changed, 33 insertions(+), 0
On Wed, 21 Apr 2010, Jamie Lokier wrote:
Gerhard Wiesinger wrote:
Would it be possible to handle these writes through QEMU directly
(without
KVM), because performance is there very well (looking at the code there
is some pointer arithmetic and some memory write done)?
I've noticed extremely s
Gerhard Wiesinger wrote:
> >>Would it be possible to handle these writes through QEMU directly
> >>(without
> >>KVM), because performance is there very well (looking at the code there
> >>is some pointer arithmetic and some memory write done)?
> >
> >I've noticed extremely slow VGA performance too
On Wed, 21 Apr 2010, Jamie Lokier wrote:
Gerhard Wiesinger wrote:
I'm using VESA mode 0x101 (640x480 256 colors), but performance is
there very low (~1MB/s). Test is also WITHOUT any vga window change, so
there isn't any page switching overhead involved in this test case.
Any ideas for improv
Avi Kivity wrote:
> Writes to vga in 16-color mode don't change set a memory location to a
> value, instead they change multiple memory locations.
While code is just writing to the VGA memory, not reading(*) and not
touching the VGA I/O register that control the write latches, is it
possible in p
Gerhard Wiesinger wrote:
> I'm using VESA mode 0x101 (640x480 256 colors), but performance is
> there very low (~1MB/s). Test is also WITHOUT any vga window change, so
> there isn't any page switching overhead involved in this test case.
>
> >>Any ideas for improvement?
> >
> >Currently when the
On Wed, 21 Apr 2010, Jamie Lokier wrote:
Gerhard Wiesinger wrote:
Any ideas from which change this might come (PS/2 mouse code seems to be
stable only keyboard LEDs added by Gerd)?
No, but you might find it with "git bisect" since you have a working
and non-working version.
Tried that, but
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/21/2010 01:08 PM, Jamie Lokier wrote:
Avi Kivity wrote:
On 04/19/2010 10:14 PM, Gerhard Wiesinger wrote:
Hello,
Finally I got QEMU-KVM to work but video performance under DOS is very
low (QEMU 0.12.3 stable and QEMU GIT master branch is fast, QE
On 4/21/10, Artyom Tarasenko wrote:
> 2010/4/16 Artyom Tarasenko :
>
> > 2010/4/15 Artyom Tarasenko :
> >> 2010/4/15 Blue Swirl :
> >>> On 4/15/10, Artyom Tarasenko wrote:
> 2010/4/15 Artyom Tarasenko :
>
> > One of LX's tests crashes pretty hard, causing qemu abort.
>
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/19/2010 10:14 PM, Gerhard Wiesinger wrote:
Hello,
Finally I got QEMU-KVM to work but video performance under DOS is very low
(QEMU 0.12.3 stable and QEMU GIT master branch is fast, QEMU KVM is slow)
I'm measuring 2 performance critical video perf
this code is a standalone server which will pass file descriptors for the shared
memory region and eventfds to support interrupts between guests using inter-VM
shared memory.
---
contrib/ivshmem-server/Makefile | 16 ++
contrib/ivshmem-server/README | 30 +++
contrib/ivshmem-
Support an inter-vm shared memory device that maps a shared-memory object as a
PCI device in the guest. This patch also supports interrupts between guest by
communicating over a unix domain socket. This patch applies to the qemu-kvm
repository.
-device ivshmem,size=[,shm=]
Interrupts are su
This avoids the need of using qemu_ram_alloc and mmap with MAP_FIXED to map a
host file into guest RAM. This function mmaps the opened file anywhere and adds
the memory to the ram blocks.
Usage is
qemu_ram_mmap(fd, size, MAP_SHARED, offset);
---
cpu-common.h |2 ++
exec.c | 36 +
Generic functions to assign irqfds and ioeventfds.
---
kvm-all.c | 44
kvm.h | 14 ++
2 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index fb8d4b8..d5c7775 100644
--- a/kvm-all.c
+++ b/kvm-all.
Latest patch for PCI shared memory device that maps a host shared memory object
to be shared between guests.
new in this series
- fixed segfault for non-server case
- code style fixes
- removed limit on the number of guests
- shared memory server is now in qemu.git/contrib
- ma
---
docs/specs/ivshmem_device_spec.txt | 91
1 files changed, 91 insertions(+), 0 deletions(-)
create mode 100644 docs/specs/ivshmem_device_spec.txt
diff --git a/docs/specs/ivshmem_device_spec.txt
b/docs/specs/ivshmem_device_spec.txt
new file mode 100644
i
Juan Quintela wrote:
> Luiz Capitulino wrote:
> > On Wed, 21 Apr 2010 15:28:16 +0200
> > Kevin Wolf wrote:
> I tried a variation of this in the past, and was not a clear agreement.
>
> Basically, after a working migration to other host, you don't want to
> allow "cont" on the source node (it tar
"Daniel P. Berrange" writes:
> On Wed, Apr 21, 2010 at 12:12:14PM -0300, Luiz Capitulino wrote:
>> On Wed, 21 Apr 2010 18:42:38 +0400 (MSD)
>> malc wrote:
>>
>> > On Wed, 21 Apr 2010, Kevin Wolf wrote:
>> >
>> > > Am 21.04.2010 10:28, schrieb Daniel P. Berrange:
>> > > > On Tue, Apr 20, 2010 a
Kevin Wolf wrote:
> Am 21.04.2010 17:08, schrieb Luiz Capitulino:
> A different status that disallows cont sounds good. But exit() would
> work for me as well and is probably easier. However, I'm not sure if it
> would work well for management.
I think that management would prefer it. It is dev
Luiz Capitulino wrote:
> On Wed, 21 Apr 2010 15:28:16 +0200
> Kevin Wolf wrote:
>
>> Am 20.04.2010 23:09, schrieb Luiz Capitulino:
>> > do_loadvm(), which implements the 'loadvm' Monitor command, pauses
>> > the emulation to load the saved VM, however it will only resume
>> > it if the loading su
Am 21.04.2010 17:39, schrieb Juan Quintela:
> Luiz Capitulino wrote:
>> 2. Don't keep the VM paused when recovery is possible
>>
>> If you can fix that, it's ok to me: I'll drop this and the next patch.
>>
>> Otherwise I'll have to insist on the split.
>
> Re-read my email. At this point, not
Luiz Capitulino wrote:
> On Wed, 21 Apr 2010 10:36:29 +0200
> Juan Quintela wrote:
>
>> QTAILQ_FOREACH(dinfo, &drives, next) {
>> bs1 = dinfo->bdrv;
>> if (bdrv_has_snapshot(bs1)) {
>>
>> /// We found a device that has snapshots
>> ret = bdrv_snapshot_goto(bs1, na
On Wed, 21 Apr 2010 16:15:58 +0100
"Daniel P. Berrange" wrote:
> On Wed, Apr 21, 2010 at 12:12:14PM -0300, Luiz Capitulino wrote:
> > On Wed, 21 Apr 2010 18:42:38 +0400 (MSD)
> > malc wrote:
> >
> > > On Wed, 21 Apr 2010, Kevin Wolf wrote:
> > >
> > > > Am 21.04.2010 10:28, schrieb Daniel P. B
Am 21.04.2010 17:08, schrieb Luiz Capitulino:
> On Wed, 21 Apr 2010 15:28:16 +0200
> Kevin Wolf wrote:
>
>> Am 20.04.2010 23:09, schrieb Luiz Capitulino:
>>> do_loadvm(), which implements the 'loadvm' Monitor command, pauses
>>> the emulation to load the saved VM, however it will only resume
>>>
On Wed, Apr 21, 2010 at 12:12:14PM -0300, Luiz Capitulino wrote:
> On Wed, 21 Apr 2010 18:42:38 +0400 (MSD)
> malc wrote:
>
> > On Wed, 21 Apr 2010, Kevin Wolf wrote:
> >
> > > Am 21.04.2010 10:28, schrieb Daniel P. Berrange:
> > > > On Tue, Apr 20, 2010 at 06:09:37PM -0300, Luiz Capitulino wrot
On Wed, 21 Apr 2010 18:42:38 +0400 (MSD)
malc wrote:
> On Wed, 21 Apr 2010, Kevin Wolf wrote:
>
> > Am 21.04.2010 10:28, schrieb Daniel P. Berrange:
> > > On Tue, Apr 20, 2010 at 06:09:37PM -0300, Luiz Capitulino wrote:
> > >> There are error handling functions in QEMU which print errno codes
>
On Wed, 21 Apr 2010 15:28:16 +0200
Kevin Wolf wrote:
> Am 20.04.2010 23:09, schrieb Luiz Capitulino:
> > do_loadvm(), which implements the 'loadvm' Monitor command, pauses
> > the emulation to load the saved VM, however it will only resume
> > it if the loading succeeds.
> >
> > In other words,
On Wed, 21 Apr 2010 10:36:29 +0200
Juan Quintela wrote:
> QTAILQ_FOREACH(dinfo, &drives, next) {
> bs1 = dinfo->bdrv;
> if (bdrv_has_snapshot(bs1)) {
>
> /// We found a device that has snapshots
> ret = bdrv_snapshot_goto(bs1, name);
> if (ret < 0) {
>
On Wed, 21 Apr 2010, Kevin Wolf wrote:
> Am 21.04.2010 10:28, schrieb Daniel P. Berrange:
> > On Tue, Apr 20, 2010 at 06:09:37PM -0300, Luiz Capitulino wrote:
> >> There are error handling functions in QEMU which print errno codes
> >> to the user. While it's debatable if this is good from a user
Am 20.04.2010 23:09, schrieb Luiz Capitulino:
> Signed-off-by: Luiz Capitulino
> ---
> qemu-monitor.hx |3 ++-
> savevm.c| 14 ++
> sysemu.h|2 +-
> 3 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/qemu-monitor.hx b/qemu-monitor.hx
> index
On Tue, Apr 20, 2010 at 08:13, Gabriel Southern
wrote:
> Hi,
>
> Does the linux-user mode in QEMU support running multithreaded code?
> I am most interested in running SPARC binaries, but I tested with
> x86_64 and it seems like some system calls needed for pthreads are not
> included. I've attac
Hi,
* the SIZE property patch:Msg-Id:<4bb206b9.80...@collabora.co.uk>
Fine with me.
* the socket reconnect patch: Msg-Id:<4b18055b.1030...@collabora.co.uk>
Not sure yet.
If we can get these patches sorted out, the only outstanding issues are
where the EGD protocol support and rate
Am 21.04.2010 10:28, schrieb Daniel P. Berrange:
> On Tue, Apr 20, 2010 at 06:09:37PM -0300, Luiz Capitulino wrote:
>> There are error handling functions in QEMU which print errno codes
>> to the user. While it's debatable if this is good from a user
>> perspective, sometimes it's the best you can
Am 20.04.2010 23:09, schrieb Luiz Capitulino:
> do_loadvm(), which implements the 'loadvm' Monitor command, pauses
> the emulation to load the saved VM, however it will only resume
> it if the loading succeeds.
>
> In other words, if the user issues 'loadvm' and it fails, the
> end result will be
Alexander Graf wrote:
> Thomas Monjalon wrote:
> > I'm slowly writing support for the WindRiver board SBC8349E.
> > For the moment, I send patches for things I'm sure.
>
> Nice. What kind of firmware does that use?
Hmm... I don't know. I don't have such a board.
I'm testing by running a wrapped Li
Thomas Monjalon wrote:
> Alexander Graf wrote:
>
>>> --- a/target-ppc/translate_init.c
>>> +++ b/target-ppc/translate_init.c
>>> @@ -2853,7 +2853,16 @@ static void init_excp_603 (CPUPPCState *env)
>>> env->excp_vectors[POWERPC_EXCP_SMI] = 0x1400;
>>> env->hreset_excp_prefix = 0x
Jamie Lokier wrote:
> But enough of that: It's history now; the guest virtio-rng has existed
> for more than a year. It is also amazingly short and simple. Yay for Rusty!
Ok, so...
If we can now take steps to integrate the code...
I'd like to get some feedback (or merging!) of the other parts
On 04/20/2010 06:40 AM, Yoshiaki Tamura wrote:
The dirty and non-dirty pages are checked one by one. When most of the memory
is not dirty, checking the dirty and non-dirty pages by multiple page size
should be much faster than checking them one by one. We introduced bit-based
phys_ram_dirty for
Alexander Graf wrote:
> > --- a/target-ppc/translate_init.c
> > +++ b/target-ppc/translate_init.c
> > @@ -2853,7 +2853,16 @@ static void init_excp_603 (CPUPPCState *env)
> > env->excp_vectors[POWERPC_EXCP_SMI] = 0x1400;
> > env->hreset_excp_prefix = 0xUL;
> > /* Hardwar
On Wed, Apr 21, 2010 at 01:46:33PM +0200, Jan Kiszka wrote:
> Michael S. Tsirkin wrote:
> > On Tue, Apr 13, 2010 at 05:59:44PM +0300, Michael S. Tsirkin wrote:
> >> The following situation was observed in the field:
> >> tap1 sends packets, tap2 does not consume them, as a result
> >> tap1 can not
Michael S. Tsirkin wrote:
> On Tue, Apr 13, 2010 at 05:59:44PM +0300, Michael S. Tsirkin wrote:
>> The following situation was observed in the field:
>> tap1 sends packets, tap2 does not consume them, as a result
>> tap1 can not be closed. This happens because
>> tun/tap devices can hang on to skbs
On Tue, Apr 13, 2010 at 05:59:44PM +0300, Michael S. Tsirkin wrote:
> The following situation was observed in the field:
> tap1 sends packets, tap2 does not consume them, as a result
> tap1 can not be closed. This happens because
> tun/tap devices can hang on to skbs undefinitely.
>
> As noted by
On Wed, 21 Apr 2010, Serge Ziryukin wrote:
> Trivial patch which uses aud_to_alsafmt to fix comparison
> between alsa and internal audio pcm format enum.
I've commited slightly different patch, thanks for spotting this.
--
mailto:av1...@comtv.ru
On 04/21/2010 01:08 PM, Jamie Lokier wrote:
Avi Kivity wrote:
On 04/19/2010 10:14 PM, Gerhard Wiesinger wrote:
Hello,
Finally I got QEMU-KVM to work but video performance under DOS is very
low (QEMU 0.12.3 stable and QEMU GIT master branch is fast, QEMU KVM
is slow)
I'm measuring 2
Trivial patch which uses aud_to_alsafmt to fix comparison
between alsa and internal audio pcm format enum.
---
audio/alsaaudio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
index 88344ff..d784476 100644
--- a/audio/alsaaudio.c
+++
On Tue, Apr 20, 2010 at 02:22:58PM +0100, Paul Brook wrote:
> > Does this mean that virtio-blk supports all three combinations?
> >
> >1. FLUSH that isn't a barrier
> >2. FLUSH that is also a barrier
> >3. Barrier that is not a flush
> >
> > 1 is good for fsync-like operations;
> > 2
Alexander Graf wrote:
> On 21.04.2010, at 12:04, Jun Koi wrote:
>
>> On Tue, Apr 20, 2010 at 8:44 PM, Alexander Graf wrote:
>>> On 20.04.2010, at 13:38, Jan Kiszka wrote:
>>>
Alexander Graf wrote:
> On 20.04.2010, at 09:18, Jan Kiszka wrote:
>
>> Jun Koi wrote:
>>> Thank you
On 21.04.2010, at 11:48, Thomas Monjalon wrote:
> From: Thomas Monjalon
>
> This function had been disabled from the beginning:
> see 9fddaa0c0cabb610947146a79b4a9a38b0a216e5
>
> cpu_reset() function is in target-ppc/helper.c
>
> Signed-off-by: Thomas Monjalon
Acked-by: Alexander Graf
Al
On 21.04.2010, at 11:21, Thomas Monjalon wrote:
> From: Thomas Monjalon
>
> The vectors are listed
>- in the chapter 1.3.3.2 (Implementation-Specific Interrupt Model)
> of the e300 datasheet [e300CORERM] and
>- in the chapter 3.5.2 (PowerPC 603 Microprocessor Exception Model)
>
On 21.04.2010, at 12:04, Jun Koi wrote:
> On Tue, Apr 20, 2010 at 8:44 PM, Alexander Graf wrote:
>>
>> On 20.04.2010, at 13:38, Jan Kiszka wrote:
>>
>>> Alexander Graf wrote:
On 20.04.2010, at 09:18, Jan Kiszka wrote:
> Jun Koi wrote:
>> Thank you for the explanation of this
On Tue, Apr 20, 2010 at 8:44 PM, Alexander Graf wrote:
>
> On 20.04.2010, at 13:38, Jan Kiszka wrote:
>
>> Alexander Graf wrote:
>>> On 20.04.2010, at 09:18, Jan Kiszka wrote:
>>>
Jun Koi wrote:
> Thank you for the explanation of this code.
>
> Qemu has a command named singlestep,
Avi Kivity wrote:
> On 04/19/2010 10:14 PM, Gerhard Wiesinger wrote:
> >Hello,
> >
> >Finally I got QEMU-KVM to work but video performance under DOS is very
> >low (QEMU 0.12.3 stable and QEMU GIT master branch is fast, QEMU KVM
> >is slow)
> >
> >I'm measuring 2 performance critical video perfor
From: Thomas Monjalon
This function had been disabled from the beginning:
see 9fddaa0c0cabb610947146a79b4a9a38b0a216e5
cpu_reset() function is in target-ppc/helper.c
Signed-off-by: Thomas Monjalon
---
hw/ppc.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/
Gerd Hoffmann wrote:
> On 04/20/10 23:31, Ian Molton wrote:
>
> >Using virtio-rng means that the data is going into the guest
> >kernels hwrng subsystem.
>
> Which is *the* major advantage of the virtio-rng driver. In case the
> guest kernel is recent enougth to have support for it, it will
>
Mohammed Gamal wrote:
> On Tue, Apr 20, 2010 at 8:36 PM, jvrao wrote:
>
> ... ...
>
>>> This'd be something interesting to do. I wonder if that would fit in
>>> the GSoC timeframe, or whether it'd be a little too short. So how long
>>> you'd estimate something like that would take?
>> I think i
From: Thomas Monjalon
Reflect values from the table "Assigned PVR values" in [e300CORERM].
Values for MPC603 and G2 processors could need check/changes also.
The reference document (e300CORERM) which is used is:
"e300 Power Architecture Core Family Reference Manual", Revision 4, 12/2007.
Signe
From: Thomas Monjalon
I'm working on e300.
It's still not working but these patches are some little steps in the right
direction.
My references:
ancestry: http://www.freescale.com/files/32bit/doc/data_sheet/MPC603.pdf
core:
http://www.freescale.com/files/32bit/doc/ref_manua
From: Thomas Monjalon
The vectors are listed
- in the chapter 1.3.3.2 (Implementation-Specific Interrupt Model)
of the e300 datasheet [e300CORERM] and
- in the chapter 3.5.2 (PowerPC 603 Microprocessor Exception Model)
of the MPC603 datasheet.
As e300 inherits from MPC603, in
On 04/19/2010 10:14 PM, Gerhard Wiesinger wrote:
Hello,
Finally I got QEMU-KVM to work but video performance under DOS is very
low (QEMU 0.12.3 stable and QEMU GIT master branch is fast, QEMU KVM
is slow)
I'm measuring 2 performance critical video performance parameters:
1.) INT 10h, functio
Luiz Capitulino wrote:
> On Tue, 20 Apr 2010 23:28:23 +0200
> Juan Quintela wrote:
>
>> Luiz Capitulino wrote:
>> > do_loadvm(), which implements the 'loadvm' Monitor command, pauses
>> > the emulation to load the saved VM, however it will only resume
>> > it if the loading succeeds.
>> >
>> > I
On Tue, Apr 20, 2010 at 06:09:37PM -0300, Luiz Capitulino wrote:
> There are error handling functions in QEMU which print errno codes
> to the user. While it's debatable if this is good from a user
> perspective, sometimes it's the best you can do because it's what
> system calls return and this is
2010/4/21 Stefan Hajnoczi :
> On Wed, Apr 21, 2010 at 6:57 AM, Yoshiaki Tamura
> wrote:
>> @@ -454,6 +458,25 @@ void qemu_fflush(QEMUFile *f)
>> }
>> }
>>
>> +void *qemu_realloc_buffer(QEMUFile *f, int size)
>> +{
>> + f->buf_max_size = size;
>> +
>> + f->buf = qemu_realloc(f->buf, f->b
On Wed, Apr 21, 2010 at 6:57 AM, Yoshiaki Tamura
wrote:
> @@ -454,6 +458,25 @@ void qemu_fflush(QEMUFile *f)
> }
> }
>
> +void *qemu_realloc_buffer(QEMUFile *f, int size)
> +{
> + f->buf_max_size = size;
> +
> + f->buf = qemu_realloc(f->buf, f->buf_max_size);
> + if (f->buf == NULL)
On 04/20/10 23:31, Ian Molton wrote:
Using virtio-rng means that the data is going into the guest
kernels hwrng subsystem.
Which is *the* major advantage of the virtio-rng driver. In case the
guest kernel is recent enougth to have support for it, it will
JustWork[tm]. No need for guest con
Currently FdMigrationState doesn't support writev() and read().
writev() is introduced to send data efficiently, and read() is
necessary to get response from the other side.
Signed-off-by: Yoshiaki Tamura
---
migration-tcp.c | 20
migration.c | 27 +++
For fool proof purpose, qemu_put_vector_parepare should be called
before qemu_put_vector. Then, if qemu_put_* functions except this is
called after qemu_put_vector_prepare, program will abort().
Signed-off-by: Yoshiaki Tamura
---
hw/hw.h |2 ++
savevm.c | 53 +
89 matches
Mail list logo
