From: Wei Yongjun yj...@cn.fujitsu.com
Just remove redundant semicolon.
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 31f4526..8a52616 100644
--- a/arch/x86/kvm/emulate.c
+++
From: Avi Kivity a...@redhat.com
These features are unused by modern userspace and can go away. Paravirt
mmu needs to stay a little longer for live migration.
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/Documentation/feature-removal-schedule.txt
From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/13/2010 08:10 PM, Marcelo Tosatti wrote:
How's that? Feel free to upgrade it.
--
Document that partially emulated instructions leave the guest state
unconsistent, and that the kernel must complete operations before
checking for pending signals.
Signed-off-by: Marcelo
Gleb Natapov wrote:
On Sat, Feb 13, 2010 at 08:20:41PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sat, Feb 13, 2010 at 07:41:35PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sat, Feb 13, 2010 at 06:49:44PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sat, Feb 13, 2010 at
From: Jan Kiszka jan.kis...@siemens.com
Based on Gleb's suggestion: To avoid that user space migrates a pending
software exception or interrupt, mask them out on KVM_GET_VCPU_EVENTS.
Without this, user space would try to reinject them, and we would have
to reconstruct the proper instruction
On Sun, Feb 14, 2010 at 11:20:44AM +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
Based on Gleb's suggestion: To avoid that user space migrates a pending
software exception or interrupt, mask them out on KVM_GET_VCPU_EVENTS.
Without this, user space would try to reinject
Gleb Natapov wrote:
On Sat, Feb 13, 2010 at 10:31:12AM +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
We intercept #BP while in guest debugging mode. As VM exists due to
intercepted exceptions do not necessarily come with valid
idt_vectoring, we have to update
Thanks Markus!
I will try it, and tell you.
Another question: when sdl draw guest OS uses some kind of 2d
acceleration on host side?
2010/2/13 Markus Breitländer breitlaen...@stud.fh-dortmund.de:
You can alter the sound driver settings by setting some variables before
starting the VM.
I use
On 02/14/2010 12:34 PM, Gleb Natapov wrote:
event_exit_inst_len is only used for event reinjection. Since event
intercepted here will not be reinjected why updating event_exit_inst_len
is needed here?
In guest debugging mode a #BP exception is always reported to user space
to find out
On 02/13/2010 03:26 PM, Marcelo Tosatti wrote:
On Thu, Feb 11, 2010 at 12:09:12AM +0100, Paolo Bonzini wrote:
This patch series morphs the code in qemu-kvm's eventfd so that it looks
like the code in upstream qemu. Patch 4 is not yet in upstream QEMU,
I'm submitting it first to qemu-kvm to
On 02/12/2010 04:03 AM, OHMURA Kei wrote:
On 02/11/2010 Anthony Liguori anth...@codemonkey.ws wrote:
Oh, I see what's happening here. Yes, I think a leul_to_cpu() makes more
sense.
Maybe I'm missing something here.
I couldn't find leul_to_cpu(), so have defined it in bswap.h.
Avi Kivity wrote:
On 02/14/2010 12:34 PM, Gleb Natapov wrote:
event_exit_inst_len is only used for event reinjection. Since event
intercepted here will not be reinjected why updating
event_exit_inst_len
is needed here?
In guest debugging mode a #BP exception is always reported to
On Sun, Feb 14, 2010 at 01:39:41PM +0100, Jan Kiszka wrote:
Avi Kivity wrote:
On 02/14/2010 12:34 PM, Gleb Natapov wrote:
event_exit_inst_len is only used for event reinjection. Since event
intercepted here will not be reinjected why updating
event_exit_inst_len
is needed here?
On 02/14/2010 02:43 PM, Gleb Natapov wrote:
Nice.
[ /me goes updating his manual - September 07... ]
I can't find nothing newer then that. What is the link?
http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html
--
error compiling committee.c: too many
On Sun, Feb 14, 2010 at 02:47:39PM +0200, Avi Kivity wrote:
On 02/14/2010 02:43 PM, Gleb Natapov wrote:
Nice.
[ /me goes updating his manual - September 07... ]
I can't find nothing newer then that. What is the link?
Avi Kivity wrote:
On 02/14/2010 02:43 PM, Gleb Natapov wrote:
Nice.
[ /me goes updating his manual - September 07... ]
I can't find nothing newer then that. What is the link?
http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html
For the records,
Jan Kiszka wrote:
Avi Kivity wrote:
On 02/14/2010 02:43 PM, Gleb Natapov wrote:
Nice.
[ /me goes updating his manual - September 07... ]
I can't find nothing newer then that. What is the link?
http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html
On 02/13/2010 08:20 PM, Jan Kiszka wrote:
But I still fail to see the case where event_exit_inst_len is set to
anything but 1 or 2 and where it is related to anything else than exits
at INT3, INT X, or INTO.
What about BOUND? (I want to hide for suggesting anyone uses that
instruction).
On 02/14/2010 01:39 PM, Jan Kiszka wrote:
that will work for both VMX and SVM before applying patches that make
oly VMX work?
VMX used to work, so my patch is actually a regression fix. I bet this
was accidentally broken while cleaning up the interrupt handling of VMX.
Care to post
On Sun, Feb 14, 2010 at 02:44:39PM +0100, Paolo Bonzini wrote:
On 02/13/2010 08:20 PM, Jan Kiszka wrote:
But I still fail to see the case where event_exit_inst_len is set to
anything but 1 or 2 and where it is related to anything else than exits
at INT3, INT X, or INTO.
What about BOUND?
On Sun, Feb 14, 2010 at 12:39:14PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 11:47:58AM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 11:26:31AM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sat, Feb 13, 2010 at 10:31:12AM +0100, Jan
On 02/14/2010 03:44 PM, Paolo Bonzini wrote:
On 02/13/2010 08:20 PM, Jan Kiszka wrote:
But I still fail to see the case where event_exit_inst_len is set to
anything but 1 or 2 and where it is related to anything else than exits
at INT3, INT X, or INTO.
What about BOUND? (I want to hide for
Recent days I am trying to modify kvm for some research. And I
encounter some problems that I can not understand. Please give some
help on that.
I try to monitor the msr register's cs,eip. And I find
that the value in the guest is always be zero for these registers. I
try to watch it
- Lucas Meneghel Rodrigues l...@redhat.com wrote:
In order to adapt all the OS unattended installs to parallel
installs, finish.exe also had to be adapted to be a server
instead of a client. These are the modifications needed.
Once the whole patchset is worked out, an updated version
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 12:39:14PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 11:47:58AM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 11:26:31AM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sat, Feb 13, 2010 at
Avi Kivity wrote:
On 02/14/2010 01:39 PM, Jan Kiszka wrote:
that will work for both VMX and SVM before applying patches that make
oly VMX work?
VMX used to work, so my patch is actually a regression fix. I bet this
was accidentally broken while cleaning up the interrupt handling of
On 02/14/2010 06:38 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 02/14/2010 01:39 PM, Jan Kiszka wrote:
that will work for both VMX and SVM before applying patches that make
oly VMX work?
VMX used to work, so my patch is actually a regression fix. I bet this
was
From: Jan Kiszka jan.kis...@siemens.com
The interrupt shadow created by STI or MOV-SS-like operations is part of
the VCPU state and must be preserved across migration. Transfer it in
the spare padding field of kvm_vcpu_events.interrupt.
As a side effect we now have to make
On Sun, Feb 14, 2010 at 05:37:39PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 12:39:14PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 11:47:58AM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 11:26:31AM +0100, Jan
On 02/14/2010 06:49 PM, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
The interrupt shadow created by STI or MOV-SS-like operations is part of
the VCPU state and must be preserved across migration. Transfer it in
the spare padding field of kvm_vcpu_events.interrupt.
As a side effect
Avi Kivity wrote:
On 02/14/2010 06:38 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 02/14/2010 01:39 PM, Jan Kiszka wrote:
that will work for both VMX and SVM before applying patches that make
oly VMX work?
VMX used to work, so my patch is actually a regression fix. I bet
- Lucas Meneghel Rodrigues l...@redhat.com wrote:
As our configuration system generates a list of dicts
with test parameters, and that list might be potentially
*very* large, keeping all this information in memory might
be a problem for smaller virtualization hosts due to
the memory
Avi Kivity wrote:
On 02/14/2010 06:49 PM, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
The interrupt shadow created by STI or MOV-SS-like operations is part of
the VCPU state and must be preserved across migration. Transfer it in
the spare padding field of
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 05:37:39PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 12:39:14PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 11:47:58AM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at
On Sun, Feb 14, 2010 at 06:06:31PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 05:37:39PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 12:39:14PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 11:47:58AM +0100, Jan
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 06:06:31PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 05:37:39PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at 12:39:14PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Feb 14, 2010 at
From: Jan Kiszka jan.kis...@siemens.com
Stolen from Xen: Instead if stepping over IRET, use the interrupt shadow
to inject the NMI on IRET while still deferring its delivery after the
instruction. This has the same limitation as the existing approach:
Exceptions raised by the IRET will trigger an
From: Michael S. Tsirkin m...@redhat.com
Date: Sat, 13 Feb 2010 19:39:11 +0200
Dave, I see it's marked not applicable:
http://patchwork.ozlabs.org/patch/44207/
the patch applies to net-next as of
b3b3f04fb587ecb61b5baa6c1c5f0e666fd12d73.
Can this be queued up please?
Should I resubmit with
On 02/14/2010 07:07 PM, Michael Goldish wrote:
- Lucas Meneghel Rodriguesl...@redhat.com wrote:
As our configuration system generates a list of dicts
with test parameters, and that list might be potentially
*very* large, keeping all this information in memory might
be a problem for
Avi Kivity wrote:
On 02/12/2010 04:08 AM, OHMURA Kei wrote:
Why do you need a counter? It may be sufficient to set a single bit.
This reduces the memory overhead and perhaps cache thrashing.
Thanks for looking into this. I agree with your opinion.
Our motivation here is to skip traveling when
dirty-bitmap-traveling is carried out by byte size in qemu-kvm.c.
But We think that dirty-bitmap-traveling by long size is faster than by byte
size especially when most of memory is not dirty.
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
bswap.h|2 ++
qemu-kvm.c | 31
On 02/14/2010 07:06 PM, Jan Kiszka wrote:
Needs a KVM_CAP_ and flags bit.
Why if merged before 2.6.33? We haven't released KVM_CAP_VCPU_EVENTS yet.
Userspace already knows the interrupt shadow mask free variant. Maybe
it all works out, but KVM_CAP_ bits are cheaper than checking
On 02/14/2010 07:06 PM, Jan Kiszka wrote:
The autotest people (Lucas copied) are generally good at adding tests,
so all we need to do is (a) add a test case to
qemu-kvm.git:kvm/user/test (b) indicate to the autotest people how to
build and run this thing.
I wonder if it requires a
On Sun, Feb 14, 2010 at 06:51:15PM +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
Stolen from Xen: Instead if stepping over IRET, use the interrupt shadow
to inject the NMI on IRET while still deferring its delivery after the
instruction. This has the same limitation as the
45 matches
Mail list logo
