Hi Marcelo and guys,
On Wed, Jan 6, 2010 at 11:24 PM, Ryota Ozaki ozaki.ry...@gmail.com wrote:
On Wed, Jan 6, 2010 at 10:59 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Jan 06, 2010 at 10:07:25PM +0900, Ryota Ozaki wrote:
[...]
I know virtio balloon can changes amount of
guest
On Sun, Jan 10, 2010 at 05:33:02PM +0900, Ryota Ozaki wrote:
On Sun, Jan 10, 2010 at 3:39 PM, Gleb Natapov g...@redhat.com wrote:
On Sat, Jan 09, 2010 at 04:30:11PM -0300, Daniel Bareiro wrote:
On Friday, 08 January 2010 19:35:04 +0900,
Ryota Ozaki wrote:
Hi all,
Hi, Ryota.
Currently we don't intercept cr0 at all when npt is enabled. This improves
performance but requires us to activate the fpu at all times.
Remove this behaviour in preparation for adding selective cr0 intercepts.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/svm.c | 30
Instead of selecting TS and MP as the comments say, the macro included TS and
PE. Luckily the macro is unused now, but fix in order to save a few hours of
debugging from anyone who attempts to use it.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/include/asm/svm.h |2 +-
1 files
This patchset (on top of the previous cr0 patchset) brings lazy fpu to npt.
For the cases where guest and host cr0 match (the majority) it will disable
intercepts for cr0.ts once the guest fpu is loaded, so the guest can to its
own lazy fpu without trapping.
v2:
Refactored last patch into
Follow the hardware.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6e6f188..ca42ae3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -428,6 +428,8
If two conditions apply:
- no bits outside TS and EM differ between the host and guest cr0
- the fpu is active
then we can activate the selective cr0 write intercept and drop the
unconditional cr0 read and write intercept, and allow the guest to run
with the host fpu state. This reduces cr0
Now that we can allow the guest to play with cr0 when the fpu is loaded,
we can enable lazy fpu when npt is in use.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/svm.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/svm.c
init_vmcb() sets up the intercepts as if the fpu is active, so initialize it
there. This avoids an INIT from setting up intercepts inconsistent with
fpu_active.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/svm.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff
On Thu, Jan 07, 2010 at 04:26:24PM -0800, Davide Libenzi wrote:
On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
Sure, I was trying to be as brief as possible, here's a detailed summary.
Description of the system (MSI emulation in KVM):
KVM supports an ioctl to assign/deassign an
In order to improve qemu.git kvm integration quality wrt performance,
features, and reliability Marcelo and I will begin to maintain a patch
queue based on qemu.git containing kvm-related patches. We will review
and apply patches to this queue, test them using the same test suite
that is used
On 01/10/2010 04:27 AM, Alexander Graf wrote:
When we get a program interrupt in guest kernel mode, we try to emulate the
instruction.
If that doesn't fail, we report to the user and try again - at the exact same
instruction pointer. So if the guest kernel really does trigger an invalid
On 01/07/2010 07:02 PM, rek2 wrote:
Hi guys, it happen again (in this server I didn't patch with the fix
you guys sent) but I did this so if it happen i can test with
tcpdump.. seems that the guest can receive packages but can't sent...
when I open a tcpdump I saw traffic coming in, but not
On 10.01.2010, at 13:22, Avi Kivity wrote:
On 01/10/2010 04:27 AM, Alexander Graf wrote:
When we get a program interrupt in guest kernel mode, we try to emulate the
instruction.
If that doesn't fail, we report to the user and try again - at the exact same
instruction pointer. So if the
On 01/08/2010 09:37 PM, Alexander Graf wrote:
Yes, but I'd rather minimize the behavioral changes as long as we can't test it.
Right. That's why the semantics of flags are Book3S specific right now and as
such the comment is correct.
The behavioral change we need to do later is to
On Sun, Jan 10, 2010 at 02:30:12PM +0200, Avi Kivity wrote:
This isn't in 2.6.27.y. Herbert, can you send it there?
It appears that now that TX is fixed we have a similar problem
with RX. Once I figure that one out I'll send them together.
Who is maintaining that BTW, sta...@kernel.org?
On 01/08/2010 05:40 PM, Christoph Hellwig wrote:
Maybe we should pick one on image creation and then stick to it. For an
image format we could write down this information in the image, but for
a raw images that's impossible.
The management system should remember it (like it remembers
On 01/10/2010 02:32 PM, Alexander Graf wrote:
Applied both, and queued for .33. I was able to guess this from the
description, but please mention it explicitly in the future.
I'm not sure what to mention. From a stability point of view, all the Book3S
patches should go in .33
On 01/10/2010 02:35 PM, Herbert Xu wrote:
On Sun, Jan 10, 2010 at 02:30:12PM +0200, Avi Kivity wrote:
This isn't in 2.6.27.y. Herbert, can you send it there?
It appears that now that TX is fixed we have a similar problem
with RX. Once I figure that one out I'll send them together.
On 01/07/2010 10:35 PM, Bruce Rogers wrote:
This is the part which applies to qemu-kvm.
Applied, thanks.
@@ -1938,7 +1938,7 @@ DEF(readconfig, HAS_ARG, QEMU_OPTION_readconfig,
-readconfigfile\n)
DEF(writeconfig, HAS_ARG, QEMU_OPTION_writeconfig,
-writeconfigfile\n
-
On 10.01.2010, at 13:37, Avi Kivity wrote:
On 01/10/2010 02:32 PM, Alexander Graf wrote:
Applied both, and queued for .33. I was able to guess this from the
description, but please mention it explicitly in the future.
I'm not sure what to mention. From a stability point of
On 10.01.2010, at 13:34, Avi Kivity wrote:
On 01/08/2010 09:37 PM, Alexander Graf wrote:
Yes, but I'd rather minimize the behavioral changes as long as we can't
test it.
Right. That's why the semantics of flags are Book3S specific right now and
as such the comment is correct.
On 01/10/2010 02:48 PM, Alexander Graf wrote:
What's the conclusion here? Do we need a respin or is this good enough?
From my point of view this is good. Hollis and I were just both agreeing that
it would be nice to move BookE to a similar concept. That really isn't in the
scope of
On 12/01/2009 03:53 PM, Pierre Riteau wrote:
Signed-off-by: Pierre Riteaupierre.rit...@irisa.fr
---
configure |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 376c458..85f7b5e 100755
--- a/configure
+++ b/configure
@@ -723,10 +723,10
On 11/30/2009 01:54 PM, Harald Dunkel wrote:
Sorry, wrong kernel. Here is the output for 2.6.31.6:
[ 374.736010] BUG: soft lockup - CPU#0 stuck for 61s! [ntpd:1657]
[ 374.736010] Modules linked in: ipv6 loop snd_pcm snd_timer snd soundcore
snd_page_alloc virtio_balloon psmouse serio_raw
Bugs item #2907597, was opened at 2009-12-02 18:57
Message generated for change (Settings changed) made by avik
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2907597group_id=180599
Please note that this message will contain a full copy of the comment
Bugs item #2923097, was opened at 2009-12-30 00:37
Message generated for change (Settings changed) made by avik
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2923097group_id=180599
Please note that this message will contain a full copy of the comment
Bugs item #2907597, was opened at 2009-12-02 18:57
Message generated for change (Comment added) made by avik
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2907597group_id=180599
Please note that this message will contain a full copy of the comment
On 10 janv. 2010, at 15:02, Avi Kivity wrote:
On 12/01/2009 03:53 PM, Pierre Riteau wrote:
Signed-off-by: Pierre Riteaupierre.rit...@irisa.fr
---
configure |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 376c458..85f7b5e 100755
On 01/10/2010 04:20 PM, Pierre Riteau wrote:
Not sure the new names are any better than the old ones.
I'm not sure I understand... I fixed the names in the help output to make them
consistent with the options actually recognized by configure.
If you don't like the names you are free to
On 01/10/2010 02:22 PM, Avi Kivity wrote:
On 01/10/2010 04:27 AM, Alexander Graf wrote:
When we get a program interrupt in guest kernel mode, we try to
emulate the
instruction.
If that doesn't fail, we report to the user and try again - at the
exact same
instruction pointer. So if the guest
On Sun, Jan 10, 2010 at 02:02:27PM +0200, Avi Kivity wrote:
In order to improve qemu.git kvm integration quality wrt
performance, features, and reliability Marcelo and I will begin to
maintain a patch queue based on qemu.git containing kvm-related
patches. We will review and apply patches to
On 01/10/2010 04:28 PM, Gleb Natapov wrote:
On Sun, Jan 10, 2010 at 02:02:27PM +0200, Avi Kivity wrote:
In order to improve qemu.git kvm integration quality wrt
performance, features, and reliability Marcelo and I will begin to
maintain a patch queue based on qemu.git containing kvm-related
On Sun, Jan 10, 2010 at 04:30:44PM +0200, Avi Kivity wrote:
On 01/10/2010 04:28 PM, Gleb Natapov wrote:
On Sun, Jan 10, 2010 at 02:02:27PM +0200, Avi Kivity wrote:
In order to improve qemu.git kvm integration quality wrt
performance, features, and reliability Marcelo and I will begin to
On 01/10/2010 04:49 PM, Gleb Natapov wrote:
If the feature is already in both, then morph qemu-kvm.git into what
is already in qemu.git. Hopefully anything missing in qemu.git will
be discovered while making the changes.
What about bugs that are present only in qemu.git? Like this:
On 10.01.2010, at 15:26, Avi Kivity wrote:
On 01/10/2010 02:22 PM, Avi Kivity wrote:
On 01/10/2010 04:27 AM, Alexander Graf wrote:
When we get a program interrupt in guest kernel mode, we try to emulate the
instruction.
If that doesn't fail, we report to the user and try again - at the
On 01/10/2010 05:06 PM, Alexander Graf wrote:
I get this building ppc32:
PPC32? That shouldn't even allow enabling KVM O_o.
You know, the embedded stuff.
Enabled config options:
VIRTUALIZATION=y
KVM=y
KVM_440=y
KVM_E500=n
KVM_EXIT_TIMING=n
--
error compiling committee.c: too
On Sun, 10 Jan 2010, Michael S. Tsirkin wrote:
What is you do (under proper irqfd locking) something like:
eventfd_ctx_read(ctx, 1, cnt);
if (irqfd-cnt != cnt) {
irqfd-cnt = cnt;
schedule_work(irqfd-inject);
}
And deactivation deep
On 10.01.2010, at 16:09, Avi Kivity wrote:
On 01/10/2010 05:06 PM, Alexander Graf wrote:
I get this building ppc32:
PPC32? That shouldn't even allow enabling KVM O_o.
You know, the embedded stuff.
Hm, that patch is based on the big patchset I sent earlier. Are you sure you
On 01/10/2010 05:28 PM, Alexander Graf wrote:
Hm, that patch is based on the big patchset I sent earlier. Are you sure you
have applied them in the correct order?
Probably not. Will reorder and retry.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe
On 01/10/2010 05:37 PM, Avi Kivity wrote:
On 01/10/2010 05:28 PM, Alexander Graf wrote:
Hm, that patch is based on the big patchset I sent earlier. Are you
sure you have applied them in the correct order?
Probably not. Will reorder and retry.
No, still fails. Please take a look at
Bugs item #2907597, was opened at 2009-12-02 18:57
Message generated for change (Comment added) made by avik
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2907597group_id=180599
Please note that this message will contain a full copy of the comment
On 01/10/2010 06:26 PM, SourceForge.net wrote:
Initial Comment:
So I am running using the VESA driver to run an Ubuntu 9.10 guest at 2560x1600
(I had to modify the xserver-video-vesa package to remove an internal screen
limit of 2048x2048 in the xorg vesa driver) and everything works great
Apparently my last series broke BookE compilation.
This patch makes it compile again.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kernel/asm-offsets.c |2 +-
arch/powerpc/kvm/44x_emulate.c|8
arch/powerpc/kvm/booke_emulate.c | 12 ++--
While trying to compile an E500 vmlinux, I stumbled across a compilation bug
that was obviously there before I touched any of the code. A trace point
doesn't get the correct arguments.
Since that shouldn't be any critical to the functionality of the code, my quick
workaround is to #if 0 it out. I
On Sun, 10 Jan 2010, Michael S. Tsirkin wrote:
Not sure what you mean by irqfd locking. IMO we must take waitqueue
lock, otherwise we can not prevent wait queue callback from being
invoked, right? Note that if we take our own lock under wait queue
callback, we won't be able to use this lock
On Sun, Jan 10, 2010 at 09:27:34AM -0800, Davide Libenzi wrote:
On Sun, 10 Jan 2010, Michael S. Tsirkin wrote:
Not sure what you mean by irqfd locking. IMO we must take waitqueue
lock, otherwise we can not prevent wait queue callback from being
invoked, right? Note that if we take our
On Sun, 10 Jan 2010, Michael S. Tsirkin wrote:
On Sun, Jan 10, 2010 at 09:27:34AM -0800, Davide Libenzi wrote:
On Sun, 10 Jan 2010, Michael S. Tsirkin wrote:
Not sure what you mean by irqfd locking. IMO we must take waitqueue
lock, otherwise we can not prevent wait queue callback
I have a multifunction PCI device that I'd like to pass through to KVM.
In order to do that, I'm reading that the PCI memory region must be 4K-page
aligned and the PCI memory resources itself must also be exact multiples
of 4K pages.
I have added the following on my kernel command
I guess I'll run the things I've found by the list to see if I'm off
track or not.
There is this patch:
http://marc.info/?l=xen-develm=124748015304566w=4
which would seem to be related to what I'm doing, trying to pass through
a multifunction device (a Ricoh firewire controller which has
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org
[mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard
Sent: Saturday, January 09, 2010 3:30 AM
To: Alexander Graf
Cc: kvm@vger.kernel.org; kvm-ppc; Benjamin Herrenschmidt; Liu Yu
Subject: Re: [PATCH 7/9] KVM:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Monday, January 11, 2010 1:02 AM
To: kvm@vger.kernel.org
Cc: kvm-ppc; Liu Yu-B13201
Subject: [PATCH] KVM: PPC: E500 compile fix
While trying to compile an E500 vmlinux, I stumbled across a
compilation bug
On Sun, Jan 10, 2010 at 11:04:23AM -0800, Davide Libenzi wrote:
On Sun, 10 Jan 2010, Michael S. Tsirkin wrote:
On Sun, Jan 10, 2010 at 09:27:34AM -0800, Davide Libenzi wrote:
On Sun, 10 Jan 2010, Michael S. Tsirkin wrote:
Not sure what you mean by irqfd locking. IMO we must take
On Sun, Jan 10, 2010 at 04:52:48PM +0200, Avi Kivity wrote:
On 01/10/2010 04:49 PM, Gleb Natapov wrote:
If the feature is already in both, then morph qemu-kvm.git into what
is already in qemu.git. Hopefully anything missing in qemu.git will
be discovered while making the changes.
What
On 01/10/2010 04:27 AM, Alexander Graf wrote:
When we get a program interrupt in guest kernel mode, we try to emulate the
instruction.
If that doesn't fail, we report to the user and try again - at the exact same
instruction pointer. So if the guest kernel really does trigger an invalid
On 10.01.2010, at 15:26, Avi Kivity wrote:
On 01/10/2010 02:22 PM, Avi Kivity wrote:
On 01/10/2010 04:27 AM, Alexander Graf wrote:
When we get a program interrupt in guest kernel mode, we try to emulate the
instruction.
If that doesn't fail, we report to the user and try again - at the
On 01/10/2010 05:06 PM, Alexander Graf wrote:
I get this building ppc32:
PPC32? That shouldn't even allow enabling KVM O_o.
You know, the embedded stuff.
Enabled config options:
VIRTUALIZATION=y
KVM=y
KVM_440=y
KVM_E500=n
KVM_EXIT_TIMING=n
--
error compiling committee.c: too
On 10.01.2010, at 16:09, Avi Kivity wrote:
On 01/10/2010 05:06 PM, Alexander Graf wrote:
I get this building ppc32:
PPC32? That shouldn't even allow enabling KVM O_o.
You know, the embedded stuff.
Hm, that patch is based on the big patchset I sent earlier. Are you sure you
On 01/10/2010 05:28 PM, Alexander Graf wrote:
Hm, that patch is based on the big patchset I sent earlier. Are you sure you
have applied them in the correct order?
Probably not. Will reorder and retry.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe
While trying to compile an E500 vmlinux, I stumbled across a compilation bug
that was obviously there before I touched any of the code. A trace point
doesn't get the correct arguments.
Since that shouldn't be any critical to the functionality of the code, my quick
workaround is to #if 0 it out. I
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org
[mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard
Sent: Saturday, January 09, 2010 3:30 AM
To: Alexander Graf
Cc: k...@vger.kernel.org; kvm-ppc; Benjamin Herrenschmidt; Liu Yu
Subject: Re: [PATCH 7/9] KVM:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Monday, January 11, 2010 1:02 AM
To: k...@vger.kernel.org
Cc: kvm-ppc; Liu Yu-B13201
Subject: [PATCH] KVM: PPC: E500 compile fix
While trying to compile an E500 vmlinux, I stumbled across a
compilation bug
62 matches
Mail list logo
