Thanks, applied all.
On Wed, Mar 23, 2011 at 1:11 AM, Benjamin Poirier
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
> * simplifie
On Mon, Mar 21, 2011 at 7:47 PM, Peter Maydell 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 tries to
> start qemu wi
On Fri, Mar 25, 2011 at 2:04 PM, Gleb Natapov 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 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 SDL upstr
On Sat, Mar 26, 2011 at 3:55 PM, Gleb Natapov 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 wrote:
>> > Ping?
>>
>> Does not work:
>> INT:
>> Got signal 951049944 from pid 0
>> TERM:
>> Got signal -1553068904 from pid 0
> You
On 3/25/11, Peter Maydell wrote:
> On 24 March 2011 22:07, Dmitry Eremin-Solenikov
> wrote:
>> Currently target-arm/ assumes at least ARMv5 core. Add support for
>> handling also ARMv4/ARMv4T. This changes the following instructions:
>
> Mostly looks good; comments below.
>
>> @@ -161,6 +179,8 @@
On 26 March 2011 17:23, Dmitry Eremin-Solenikov 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 ARM says the valid v5
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
---
hw/e1000.c | 21 ++---
1 files changed, 18 insertions(+), 3 dele
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
Signed-off-by: Stefan Weil
---
monitor.c | 48 ++--
1 files changed, 18 insertions(+), 30 deletions(-)
d
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
Signed-off-by: Stefan Weil
---
exec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/exec.c b/exec.c
index 964ce31..d7afe30
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
Signed-off-by: Stefan Weil
---
monitor.c | 48 ++--
1 files changed, 18 insertion
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 snapsh
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
Signed-off-by: Stefan Weil
---
hw/cirrus_vga.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 2724f7b.
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 bit
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 #incl
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
---
host-state.h |
On 3/26/11, Peter Maydell wrote:
> On 26 March 2011 17:23, Dmitry Eremin-Solenikov
> 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.
Move all state related to current VM and migration to vm-state.h.
Signed-off-by: Blue Swirl
---
arch_init.c |1 +
audio/audio.c|2 +-
blockdev.c |2 +-
cpus.c |1 +
gdbstub.c|2 +-
hw/fw_cfg.c |1 +
hw/ide/cmd6
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 I'm
20 matches
Mail list logo
