On 07/13/2011 09:45 AM, Pekka Enberg wrote:
>
> OK, what's the simplest thing we can do here to keep Avi happy and get
> the functionality of Sasha's original patch that helps us avoid guest
> exits for serial console? I agree with Avi that we don't want
> fragmented ABI but it seems to me th
On Sun, Jul 10, 2011 at 8:34 AM, Sasha Levin wrote:
> After working on that solution a bit I saw it's adding a lot of code and
> complexity for this small issue, and I'm now thinking we may be better
> off with just handling reads twice in case of a signal just between
> socket_write() and socket_
On Wed, Jul 13, 2011 at 10:07 AM, Avi Kivity wrote:
> - the writes are such high frequency that we gain something from the
> queueing is happens when we thread work. That's where the gain for serial
> console can come from - though it would be better to just use virtio-serial
> instead.
We'd lik
On Wed, Jul 13, 2011 at 10:51 AM, Pekka Enberg wrote:
> On Sun, Jul 10, 2011 at 8:34 AM, Sasha Levin wrote:
>> After working on that solution a bit I saw it's adding a lot of code and
>> complexity for this small issue, and I'm now thinking we may be better
>> off with just handling reads twice i
On Wed, 2011-07-13 at 13:04 +0300, Pekka Enberg wrote:
> On Wed, Jul 13, 2011 at 10:51 AM, Pekka Enberg wrote:
> > On Sun, Jul 10, 2011 at 8:34 AM, Sasha Levin
> > wrote:
> >> After working on that solution a bit I saw it's adding a lot of code and
> >> complexity for this small issue, and I'm n
On Wed, Jul 13, 2011 at 1:26 PM, Sasha Levin wrote:
> The problem is that if we received a signal during the read notification
> the write and before receiving the read, we have to go back to
> userspace.
>
> This means that userspace will see same read request twice (once in the
> socket and once
On Wed, Jul 13, 2011 at 1:56 PM, Pekka Enberg wrote:
> On Wed, Jul 13, 2011 at 1:26 PM, Sasha Levin wrote:
>> The problem is that if we received a signal during the read notification
>> the write and before receiving the read, we have to go back to
>> userspace.
>>
>> This means that userspace wi
On 07/13/2011 11:02 AM, Pekka Enberg wrote:
On Wed, Jul 13, 2011 at 10:07 AM, Avi Kivity wrote:
> - the writes are such high frequency that we gain something from the
> queueing is happens when we thread work. That's where the gain for serial
> console can come from - though it would be bett
On Wed, Jul 13, 2011 at 3:57 PM, Avi Kivity wrote:
>> We'd like to keep 8250 emulation because it's the most robust method
>> for getting data out of the kernel when there's problems. It's also
>> compatible with earlyprintk and such.
>
> What do you hope to gain from the optimization? 100ms less
On 07/13/2011 09:22 AM, Tian, Kevin wrote:
it works in my side, due to config difference. It is caused by recent
steal time feature.
int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
case MSR_KVM_STEAL_TIME:
if (unlikely(!sched_info_on()))
On 07/12/2011 11:00 PM, Jan Kiszka wrote:
From: Jan Kiszka
Comparison takes precedence over bitwise&, but the latter needs to be
evaluated first here.
Thanks, applied.
Avi, how's your 32-bit buildbot?
Seems to be working perfectly.
--
error compiling committee.c: too many arguments to fu
On 07/09/2011 03:25 PM, Sasha Levin wrote:
The patch raises the hard limit of VCPU count to 1024.
This will allow developers to easily work on scalability
and will allow users to test high VCPU setups easily without
patching the kernel.
To prevent possible issues with current setups, KVM_CAP_NR
On 07/13/2011 04:00 PM, Pekka Enberg wrote:
On Wed, Jul 13, 2011 at 3:57 PM, Avi Kivity wrote:
>> We'd like to keep 8250 emulation because it's the most robust method
>> for getting data out of the kernel when there's problems. It's also
>> compatible with earlyprintk and such.
>
> What do y
From: Joerg Roedel
Reorder the function a little bit to move interrupt related
code together and the tlb-flush from the middle of the
function towards the end.
Signed-off-by: Joerg Roedel
---
arch/x86/kvm/svm.c | 31 ---
1 files changed, 16 insertions(+), 15 delet
From: Joerg Roedel
This patch introduces a new pointer which always points to
the VMCB used for running the L1 guest.
Signed-off-by: Joerg Roedel
---
arch/x86/kvm/svm.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 4
From: Joerg Roedel
Move torwards emulation of VMCB-clean-bits by using a
seperate VMCB when running L2 guests.
Signed-off-by: Joerg Roedel
---
arch/x86/kvm/svm.c | 43 ---
1 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm
Rather than changing the host intercepts in
nested_svm_vmrun, mask the intercepts we only want to see
from the guest out in recalc_intercepts.
Signed-off-by: Joerg Roedel
---
arch/x86/kvm/svm.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm
From: Joerg Roedel
All state is keept in svm->host_vmcb so the hsave is not
necessary anymore, so remote it.
Signed-off-by: Joerg Roedel
---
arch/x86/kvm/svm.c | 151 ++--
1 files changed, 41 insertions(+), 110 deletions(-)
diff --git a/arch/x8
Hi Avi, Marcelo,
here is a patch-set that implements a shadow-vmcb for nested SVM. The
shadow-vmcb is always used when the L2-guest is invoked. This saves some
memory copys in the nested vmrun and vmexit paths because the contents
of the host-vmcb do not need to be saved/restored anymore.
This pa
This saves copying over the vmload/vmsave switched part from
the host to the guest vmcb later.
Signed-off-by: Joerg Roedel
---
arch/x86/kvm/svm.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 3d5990f..dc703ac 100644
-
From: Joerg Roedel
This patch moves the unsetting of the hflags used for
nesting into the #vmexit path instead of doing everything in
the vmrun path.
Signed-off-by: Joerg Roedel
---
arch/x86/kvm/svm.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch
The paravirt/xen bits in ia64 are already in bit-rot. I have this
build error in upstream building the arch/ia64/configs/xen_domu_defconfig
(even before applying your latest patch):
drivers/xen/grant-table.c: In function 'gnttab_map_refs':
drivers/xen/grant-table.c:491: error: implicit declaratio
On Wed, 2011-07-13 at 16:30 +0300, Avi Kivity wrote:
> On 07/09/2011 03:25 PM, Sasha Levin wrote:
> > The patch raises the hard limit of VCPU count to 1024.
> >
> > This will allow developers to easily work on scalability
> > and will allow users to test high VCPU setups easily without
> > patching
Following patch is implemented to deal with the VCPU and iothread starvation
during the migration of a guest. Currently iothread is responsible for
performing the migration. It holds the qemu_mutex during the migration and
doesn't allow VCPU to enter the qemu mode and delays its return to the gu
24 matches
Mail list logo
