Thanks, applied all.
On Wed, Mar 23, 2011 at 1:11 AM, Benjamin Poirier
benjamin.poir...@gmail.com wrote:
Hello,
Here is version 7 of my patchset to add vlan support to the emulated rtl8139
nic.
Changes since v6:
* added check against guest requesting tagging on frames with len 12
On Mon, Mar 21, 2011 at 7:47 PM, Peter Maydell peter.mayd...@linaro.org wrote:
This fairly simple patchset adds a new 'max_ram' field to the QEMUMachine
structure so that a board model can specify the maximum RAM it will accept.
We can then produce a friendly diagnostic message when the user
On Fri, Mar 25, 2011 at 2:04 PM, Gleb Natapov g...@redhat.com wrote:
Ping?
Does not work:
INT:
Got signal 951049944 from pid 0
TERM:
Got signal -1553068904 from pid 0
HUP:
Got signal 1 from pid 16185
Even here the pid is not correct, it should be 3098.
On Sat, Mar 26, 2011 at 03:50:46PM +0200, Blue Swirl wrote:
On Fri, Mar 25, 2011 at 2:04 PM, Gleb Natapov g...@redhat.com wrote:
Ping?
Does not work:
INT:
Got signal 951049944 from pid 0
TERM:
Got signal -1553068904 from pid 0
You use SDL correct? This is SDL problem and I fixed it in
On Sat, Mar 26, 2011 at 3:55 PM, Gleb Natapov g...@redhat.com wrote:
On Sat, Mar 26, 2011 at 03:50:46PM +0200, Blue Swirl wrote:
On Fri, Mar 25, 2011 at 2:04 PM, Gleb Natapov g...@redhat.com wrote:
Ping?
Does not work:
INT:
Got signal 951049944 from pid 0
TERM:
Got signal -1553068904
On 3/25/11, Peter Maydell peter.mayd...@linaro.org wrote:
On 24 March 2011 22:07, Dmitry Eremin-Solenikov dbarysh...@gmail.com
wrote:
Currently target-arm/ assumes at least ARMv5 core. Add support for
handling also ARMv4/ARMv4T. This changes the following instructions:
Mostly looks good;
On 26 March 2011 17:23, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote:
Can we assume (maybe temporarily) that all v5 are also v5TE?
It seems it's currently done so, and I don't want to be too intrusive.
All the cores we currently model that are v5 are v5TE, I think.
The current (v7) ARM
Rx and Tx descriptors are 16 byte aligned, so the lower bits are
ignored by real hardware. In fact, they always read back as zero on real
hardware, but probably nobody relies on that.
Signed-off-by: Kevin Wolf m...@kevin-wolf.de
---
hw/e1000.c | 21 ++---
1 files changed, 18
A lot of calls don't operate on bytes but on words or on structured data.
So instead of a pointer to uint8_t, a void pointer is the better choice.
This allows removing many type casts.
(Some very early implementations of memcpy used char pointers
which were replaced by void pointers for the same
All other type casts in calls of cpu_physical_memory_read are
used by hardware emulations and will be fixed by separate patches.
Cc: Blue Swirl blauwir...@gmail.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
monitor.c | 48 ++--
1 files
All other type casts in calls of cpu_physical_memory_write are
used by hardware emulations and will be fixed by separate patches.
Cc: Blue Swirl blauwir...@gmail.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
exec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
All other type casts in calls of cpu_physical_memory_read are
used by hardware emulations and will be fixed by separate patches.
v2: Fixed subject line
Cc: Blue Swirl blauwir...@gmail.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
monitor.c | 48
Hi list,
strange situation: When I create a snapshot using Qemu 0.14.0 stable,
everything works smoothly and resuming the CPU takes about 1-2 seconds. If I
don't use the snapshot file for some time, the time it takes to resume grows
by 2-3 seconds per day. At the moment, I'm looking at a
cirrus_reset is also called by the pci framework,
so there is no need to call it in cirrus_init_common.
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/cirrus_vga.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git
On the other hand, I think the starting point for a generic in-place
converter would be a loop that does something like bdrv_is_allocated()
but translates the guest position in the block device into an offset
into the image file. That, together with some sort of free map or
space allocation
The states at this point are just header files with various stuff
thrown in from sysemu.h, but structures could be introduced later,
functions named more consistently and other header files examined.
The patches touch a lot of files, but most of the changes are just one
line adjustments to
Move host specific state (not guest visible except for PV, unrelated to
any specific target machine, VM, VCPU or devices) declarations
to host-state.h.
Move macro TFR to qemu-common.h, so that qemu-char.c does not need
to include sysemu.h.
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
On 3/26/11, Peter Maydell peter.mayd...@linaro.org wrote:
On 26 March 2011 17:23, Dmitry Eremin-Solenikov dbarysh...@gmail.com
wrote:
Can we assume (maybe temporarily) that all v5 are also v5TE?
It seems it's currently done so, and I don't want to be too intrusive.
All the cores we currently
Move all state related to current VM and migration to vm-state.h.
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
arch_init.c |1 +
audio/audio.c|2 +-
blockdev.c |2 +-
cpus.c |1 +
gdbstub.c|2 +-
hw/fw_cfg.c
I've just gone through this distinguishing v5 sublevels.
I've also gone back and looked up an older ARM ARM for any v5 vs
v5T differences, and it looks like the only difference really is
whether Thumb mode works: the ARM instruction set is exactly the
same including the existence of BX/BLX.
So
20 matches
Mail list logo
