Hello Dmitry,
Tried it also on qemu, without success. Same behavior.
I sniffed also with tcpdump:
ICMP traffic is dumped immediately but TCP traffic not. Looks like a TCP
problem.
For config and other details see below.
Ciao,
Gerhard
On 21.03.2012 07:59, Gerhard Wiesinger wrote:
On
Eduardo Habkost wrote:
On Fri, Mar 09, 2012 at 09:52:29PM +0100, Jan Kiszka wrote:
On 2012-03-09 20:09, Liu, Jinsong wrote:
Jan Kiszka wrote:
On 2012-03-09 19:27, Liu, Jinsong wrote:
Jan Kiszka wrote:
On 2012-03-06 08:49, Liu, Jinsong wrote:
Jan,
Any comments? I feel some confused about
On Thu, Mar 22, 2012 at 03:01:17PM -0500, Anthony Liguori wrote:
On 03/22/2012 12:14 PM, Eduardo Habkost wrote:
On Thu, Mar 22, 2012 at 11:37:39AM -0500, Anthony Liguori wrote:
On 03/22/2012 04:32 AM, Gleb Natapov wrote:
On Tue, Mar 13, 2012 at 11:53:19AM -0300, Eduardo Habkost wrote:
So,
On 03/25/2012 04:00 AM, Max Filippov wrote:
Since I'm rewriting this area, don't worry about efficiency. Let's get
it correct and after the rewrite we can reexamine efficiency.
I imagine you'll need something like breakpoint_invalidate().
The following RFC patch takes the obvious approach
On 03/23/2012 07:58 PM, Luiz Capitulino wrote:
On Wed, 21 Mar 2012 15:48:43 +0200
Avi Kivity a...@redhat.com wrote:
On 03/21/2012 03:40 PM, Jan Kiszka wrote:
On 2012-03-21 13:38, GaoYi wrote:
Hi Jan,
Since the newest Intel-VT supports the guest OS under the real
mode,
On Sat, Mar 24, 2012 at 08:13:34AM +0100, Stefan Weil wrote:
mem is an uint64_t value, so %lx was wrong.
Thanks,
ACK
Signed-off-by: Stefan Weil s...@weilnetz.de
---
trace-events |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/trace-events b/trace-events
On Thu, Mar 22, 2012 at 12:50:18PM -0300, Eduardo Habkost wrote:
On Thu, Mar 22, 2012 at 04:30:55PM +0200, Gleb Natapov wrote:
On Thu, Mar 22, 2012 at 10:31:21AM -0300, Eduardo Habkost wrote:
On Thu, Mar 22, 2012 at 11:32:44AM +0200, Gleb Natapov wrote:
What does this mean? Will
On 03/23/2012 06:37 PM, Jan Kiszka wrote:
On 2012-03-23 16:08, Julien Grall wrote:
On 03/22/2012 05:44 PM, Jan Kiszka wrote:
static void core_region_nop(MemoryListener *listener,
diff --git a/ioport.c b/ioport.c
index 78a3b89..073ed75 100644
--- a/ioport.c
+++ b/ioport.c
@@
So if the VT already supports unrestricted guest, KVM can then runs such
guest?
在 2012年3月25日 下午5:55，Avi Kivity a...@redhat.com写道：
On 03/23/2012 07:58 PM, Luiz Capitulino wrote:
On Wed, 21 Mar 2012 15:48:43 +0200
Avi Kivity a...@redhat.com wrote:
On 03/21/2012 03:40 PM, Jan Kiszka
On 03/23/2012 01:02 PM, Stefano Stabellini wrote:
Maybe the best thing to do is to have a set of machine specific options
to select what devices need to be built in the machine.
Most devices already can be dynamically selected: NICs, usb, acpi,
cirrus, etc.
We already have a Xen machine
On 03/25/2012 04:49 AM, Gleb Natapov wrote:
On Thu, Mar 22, 2012 at 03:01:17PM -0500, Anthony Liguori wrote:
So let's avoid that and start by having a positive configuration
mechanism that the user can use to change the path and exclude it.
My suggestion eliminate the need for two future
On 03/25/2012 02:55 PM, Anthony Liguori wrote:
If cpu models are not part of configuration they should not be affected
by configuration mechanism. You are just avoiding addressing the real
question that if asked above.
I think you're just refusing to listen.
The stated direction of QEMU,
On 03/25/2012 05:19 AM, Gleb Natapov wrote:
On Thu, Mar 22, 2012 at 12:50:18PM -0300, Eduardo Habkost wrote:
On Thu, Mar 22, 2012 at 04:30:55PM +0200, Gleb Natapov wrote:
On Thu, Mar 22, 2012 at 10:31:21AM -0300, Eduardo Habkost wrote:
On Thu, Mar 22, 2012 at 11:32:44AM +0200, Gleb Natapov
On 03/25/2012 08:08 AM, Avi Kivity wrote:
On 03/25/2012 02:55 PM, Anthony Liguori wrote:
If cpu models are not part of configuration they should not be affected
by configuration mechanism. You are just avoiding addressing the real
question that if asked above.
I think you're just refusing to
On 03/25/2012 03:12 PM, Anthony Liguori wrote:
qemu -M pc
Would effectively be short hand for -readconfig
/usr/share/qemu/machines/pc.cfg
In that case
qemu -cpu westmere
is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
This is not a bad suggestion, although it would
On 03/11/2012 04:12 PM, Anthony Liguori wrote:
Let me elaborate about the later. Suppose host CPU has kill_guest
feature and at the time a guest was installed it was not implemented by
kvm. Since it was not implemented by kvm it was not present in vcpu
during installation and the guest didn't
On 03/25/2012 08:14 AM, Avi Kivity wrote:
On 03/25/2012 03:12 PM, Anthony Liguori wrote:
qemu -M pc
Would effectively be short hand for -readconfig
/usr/share/qemu/machines/pc.cfg
In that case
qemu -cpu westmere
is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
This is
On 03/25/2012 08:21 AM, Avi Kivity wrote:
On 03/11/2012 04:12 PM, Anthony Liguori wrote:
This discussion isn't about whether QEMU should have a Westmere
processor definition. In fact, I think I already applied that patch.
It's a discussion about how we handle this up and down the stack.
The
On 03/25/2012 03:22 PM, Anthony Liguori wrote:
In that case
qemu -cpu westmere
is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
This is not a bad suggestion, although it would make -cpu ? a bit
awkward. Do you see an advantage to this over having
On 03/25/2012 08:34 AM, Avi Kivity wrote:
On 03/25/2012 03:22 PM, Anthony Liguori wrote:
In that case
qemu -cpu westmere
is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
This is not a bad suggestion, although it would make -cpu ? a bit
awkward. Do you see an advantage
On 03/25/2012 04:36 PM, Anthony Liguori wrote:
Apart from the command line length, it confuses configuration with
definition.
There is no distinction with what we have today. Our configuration
file basically corresponds to command line options and as there is no
distinction in command line
On Sun, Mar 25, 2012 at 08:09:37AM -0500, Anthony Liguori wrote:
On 03/25/2012 05:19 AM, Gleb Natapov wrote:
On Thu, Mar 22, 2012 at 12:50:18PM -0300, Eduardo Habkost wrote:
On Thu, Mar 22, 2012 at 04:30:55PM +0200, Gleb Natapov wrote:
On Thu, Mar 22, 2012 at 10:31:21AM -0300, Eduardo Habkost
On Sun, Mar 25, 2012 at 03:14:56PM +0200, Avi Kivity wrote:
On 03/25/2012 03:12 PM, Anthony Liguori wrote:
qemu -M pc
Would effectively be short hand for -readconfig
/usr/share/qemu/machines/pc.cfg
In that case
qemu -cpu westmere
is shorthand for -readconfig
On 03/25/2012 09:46 AM, Avi Kivity wrote:
On 03/25/2012 04:36 PM, Anthony Liguori wrote:
Apart from the command line length, it confuses configuration with
definition.
There is no distinction with what we have today. Our configuration
file basically corresponds to command line options and
On 03/25/2012 09:46 AM, Gleb Natapov wrote:
On Sun, Mar 25, 2012 at 08:09:37AM -0500, Anthony Liguori wrote:
On 03/25/2012 05:19 AM, Gleb Natapov wrote:
It's the Unix Philosophy:
Rule of Representation: Fold knowledge into data so program logic
can be stupid and robust.
If it can be
On 03/25/2012 09:58 AM, Gleb Natapov wrote:
On Sun, Mar 25, 2012 at 03:14:56PM +0200, Avi Kivity wrote:
On 03/25/2012 03:12 PM, Anthony Liguori wrote:
qemu -M pc
Would effectively be short hand for -readconfig
/usr/share/qemu/machines/pc.cfg
In that case
qemu -cpu westmere
is shorthand
On 03/25/2012 04:59 PM, Anthony Liguori wrote:
On 03/25/2012 09:46 AM, Avi Kivity wrote:
On 03/25/2012 04:36 PM, Anthony Liguori wrote:
Apart from the command line length, it confuses configuration with
definition.
There is no distinction with what we have today. Our configuration
file
On 03/25/2012 05:07 PM, Anthony Liguori wrote:
As log as qemu -nodefconfig -cpu westmere -M pc1.1
-nodefconfig is going to eventually mean that -cpu westmere and -M
pc-1.1 will not work.
This is where QEMU is going. There is no reason that a normal user
should ever use -nodefconfig.
I
On 03/25/2012 10:16 AM, Avi Kivity wrote:
On 03/25/2012 04:59 PM, Anthony Liguori wrote:
On 03/25/2012 09:46 AM, Avi Kivity wrote:
On 03/25/2012 04:36 PM, Anthony Liguori wrote:
Apart from the command line length, it confuses configuration with
definition.
There is no distinction with what
On 03/25/2012 10:18 AM, Avi Kivity wrote:
On 03/25/2012 05:07 PM, Anthony Liguori wrote:
As log as qemu -nodefconfig -cpu westmere -M pc1.1
-nodefconfig is going to eventually mean that -cpu westmere and -M
pc-1.1 will not work.
This is where QEMU is going. There is no reason that a normal
On 03/25/2012 05:26 PM, Anthony Liguori wrote:
Put the emphasis around *configuration*.
So how about:
1) Load ['@SYSCONFDIR@/qemu/qemu.cfg',
'@SYSCONFDIR@/qemu/target-@ARCH@.cfg',
'@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg']
2) system-@ARCH@.cfg will contain:
On 03/25/2012 05:30 PM, Anthony Liguori wrote:
On 03/25/2012 10:18 AM, Avi Kivity wrote:
On 03/25/2012 05:07 PM, Anthony Liguori wrote:
As log as qemu -nodefconfig -cpu westmere -M pc1.1
-nodefconfig is going to eventually mean that -cpu westmere and -M
pc-1.1 will not work.
This is where
On 03/25/2012 03:26 PM, Anthony Liguori wrote:
We would continue to have Westmere/etc in QEMU exposed as part of the
user configuration. But I don't think it makes a lot of sense to have
to modify QEMU any time a new CPU comes out.
We have to. New features often come with new MSRs which
On Sun, Mar 25, 2012 at 10:06:03AM -0500, Anthony Liguori wrote:
On 03/25/2012 09:46 AM, Gleb Natapov wrote:
On Sun, Mar 25, 2012 at 08:09:37AM -0500, Anthony Liguori wrote:
On 03/25/2012 05:19 AM, Gleb Natapov wrote:
It's the Unix Philosophy:
Rule of Representation: Fold knowledge into
On 03/25/2012 10:45 AM, Avi Kivity wrote:
On 03/25/2012 05:30 PM, Anthony Liguori wrote:
On 03/25/2012 10:18 AM, Avi Kivity wrote:
On 03/25/2012 05:07 PM, Anthony Liguori wrote:
As log as qemu -nodefconfig -cpu westmere -M pc1.1
-nodefconfig is going to eventually mean that -cpu westmere
On 03/25/2012 08:01 PM, Anthony Liguori wrote:
I don't think this came out of happiness, but despair. Seriously,
keeping compatibility is one of the things we work hardest to achieve,
and we can't manage it for our command line?
I hate to burst your bubble, but we struggle and rarely
On 03/25/2012 10:40 AM, Avi Kivity wrote:
On 03/25/2012 05:26 PM, Anthony Liguori wrote:
Put the emphasis around *configuration*.
So how about:
1) Load ['@SYSCONFDIR@/qemu/qemu.cfg',
'@SYSCONFDIR@/qemu/target-@ARCH@.cfg',
'@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg']
2)
Hi Stefan,
I finally added make check to the default factory.
Note, if the make check fails the mail will state:
BUILD FAILED: failed test
It's failing on yuzuki due to missing bc.
Could you install bc on your buildslave?
You might want to do a manual make check in your buildslave to check
Hello Paul,
Vadim is the owner of virtio-block Windows driver. He will try to help you.
Best regards,
Yan.
On Mar 23, 2012, at 7:32 PM, Paul Fisher wrote:
Dear Yan,
We seem to be having some trouble with virtio disk on Windows Server 2008 R2
running on qemu-kvm. Essentially, when disk IO
These two patches override the user specific locale settings which
can break QEMU builds. They set the default locale C for configure
and make:
[PATCH v2 1/2] Makefile: Set default locale C
[PATCH 2/2] configure: Set default locale C (fix build for Turkish
A side effect is that all messages
Some locale settings let make fail or create wrong results,
so set always the C locale.
* Conversion from lower to upper case with tr does not convert
lower case 'i' to 'I' with locale tr_TR.UTF-8. This results in
wrong entries in config-host.h like these ones:
#define CONFIG_QEMU_PREFiX
Some locales don't work with QEMU's configure because they
don't convert lower case to upper case as expected.
With the Turkish locale tr_TR.UTF-8 for example the command 'tr'
does not convert lower case 'i' which results in wrong definitions
in some target specific config-target.mak files:
** Patch added: configure: Set default locale C (fix build for Turkish
locale)
https://bugs.launchpad.net/qemu/+bug/962880/+attachment/2936088/+files/0002-configure-Set-default-locale-C-fix-build-for-Turkish.patch
** Changed in: qemu
Status: New = Confirmed
--
You received this
Am 25.03.2012 21:11, schrieb Stefan Weil:
These two patches override the user specific locale settings which
can break QEMU builds. They set the default locale C for configure
and make:
[PATCH v2 1/2] Makefile: Set default locale C
[PATCH 2/2] configure: Set default locale C (fix build for
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
qga/commands-posix.c | 111 +
1 files changed, 66 insertions(+), 45 deletions(-)
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 7b2be2f..faf970d 100644
---
On Sat, Mar 24, 2012 at 09:19:20PM -0400, Brad Smith wrote:
On 20/03/12 9:28 AM, Brad Smith wrote:
On 20/03/12 6:14 AM, Michal Privoznik wrote:
On 18.03.2012 02:09, Brad Smith wrote:
Michal,
http://git.qemu.org/?p=qemu.git;a=commit;h=3424fc9f16a1e7d1c48eb6d605eb0ca63e199ec2
This
Am 25.03.2012 21:27, schrieb Andreas Färber:
Am 25.03.2012 21:11, schrieb Stefan Weil:
These two patches override the user specific locale settings which
can break QEMU builds. They set the default locale C for configure
and make:
[PATCH v2 1/2] Makefile: Set default locale C
[PATCH 2/2]
On 25 March 2012 20:27, Andreas Färber afaer...@suse.de wrote:
Am 25.03.2012 21:11, schrieb Stefan Weil:
These two patches override the user specific locale settings which
can break QEMU builds. They set the default locale C for configure
and make:
[PATCH v2 1/2] Makefile: Set default locale
Am 25.03.2012 21:52, schrieb Peter Maydell:
On 25 March 2012 20:27, Andreas Färber afaer...@suse.de wrote:
Am 25.03.2012 21:11, schrieb Stefan Weil:
These two patches override the user specific locale settings which
can break QEMU builds. They set the default locale C for configure
and make:
32-bit sparc hasn't worked in quite a while. Missing opcodes,
incorrect opcodes, unconditional use of ASI_PRIMARY_LITTLE.
This patch set begins by dropping support for pre-v9 sparc.
This lets us clean things up quite a bit, using 64-bit load
and store operations.
I was still having problems
Signed-off-by: Richard Henderson r...@twiddle.net
---
exec-all.h |9 ++---
tcg/sparc/tcg-target.c | 19 ---
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/exec-all.h b/exec-all.h
index 93a5b22..f7d4708 100644
--- a/exec-all.h
+++
And change from %i4 to %g1 to remove a v8plus fixme.
Signed-off-by: Richard Henderson r...@twiddle.net
---
tcg/sparc/tcg-target.c | 110 ---
1 files changed, 56 insertions(+), 54 deletions(-)
diff --git a/tcg/sparc/tcg-target.c
Signed-off-by: Richard Henderson r...@twiddle.net
---
tcg/sparc/tcg-target.c | 235 +--
1 files changed, 125 insertions(+), 110 deletions(-)
diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
index 9891648..d45114f 100644
---
Signed-off-by: Richard Henderson r...@twiddle.net
---
dyngen-exec.h | 20 +++-
exec.c| 16 ++--
2 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/dyngen-exec.h b/dyngen-exec.h
index 65fcb43..d673f9f 100644
--- a/dyngen-exec.h
+++
Signed-off-by: Richard Henderson r...@twiddle.net
---
tcg/sparc/tcg-target.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
index 0e71618..358a70c 100644
--- a/tcg/sparc/tcg-target.c
+++ b/tcg/sparc/tcg-target.c
@@ -242,7
Current code doesn't actually work in 32-bit mode at all. Since
no one really noticed, drop the complication of v7 and v8 cpus.
Eliminate the --sparc_cpu configure option and standardize macro
testing on TCG_TARGET_REG_BITS.
Signed-off-by: Richard Henderson r...@twiddle.net
---
configure
On 03/24/2012 11:58 AM, Blue Swirl wrote:
v2: fix patch 1, tweak patch 2 and rebase to master.
URL git://repo.or.cz/qemu/blueswirl.git
http://repo.or.cz/r/qemu/blueswirl.git
Blue Swirl (6):
arm: move neon_tbl to neon_helper.c
arm: move saturating arithmetic to helper.c
The xtensa-test image generates a sra_i32 with count 0x40.
Whether this is accident of tcg constant propagation or
originating directly from the instruction stream is immaterial.
Signed-off-by: Richard Henderson r...@twiddle.net
---
tcg/sparc/tcg-target.c | 18 --
1 files
Signed-off-by: Richard Henderson r...@twiddle.net
---
dyngen-exec.h |5 +
user-exec.c | 17 ++---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/dyngen-exec.h b/dyngen-exec.h
index cfeef99..65fcb43 100644
--- a/dyngen-exec.h
+++ b/dyngen-exec.h
@@ -19,6
At the same time, split out the tlb load logic to a new function.
Fixes the cases of two data registers and two address registers.
Fixes the signature of, and adds missing, qemu_ld/st opcodes.
Signed-off-by: Richard Henderson r...@twiddle.net
---
tcg/sparc/tcg-target.c | 751
Given that we have an opcode for all sizes, all endianness,
turn the functions into a simple table lookup.
Signed-off-by: Richard Henderson r...@twiddle.net
---
tcg/sparc/tcg-target.c | 209 +---
1 files changed, 56 insertions(+), 153 deletions(-)
Signed-off-by: Richard Henderson r...@twiddle.net
---
tcg/sparc/tcg-target.c |3 ++-
tcg/sparc/tcg-target.h |9 +
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
index d45114f..dc36840 100644
---
Don't use -ffixed-gN. Don't link statically. Don't save/restore
AREG0 around calls. Don't allocate space on the stack for AREG0 save.
Signed-off-by: Richard Henderson r...@twiddle.net
---
configure | 12 --
tcg/sparc/tcg-target.c | 57
Not actually implemented, but at least we avoid the tcg assert
at startup.
Signed-off-by: Richard Henderson r...@twiddle.net
---
tcg/sparc/tcg-target.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
index
Signed-off-by: Richard Henderson r...@twiddle.net
---
tcg/sparc/tcg-target.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
index 896fab1..ce7c44e 100644
--- a/tcg/sparc/tcg-target.c
+++
Signed-off-by: Richard Henderson r...@twiddle.net
---
configure |2 ++
tcg/sparc/tcg-target.c | 40 +---
tcg/sparc/tcg-target.h |2 ++
3 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/configure b/configure
index
On Sat, Mar 24, 2012 at 12:01 AM, Richard Henderson r...@twiddle.net wrote:
+DEF_HELPER_1(absqsph, i32, i32)
Many of these helpers merely compute a function. They do not trap,
they do not modify global state. They should be using the
DEF_HELPER_FLAGS_N macro to define them, so that the TCG
At 03/23/2012 08:02 PM, HATAYAMA Daisuke Wrote:
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 05/11 v10] Add API to get memory mapping
Date: Tue, 20 Mar 2012 11:51:18 +0800
Add API to get all virtual address and physical address mapping.
If the guest doesn't use paging, the
At 03/23/2012 05:40 PM, HATAYAMA Daisuke Wrote:
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 11/11 v10] introduce a new monitor command
'dump-guest-memory' to dump guest's memory
Date: Tue, 20 Mar 2012 11:57:43 +0800
+/* get the memory's offset in the vmcore */
+static
At 03/23/2012 05:00 PM, HATAYAMA Daisuke Wrote:
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 11/11 v10] introduce a new monitor command
'dump-guest-memory' to dump guest's memory
Date: Tue, 20 Mar 2012 11:57:43 +0800
+static int write_elf64_header(DumpState *s)
+{
+
Currently the virtio balloon device, when using the virtio-pci interface
advertises itself with PCI class code MEMORY_RAM. This is wrong; the
balloon is vaguely related to memory, but is nothing like a PCI memory
device in the meaning of the class code, and this code is not required or
suggested
At 03/24/2012 01:19 AM, Luiz Capitulino Wrote:
On Tue, 20 Mar 2012 11:57:43 +0800
Wen Congyang we...@cn.fujitsu.com wrote:
The command's usage:
dump [-p] protocol [begin] [length]
The supported protocol can be file or fd:
1. file: the protocol starts with file:, and the following string
At 03/24/2012 01:07 AM, Luiz Capitulino Wrote:
On Fri, 23 Mar 2012 17:06:22 +0900 ( )
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 11/11 v10] introduce a new monitor command
'dump-guest-memory' to dump guest's memory
Date:
From: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Wanpeng Li l...@linux.vnet.ibm.com
---
memory.c | 94 ++
memory.h |8 +
2 files changed, 78 insertions(+), 24
From: Anthony Liguori aligu...@us.ibm.com
The HPET usually sits on the LPC bus (which replaces ISA in modern systems).
It's sometimes a dedicated chip but can certain co-exist in a Super IO chip.
I think in terms of where it would live in this hypothetical device model,
putting it in the
From: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Wanpeng Li l...@linux.vnet.ibm.com
---
hw/pci_host.c | 26 ++
hw/pci_host.h |5 +
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git
From: Wen Congyang we...@cn.fujitsu.com
Subject: Re: [PATCH 05/11 v10] Add API to get memory mapping
Date: Mon, 26 Mar 2012 09:10:52 +0800
At 03/23/2012 08:02 PM, HATAYAMA Daisuke Wrote:
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 05/11 v10] Add API to get memory mapping
Date:
From: Anthony Liguori aligu...@us.ibm.com
This series aggressively refactors the PC machine initialization to be more
modelled and less ad-hoc. The highlights of this series are:
1) Things like -m and -bios-name are now device model properties
2) The i440fx and piix3 are now modelled in a
From: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Wanpeng Li l...@linux.vnet.ibm.com
---
hw/pc.c | 22 +++---
hw/pc.h | 26 --
2 files changed, 11 insertions(+), 37 deletions(-)
diff --git
From: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Wanpeng Li l...@linux.vnet.ibm.com
---
Makefile.target |1 -
hw/pc.c | 816 +--
hw/pc.h | 20 +-
hw/pc_piix.c
From: Anthony Liguori aligu...@us.ibm.com
The big picture about the patch is shown as follows:
1) pc_init creates an I440FX, any bus devices (ISA serial port, PCI
vga and nics, etc.), sets properties appropriately, and realizes the
devices.
2) I440FX is-a PCIHost, has-a I440FX-PMC, has-a PIIX3
At 03/26/2012 10:31 AM, HATAYAMA Daisuke Wrote:
From: Wen Congyang we...@cn.fujitsu.com
Subject: Re: [PATCH 05/11 v10] Add API to get memory mapping
Date: Mon, 26 Mar 2012 09:10:52 +0800
At 03/23/2012 08:02 PM, HATAYAMA Daisuke Wrote:
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH
From: Wen Congyang we...@cn.fujitsu.com
Subject: Re: [PATCH 11/11 v10] introduce a new monitor command
'dump-guest-memory' to dump guest's memory
Date: Mon, 26 Mar 2012 09:39:24 +0800
At 03/23/2012 05:40 PM, HATAYAMA Daisuke Wrote:
From: Wen Congyang we...@cn.fujitsu.com
Subject: [PATCH 11/11
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Sending the patchset is mainly intended to get some comments and void the wrong
development direction.
The patchset is used to qomify -netdev, but it introduce one infrastructure for
host devices based on raw Class and Object, not qdev. So they are
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
include/qemu/hostdev.h | 128 ++
qom/Makefile |2 +-
qom/hostdev.c | 333
3 files changed, 462
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c| 54 +-
net.h|2 ++
net/slirp.c | 33 +
net/slirp.h |1 +
net/socket.c | 33
Sorry, pls ignore this patch
On Mon, Mar 26, 2012 at 1:40 PM, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
cpu-common.h | 13 +-
hw/qdev-monitor.c | 4 ++-
hw/qdev.h | 2 +
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net/slirp.c | 42 ++
net/slirp.h |7 +++
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/net/slirp.c b/net/slirp.c
index
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net.c b/net.c
index ff8ddaf..22ed51b 100644
--- a/net.c
+++ b/net.c
@@ -549,15 +549,17 @@ int
A lot of property get/set functions in qdev-properties.c are related
to DeviceState. So i have to copy and modify some of them here to
apply our host device model. In the future, we should make those
functions more generic.
On Mon, Mar 26, 2012 at 1:40 PM, zwu.ker...@gmail.com wrote:
From: Zhi
90 matches
Mail list logo
