This patch series updates the gdbstub support for kvm.
Patch 12 introduce basic powerpc support while patch 3 fixes gdbstub generic
code that was broken in a qemu merge.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo
# HG changeset patch
# User Christian Ehrhardt [EMAIL PROTECTED]
# Date 1228989956 -3600
# Node ID 6f228c807ad0b239b7342d2974debfc66418d784
# Parent 38846cef16e56c681da1ddc179e248972c8b2ff9
[PATCH] qemu: ppc: kvm-userspace: KVM PowerPC support for qemu gdbstub
From: Hollis Blanchard [EMAIL
# HG changeset patch
# User Christian Ehrhardt [EMAIL PROTECTED]
# Date 1228924564 -3600
# Node ID 38846cef16e56c681da1ddc179e248972c8b2ff9
# Parent 705d874ff7a24484eaa15ed75a748c4e1a70c2ef
[PATCH] kvm-userspace: ppc: Add kvm_translate wrapper
From: Hollis Blanchard [EMAIL PROTECTED]
Add
Hi Weidong,
Thank you for your advice.
The other messages which I found are the following messages which
KVM outputs:
BUG: kvm_destroy_phys_mem: invalid parameters (slot=-1)
BUG: kvm_destroy_phys_mem: invalid parameters (slot=-1)
and, IRQ status is as follows:
/proc/interrupt of the host OS is
Load assigned devices' PCI option ROMs to the RAM of
guest OS. And pass the corresponding devfns to BIOS.
Signed-off-by: Kechao Liu [EMAIL PROTECTED]
---
bios/rombios.c | 20 +-
qemu/hw/device-assignment.c | 140 +++
It's not related to shared irq. MSI is already supported in KVM, so if the
device has MSI capability, there is no sharing irq issue.
Can you try latest kvm.git and kvm-userspace.git? At least you are not using
latest kvm-userspace because there is output BUG: kvm_destroy_phys_mem:
invalid
This is v2 as version one had a type in it occured when splitting patches.
Mercurial somehow lost my changes to the patch description explaining
that, but the patch is right this way.
Christian Ehrhardt wrote:
# HG changeset patch
# User Christian Ehrhardt [EMAIL PROTECTED]
# Date 1228999833
# HG changeset patch
# User Christian Ehrhardt [EMAIL PROTECTED]
# Date 1228999833 -3600
# Node ID dc1466c9077ab162f4637fffee1869f26be02299
# Parent 4c07fe2a56c7653a9113e05bb08c2de9aec210ce
[PATCH] qemu: ppc: kvm-userspace: KVM PowerPC support for qemu gdbstub
From: Hollis Blanchard [EMAIL
My current feeling is that this user thread aio thing will never
satisfy enterprise usage and kernel aio is mandatory in my view. I had
the same feeling before too, but I thought clone aio was desiderable
as intermediate step, because it could help whatever other unix host
OS that may not have
This is just a tiny nitpick I came across while hacking on other stuff.
It reduces the code duplication, hopefully in a good way for other eyes
too.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Code for all versions of notdirty_mem_write are quite alike.
Rewrite it as a generator macro.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
exec.c | 66 ---
1 files changed, 17 insertions(+), 49 deletions(-)
diff --git a/exec.c
Bugs item #2417350, was opened at 2008-12-11 16:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2417350group_id=180599
Please note that this message will contain a full copy of
Bugs item #2417387, was opened at 2008-12-11 16:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2417387group_id=180599
Please note that this message will contain a full copy of
--- On Wed, 12/10/08, Grant Grundler [EMAIL PROTECTED] wrote:
Date: Wednesday, December 10, 2008, 10:33 PM
On Thu, Dec 11, 2008 at 09:43:13AM +0800, Yu Zhao wrote:
...
I believe this is the only problem that preclude us
having the run-time
resource rebalance. And I'm not sure how much
On Thu, Dec 11, 2008 at 04:24:37PM +0100, Gerd Hoffmann wrote:
Well, linux kernel aio has its share of problems too:
* Anthony mentioned it may block on certain circumstances (forgot
which ones), and you can't figure beforehand to turn off aio then.
We've worse problems as long as
There is no point in doing the ready_for_nmi_injection/
request_nmi_window dance with user space. First, we don't do this for
in-kernel irqchip anyway, while the code path is the same as for user
space irqchip mode. And second, there is nothing to loose if a pending
NMI is overwritten by another
Andrea Arcangeli wrote:
* It can't handle block allocation. Kernel handles that by doing
such writes synchronously via VFS layer (instead of the separate
aio code paths). Leads to horrible performance and bug reports
such as installs on sparse files are very slow.
I think
Gerd Hoffmann wrote:
Andrea Arcangeli wrote:
My current feeling is that this user thread aio thing will never
satisfy enterprise usage and kernel aio is mandatory in my view.
Well, linux kernel aio has its share of problems too:
* Anthony mentioned it may block on certain
On Thu, Dec 11, 2008 at 05:11:08PM +0100, Gerd Hoffmann wrote:
Yes. But kernel aio requires O_DIRECT, so aio users are affected
nevertheless.
Are you sure? It surely wasn't the case...
Havn't tested that. Could be it isn't a big problem, extra code size
for the two modes aside.
There
On Mon, 2008-12-08 at 16:09 +, Avi Kivity wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index ba4275d..2d6ca79 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -568,14 +570,17 @@ static bool make_all_cpus_request(struct kvm *kvm,
unsigned int req)
I think it is an unsync tsc problem.
First, make sure you pin all of the process threads. There is thread
per
vcpu + io thread +more non relevant.
You can do it by adding the taskset before the cmdline.
Second, you said that you use smp guest. So windows also sees unsync
tsc.
So, either
Andrea Arcangeli wrote:
On Thu, Dec 11, 2008 at 05:11:08PM +0100, Gerd Hoffmann wrote:
Yes. But kernel aio requires O_DIRECT, so aio users are affected
nevertheless.
Are you sure? It surely wasn't the case...
Tons of docs say so, but might be they are wrong, I didn't check.
Kernel side
Can anyone provide any pointers as to what might cause virtio networking
to be slow (~55Mb/s)? Here's what I've tried so far:
Guests tried:
Windows Server 2003 x32 SP2 UP guest w/ Windows guest drivers ver 3
Windows Server 2003 x64 SP2 SMP guest w/ Windows guest drivers ver 3
On the host:
Avi Kivity wrote:
Jan Kiszka wrote:
When single-stepping, we have to ensure that the INT1 can make it
through even if the guest itself is uninterruptible due to MOV SS or
STI. VMENTRY will fail otherwise.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/vmx.c | 10
Hi,
So one could be preadv+threads. Probably quite portable if we manage to
get the syscalls into linux kernel and glibc. All *BSDs have it
already, for solaris I've found a feature request on that. Dunno for MacOS.
Who's taking care of submitting it to linux?
I will.
cheers,
Gerd
On Thu, Dec 11, 2008 at 05:49:47PM +0100, Andrea Arcangeli wrote:
On Thu, Dec 11, 2008 at 05:11:08PM +0100, Gerd Hoffmann wrote:
Yes. But kernel aio requires O_DIRECT, so aio users are affected
nevertheless.
Are you sure? It surely wasn't the case...
Mainline kernel aio only implements
Bugs item #2418470, was opened at 2008-12-11 23:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2418470group_id=180599
Please note that this message will contain a full copy of
On Thu, Dec 11, 2008 at 07:38:24PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
This looks fine, but have you tested it on a host with unsync tsc?
I'm worried that we'll get regressions there even on uniprocessor
guest. I'd like to keep the current behaviour for the special case
This patch set add E500 support in KVM,
and is already based on Hollis's feedback (a patchset which not yet commit)
btw: The latest code seems broken with this error.
---
CC arch/powerpc/kvm/../../../virt/kvm/kvm_main.o
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c: In function
Signed-off-by: Liu Yu [EMAIL PROTECTED]
---
arch/powerpc/kernel/asm-offsets.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index fc3b863..544a27f 100644
--- a/arch/powerpc/kernel/asm-offsets.c
E500 deosn't support this instruction.
Signed-off-by: Liu Yu [EMAIL PROTECTED]
---
arch/powerpc/kvm/booke_interrupts.S |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/booke_interrupts.S
b/arch/powerpc/kvm/booke_interrupts.S
index 084ebcd..4679ec2
Signed-off-by: Liu Yu [EMAIL PROTECTED]
---
arch/powerpc/include/asm/kvm_e500.h | 67 +++
arch/powerpc/kvm/e500.c | 151 +++
2 files changed, 218 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/kvm_e500.h
Signed-off-by: Liu Yu [EMAIL PROTECTED]
---
arch/powerpc/kvm/e500_emulate.c | 359 +++
1 files changed, 359 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/kvm/e500_emulate.c
diff --git a/arch/powerpc/kvm/e500_emulate.c
E500 needs to update some mmu registers, when itlb or dtlb miss happens.
Signed-off-by: Liu Yu [EMAIL PROTECTED]
---
arch/powerpc/include/asm/kvm_ppc.h |2 ++
arch/powerpc/kvm/44x_tlb.c |8
arch/powerpc/kvm/booke.c |2 ++
3 files changed, 12 insertions(+),
Signed-off-by: Liu Yu [EMAIL PROTECTED]
---
arch/powerpc/kvm/booke.c |2 +-
arch/powerpc/kvm/booke.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 933c406..f192fbe 100644
--- a/arch/powerpc/kvm/booke.c
+++
Signed-off-by: Liu Yu [EMAIL PROTECTED]
---
arch/powerpc/include/asm/kvm_asm.h |7 ++-
arch/powerpc/include/asm/kvm_host.h |2 +-
arch/powerpc/kvm/booke.c| 18 ++
arch/powerpc/kvm/booke.h| 30 ++
# HG changeset patch
# User Christian Ehrhardt [EMAIL PROTECTED]
# Date 1228924564 -3600
# Node ID 38846cef16e56c681da1ddc179e248972c8b2ff9
# Parent 705d874ff7a24484eaa15ed75a748c4e1a70c2ef
[PATCH] kvm-userspace: ppc: Add kvm_translate wrapper
From: Hollis Blanchard [EMAIL PROTECTED]
Add
# HG changeset patch
# User Christian Ehrhardt [EMAIL PROTECTED]
# Date 1228989958 -3600
# Node ID f80fb35de91fe69dae889c70948c9a53212ee444
# Parent 6f228c807ad0b239b7342d2974debfc66418d784
[PATCH] kvm-userspace: fix gdbstub kvm integration
From: Christian Ehrhardt [EMAIL PROTECTED]
Some recent
This is v2 as version one had a type in it occured when splitting patches.
Mercurial somehow lost my changes to the patch description explaining
that, but the patch is right this way.
Christian Ehrhardt wrote:
# HG changeset patch
# User Christian Ehrhardt [EMAIL PROTECTED]
# Date 1228999833
Currently on x86, qemu initializes CPUState but KVM ignores it and does its
own vcpu initialization. However, PowerPC KVM needs to be able to set the
initial register state to support the -kernel and -append options.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
---
kvm-all.c | 15
Implement hooks called by generic KVM code.
Also add code that will copy the host's CPU and timebase frequencies to the
guest, which is necessary on KVM because the guest can directly access the
timebase.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
---
Makefile.target |3 +
To implement the -kernel, -initrd, and -append options, 4xx board emulation
must load the guest kernel as if firmware had loaded it. Where u-boot would be
the firmware, we must load the flat device tree into memory and set key fields
such as /chosen/bootargs.
This patch introduces a dependency on
Wire up the system-on-chip devices present on 440EP chips.
This patch is a little unusual in that qemu doesn't actually emulate the 440
core, but we use this board code with KVM (which does). If/when 440 core
emulation is supported, the kvm_enabled() hack can be removed.
Signed-off-by: Hollis
Hollis Blanchard wrote:
Currently on x86, qemu initializes CPUState but KVM ignores it and does its
own vcpu initialization. However, PowerPC KVM needs to be able to set the
initial register state to support the -kernel and -append options.
Signed-off-by: Hollis Blanchard holl...@us.ibm.com
On 12/11/08, Hollis Blanchard holl...@us.ibm.com wrote:
Since most IO devices are integrated into the 440EP chip, Bamboo support
mostly entails implementing the -kernel, -initrd, and -append options.
These options are implemented by loading the guest as if u-boot had done it,
i.e. loading
Hollis Blanchard wrote:
Since most IO devices are integrated into the 440EP chip, Bamboo support
mostly entails implementing the -kernel, -initrd, and -append options.
These options are implemented by loading the guest as if u-boot had done it,
i.e. loading a flat device tree, updating it to
On Thu, 2008-12-11 at 15:30 -0600, Anthony Liguori wrote:
Hollis Blanchard wrote:
+int kvm_arch_get_registers(CPUState *env)
+{
+ struct kvm_regs regs;
+ uint32_t i, ret;
+
+ ret = kvm_vcpu_ioctl(env, KVM_GET_REGS, regs);
+ if (ret 0)
+ return ret;
+
+
On Thu, 2008-12-11 at 15:39 -0600, Anthony Liguori wrote:
Hollis Blanchard wrote:
+
+#define BINARY_DEVICE_TREE_FILE bamboo.dtb
+
+static void *bamboo_load_device_tree(void *addr,
+ uint32_t ramsize,
+
48 matches
Mail list logo
