Antoine Martin wrote:
> I've tried various guests, including most recent Fedora12 kernels,
> custom 2.6.32.x
> All of them hang around the same point (~1GB written) when I do heavy IO
> write inside the guest.
[]
> Host is running: 2.6.31.4
> QEMU PC emulator version 0.10.50 (qemu-kvm-devel-88)
Pl
On Thu, Jan 21, 2010 at 07:47:22AM -0800, H. Peter Anvin wrote:
> On 01/21/2010 01:02 AM, Avi Kivity wrote:
> >>
> >> You can also just emulate the state transition -- since you know
> >> you're dealing with a flat protected-mode or long-mode OS (and just
> >> make that a condition of enabling the
On Thu, Jan 21, 2010 at 05:35:08PM -0600, Jimmy Crossley wrote:
> I am now running qemu-kvm 0.11.1:
>
> $ kvm -h | head -1
> QEMU PC emulator version 0.11.1 (qemu-kvm-0.11.1), Copyright (c) 2003-2008
> Fabrice Bellard
>
> My Windows 7 guest detected a lot of new hardware, but I still have the sa
vcpu->arch.mce_banks is malloc in kvm_arch_vcpu_init(), but
never free in any place, this may cause memory leak. So this
patch fixed to free it in kvm_arch_vcpu_uninit().
Signed-off-by: Wei Yongjun
---
arch/x86/kvm/x86.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ar
In function kvm_arch_vcpu_init(), if the memory malloc for
vcpu->arch.mce_banks is fail, it does not free the memory
of lapic date. This patch fixed it.
Signed-off-by: Wei Yongjun
---
arch/x86/kvm/x86.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86
vcpu->arch.mce_banks is malloc in kvm_arch_vcpu_init(), but
never free in any place, this may cause memory leak. So this
patch fixed to free it in kvm_arch_vcpu_uninit().
Signed-off-by: Wei Yongjun
---
arch/x86/kvm/x86.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ar
On Thu, Jan 21, 2010 at 09:24:36PM -0800, Aaron Clausen wrote:
> I'm trying once again to get PCI passthrough working (KVM 84 on Ubuntu
> 9.10), and I'm getting this error :
>
> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
> /usr/bin/kvm -S -M pc-0.11 -m 4096 -smp 4 -
On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
> Gleb Natapov wrote:
> > On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
> >>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00
> >>> 2001
> >> From: Liu, Jinsong
> >> Date: Fri, 22 Jan 2010 03:18:46 +08
I'm trying once again to get PCI passthrough working (KVM 84 on Ubuntu
9.10), and I'm getting this error :
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
/usr/bin/kvm -S -M pc-0.11 -m 4096 -smp 4 -name mailserver -uuid
76a83471-e94a-3658-fa61-8eceaa74ffc2 -monitor
unix:
So now I can step instruction but my breakpoints do not work. I have
verified that disabling kvm restores the breakpoint functionality. Any
suggestions?
Thanks,
Nicholas
Jan Kiszka wrote:
Hi Nicholas,
please don't drop CCs on reply.
Nicholas Amon wrote:
Hi Jan,
Thanks for responding
On Friday 22 January 2010 02:41:35 Saksena, Abhishek wrote:
> Hi All,
> Is there a way in KVM to measure the real physical (CPU) time consumed by
> each running Virtual CPU? (I want to do time profiling of the virtual
> machines running on host system)
>
> Also, is there an explanation somewher
The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO content is small.
2. The writing interval is big.
3. No ne
Gleb Natapov wrote:
> On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
>>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00
>>> 2001
>> From: Liu, Jinsong
>> Date: Fri, 22 Jan 2010 03:18:46 +0800
>> Subject: [PATCH] Setup vcpu add/remove infrastructure,
>> in
Avi Kivity wrote:
> On 01/21/2010 01:54 PM, Liu, Jinsong wrote:
>> Avi,
>>
>> I just send 2 patches for KVM vcpu hotplug support.
>> 1 is seabios patch: Setup vcpu add/remove infrastructure, including
>> madt bios_info and dsdt 2 is qemu-kvm patch: Debug vcpu add
>>
>>
>
> The patches look reas
On Wed, Jan 20, 2010 at 06:20:20PM +0100, Jan Kiszka wrote:
> Major parts of this series were already posted a while ago during the
> debug register switch optimizations. This version now comes with an
> additional fix for VMX (patch 1) and a rework of mov dr emulation for
> SVM.
>
> Find this ser
Hi,
With this small disk image:
http://psy.jim.sh/~jim/tmp/diskimage.gz
and the new qemu-kvm-0.12.2:
$ kvm --version
QEMU PC emulator version 0.12.2 (qemu-kvm-0.12.2), Copyright (c) 2003-2008
Fabrice Bellard
I can successfully boot to a "grub> " prompt with:
$ kvm -drive file=diskima
I am now running qemu-kvm 0.11.1:
$ kvm -h | head -1
QEMU PC emulator version 0.11.1 (qemu-kvm-0.11.1), Copyright (c) 2003-2008
Fabrice Bellard
My Windows 7 guest detected a lot of new hardware, but I still have the same
key repeating problem. I think I will just leave this alone for now since
On 21.01.2010, at 18:36, Marcelo Tosatti wrote:
> On Thu, Jan 21, 2010 at 12:19:07PM +0100, Christian Borntraeger wrote:
>> v2: apply Avis suggestions about ARRAY_SIZE.
>>
>> kvm_handle_sie_intercept uses a jump table to get the intercept handler
>> for a SIE intercept. Static code analysis reve
No sorry, I haven't any performance data with noop. I even don't
have had a crash. BUT I've experienced serve I/O degradation
with noop. Once I've written a big chunk of data (e.g. a simple
rsync -av /usr /opt) with noop it works for a while and
after a few seconds I saw heavy writes which made the
On Thursday 21 January 2010 21:08:38 RW wrote:
> Some months ago I also thought elevator=noop should be a good idea.
> But it isn't. It works good as long as you only do short IO requests.
> Try using deadline in host and guest.
>
> Robert
@Robert: I've been using noop on all of my KVMs and didn'
Some months ago I also thought elevator=noop should be a good idea.
But it isn't. It works good as long as you only do short IO requests.
Try using deadline in host and guest.
Robert
On 01/21/10 18:26, Antoine Martin wrote:
> I've tried various guests, including most recent Fedora12 kernels,
> c
On 01/21/2010 10:43 AM, john cooper wrote:
Anthony Liguori wrote:
On 01/20/2010 07:18 PM, john cooper wrote:
I can appreciate the concern of wanting to get this
as "correct" as possible.
This is the root of the trouble. At the qemu layer, we try to focus on
being correct.
Hi All,
Is there a way in KVM to measure the real physical (CPU) time consumed by each
running Virtual CPU? (I want to do time profiling of the virtual machines
running on host system)
Also, is there an explanation somewhere on how Virtual CPU scheduling is
achieved in KVM?
Thanks
Abhishek
--
Jamie Lokier wrote:
> I think we can all agree that there is no point looking for a familiar
> -cpu naming scheme because there aren't any familiar and meaningful names
> these days.
Even if we dismiss the Intel coined names as internal
code names, there is still VMW's use of them in this
space w
Jamie Lokier wrote:
> Do you mean that more powerful management tools to support safe
> migration will maintain _their own_ processor model tables, and
> perform their calculations using their own tables instead of querying
> qemu, and therefore not have any need of qemu's built in table?
I would
john cooper wrote:
> I can appreciate the argument above, however the goal was
> choosing names with some basis in reality. These were
> recommended by our contacts within Intel, are used by VmWare
> to describe their similar cpu models, and arguably have fallen
> to defacto usage as evidenced by
On Thu, Jan 21, 2010 at 07:57:22PM +0200, Avi Kivity wrote:
> On 01/21/2010 07:56 PM, Avi Kivity wrote:
>> On 01/21/2010 07:45 PM, Michael S. Tsirkin wrote:
>>>
But you're in process context. An eventfd never blocks.
>>> Yes it blocks if counter is 0. And we don't know
>>> it's not 0 unless w
On Wed, Jan 20, 2010 at 11:58:48AM +0100, Gerd Hoffmann wrote:
> Nowdays (qemu 0.12) seabios loads option roms from pci rom bars. So
> there is no need any more to scan for option roms and have qemu load
> them. Zap the code.
>
> Signed-off-by: Gerd Hoffmann
Applied, thanks.
--
To unsubscribe
On Wed, Jan 20, 2010 at 04:47:21PM +0900, Takuya Yoshikawa wrote:
> The return values from x86_emulate_ops are defined
> in kvm_emulate.h as macros X86EMUL_*.
>
> But in emulate.c, we are comparing the return values
> from these ops with 0 to check if they're X86EMUL_CONTINUE
> or not: X86EMUL_CON
On Thu, Jan 21, 2010 at 12:19:07PM +0100, Christian Borntraeger wrote:
> v2: apply Avis suggestions about ARRAY_SIZE.
>
> kvm_handle_sie_intercept uses a jump table to get the intercept handler
> for a SIE intercept. Static code analysis revealed a potential problem:
> the intercept_funcs jump tab
On Tue, Jan 12, 2010 at 10:21:27PM +0100, Jan Kiszka wrote:
> Since kvm-kmod-2.6.32.2 we have an alternative source for recent KVM
> kernel headers. Use it when available and not overruled by --kerneldir.
> If there is no kvm-kmod and no --kerneldir, we continue to fall back to
> the qemu-kvm's ker
On Thu, Jan 21, 2010 at 04:20:04PM +0800, Sheng Yang wrote:
> The commit 0953ca73 "KVM: Simplify coalesced mmio initialization"
> allocate kvm_coalesced_mmio_ring in the kvm_coalesced_mmio_init(), but
> didn't discard the original allocation...
>
> Signed-off-by: Sheng Yang
Applied, thanks.
--
On Wed, Jan 20, 2010 at 12:46:28PM +0100, Juan Quintela wrote:
> This substitution got missed somehow
>
> Signed-off-by: Juan Quintela
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 01/21/2010 07:56 PM, Avi Kivity wrote:
On 01/21/2010 07:45 PM, Michael S. Tsirkin wrote:
But you're in process context. An eventfd never blocks.
Yes it blocks if counter is 0. And we don't know
it's not 0 unless we read :) catch-22.
Ah yes, I forgot.
Well, you can poll it and then re
On 01/21/2010 07:45 PM, Michael S. Tsirkin wrote:
But you're in process context. An eventfd never blocks.
Yes it blocks if counter is 0. And we don't know
it's not 0 unless we read :) catch-22.
Ah yes, I forgot.
--
Do not meddle in the internals of kernels, for they are subtle an
john cooper wrote:
> > I foresee wanting to iterate over the models and pick the latest one
> > which a host supports - on the grounds that you have done the hard
> > work of ensuring it is a reasonably good performer, while "probably"
> > working on another host of similar capability when a new ho
On Thu, Jan 21, 2010 at 09:50:34AM -0800, Davide Libenzi wrote:
> On Thu, 21 Jan 2010, Avi Kivity wrote:
>
> > On 01/21/2010 07:32 PM, Michael S. Tsirkin wrote:
> > >
> > > > Can't you read from the file?
> > > >
> > > IMO no, the read could block.
> > >
> >
> > But you're in process c
john cooper wrote:
> kvm itself can modify flags exported from qemu to a guest.
I would hope for an option to request that qemu doesn't run if the
guest won't get the cpuid flags requested on the command line.
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body
On Thu, 21 Jan 2010, Avi Kivity wrote:
> On 01/21/2010 07:32 PM, Michael S. Tsirkin wrote:
> >
> > > Can't you read from the file?
> > >
> > IMO no, the read could block.
> >
>
> But you're in process context. An eventfd never blocks.
Can you control the eventfd flags? Because if yes
On Thu, Jan 21, 2010 at 07:47:40PM +0200, Avi Kivity wrote:
> On 01/21/2010 07:32 PM, Michael S. Tsirkin wrote:
>>
>>> Can't you read from the file?
>>>
>> IMO no, the read could block.
>>
>
> But you're in process context. An eventfd never blocks.
Yes it blocks if counter is 0. And we
On 01/21/2010 07:32 PM, Michael S. Tsirkin wrote:
Can't you read from the file?
IMO no, the read could block.
But you're in process context. An eventfd never blocks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from thi
On Thu, Jan 21, 2010 at 07:33:02PM +0200, Avi Kivity wrote:
> On 01/21/2010 07:23 PM, Michael S. Tsirkin wrote:
>>
>>> I agree.
>>>
>>> But I think we can solve this in another way in .32: we can clear the
>>> eventfd from irqfd->inject work, which is in process context. The new
>>> stuff is only
I've tried various guests, including most recent Fedora12 kernels,
custom 2.6.32.x
All of them hang around the same point (~1GB written) when I do heavy IO
write inside the guest.
I have waited 30 minutes to see if the guest would recover, but it just
sits there, not writing back any data, not d
On 01/21/2010 07:23 PM, Michael S. Tsirkin wrote:
I agree.
But I think we can solve this in another way in .32: we can clear the
eventfd from irqfd->inject work, which is in process context. The new
stuff is only needed for lockless clearing, no?
No, AFAIK there's no way to clear the c
On Thu, Jan 21, 2010 at 07:13:13PM +0200, Avi Kivity wrote:
> On 01/21/2010 06:58 PM, Davide Libenzi wrote:
>> On Thu, 21 Jan 2010, Michael S. Tsirkin wrote:
>>
>>
>>> This is a backport of commit: 03db343a6320f780937078433fa7d8da955e6fce
>>> modified in a way that introduces some code duplicat
On 01/21/2010 07:13 PM, Avi Kivity wrote:
But I think we can solve this in another way in .32: we can clear the
eventfd from irqfd->inject work, which is in process context. The new
stuff is only needed for lockless clearing, no?
I meant atomic clearing, when we inject interrupts from the
On 01/21/2010 06:58 PM, Davide Libenzi wrote:
On Thu, 21 Jan 2010, Michael S. Tsirkin wrote:
This is a backport of commit: 03db343a6320f780937078433fa7d8da955e6fce
modified in a way that introduces some code duplication on the one hand,
but reduces the risk of regressing existing eventfd us
On Thu, Jan 21, 2010 at 2:39 PM, Andre Przywara wrote:
> john cooper wrote:
>>
>> Chris Wright wrote:
>>>
>>> * Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu ' are just as
unfriendly as each other. The only user friendly option is
On Thu, 21 Jan 2010, Michael S. Tsirkin wrote:
> This is a backport of commit: 03db343a6320f780937078433fa7d8da955e6fce
> modified in a way that introduces some code duplication on the one hand,
> but reduces the risk of regressing existing eventfd users on the other
> hand.
>
> KVM needs a wait
Anthony Liguori wrote:
> On 01/20/2010 07:18 PM, john cooper wrote:
>> I can appreciate the concern of wanting to get this
>> as "correct" as possible.
>>
>
> This is the root of the trouble. At the qemu layer, we try to focus on
> being correct.
>
> Management tools are typically the layer
This is a backport of commit: 03db343a6320f780937078433fa7d8da955e6fce
modified in a way that introduces some code duplication on the one hand,
but reduces the risk of regressing existing eventfd users on the other
hand.
KVM needs a wait to atomically remove themselves from the eventfd
->poll() wa
On 01/21/2010 01:02 AM, Avi Kivity wrote:
>>
>> You can also just emulate the state transition -- since you know
>> you're dealing with a flat protected-mode or long-mode OS (and just
>> make that a condition of enabling the feature) you don't have to deal
>> with all the strange combinations of di
On 01/20/2010 07:18 PM, john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise
john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu ' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme & document it. G
Luvalley is a lightweight type-1 Virtual Machine Monitor (VMM).
Its part of source codes are derived from KVM to virtualize
CPU instructions and memory management unit (MMU). However, its
overall architecture is completely different from KVM, but somewhat
like Xen. Luvalley runs outside of Linux, j
Hello:
I am using kvm on a CentOS 5.4 server.
I am trying to install the TunkeyLinux Core appliance
found here: http://www.turnkeylinux.org/core
I downloaded the ISO file from the web site.
Then, I used this command to intall it:
virt-install -n tkl-core -r 512 --vcpus=1 --check-cpu --os-type=
'mask' is always a constant, so we can check whether it includes a bit that
might be owned by the guest very cheaply, and avoid the decache call. Saves
a few hundred bytes of module text.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/kvm_cache_regs.h |9 +++--
1 files changed, 7 insertions
They have more general scope than the mmu.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/emulate.c |1 -
arch/x86/kvm/mmu.c |1 +
arch/x86/kvm/mmu.h | 24
arch/x86/kvm/x86.h | 24
4 files changed, 25 insertions(+), 25 deletio
None of the other registers have the shadow_ prefix.
Signed-off-by: Avi Kivity
---
arch/x86/include/asm/kvm_host.h |2 +-
arch/x86/kvm/mmu.c |2 +-
arch/x86/kvm/svm.c | 12 ++--
arch/x86/kvm/vmx.c | 14 +++---
arch/x86/kvm/x86.c
Signed-off-by: Avi Kivity
---
arch/x86/kvm/x86.c |2 ++
include/trace/events/kvm.h | 19 +++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8b42c19..06a03c1 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/
Not used anymore.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/x86.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e3145d5..feca59f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5305,7 +5305,6 @@ void kvm_load
Signed-off-by: Avi Kivity
---
arch/x86/kvm/emulate.c |9 -
arch/x86/kvm/vmx.c |4 ++--
arch/x86/kvm/x86.c |7 +++
arch/x86/kvm/x86.h |6 ++
4 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
Assume that if the guest executes clts, it knows what it's doing, and load the
guest fpu to prevent an #NM exception.
Signed-off-by: Avi Kivity
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/svm.c |8 +++-
arch/x86/kvm/vmx.c |1 +
arch/x86/kvm/x8
This allows accessing the guest fpu from the instruction emulator, as well as
being symmetric with kvm_put_guest_fpu().
Signed-off-by: Avi Kivity
---
arch/x86/kvm/x86.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 47c6
Mostly trivial cleanups with the exception of a patch activating the fpu
on clts.
Avi Kivity (8):
KVM: Allow kvm_load_guest_fpu() even when !vcpu->fpu_active
KVM: Drop kvm_{load,put}_guest_fpu() exports
KVM: Activate fpu on clts
KVM: Add a helper for checking if the guest is in protected m
Move to/from Control Registers chapter of Intel SDM says. "Reserved bits
in CR0 remain clear after any load of those registers; attempts to set
them have no impact". Control Register chapter says "Bits 63:32 of CR0 are
reserved and must be written with zeros. Writing a nonzero value to any
of the
On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
> >From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong
> Date: Fri, 22 Jan 2010 03:18:46 +0800
> Subject: [PATCH] Setup vcpu add/remove infrastructure, including madt
> bios_info and dsdt
On Thursday 21 January 2010 19:50:17 Liu, Jinsong wrote:
> From 479e84d9ce9d7d78d845f438071a4b1a44aca0bb Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong
> Date: Fri, 22 Jan 2010 03:30:33 +0800
> Subject: [PATCH] Debug vcpu add
Jinsong, this name is pretty strange...
I think something like "Fix
On 01/21/2010 01:54 PM, Liu, Jinsong wrote:
Avi,
I just send 2 patches for KVM vcpu hotplug support.
1 is seabios patch: Setup vcpu add/remove infrastructure, including madt
bios_info and dsdt
2 is qemu-kvm patch: Debug vcpu add
The patches look reasonable (of course I'd like to see Gleb
On 21.01.2010, at 09:09, Liu Yu-B13201 wrote:
>
>
>> -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;
Avi,
I just send 2 patches for KVM vcpu hotplug support.
1 is seabios patch: Setup vcpu add/remove infrastructure, including madt
bios_info and dsdt
2 is qemu-kvm patch: Debug vcpu add
Thanks,
Jinsong--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to ma
>From 479e84d9ce9d7d78d845f438071a4b1a44aca0bb Mon Sep 17 00:00:00 2001
From: Liu, Jinsong
Date: Fri, 22 Jan 2010 03:30:33 +0800
Subject: [PATCH] Debug vcpu add
Add 'kvm_vcpu_inited' check so that when adding vcpu it will not
cause segmentation fault. This is especially necessary when
>From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong
Date: Fri, 22 Jan 2010 03:18:46 +0800
Subject: [PATCH] Setup vcpu add/remove infrastructure, including madt
bios_info and dsdt.
1. setup madt bios_info structure, so that static dsdt get
Am Donnerstag 21 Januar 2010 12:24:18 schrieb Heiko Carstens:
> > - if (code & 3 || code > 0x48)
> > + if (code & 3 || (code >> 2) >= ARRAY_SIZE(intercept_funcs))
> > return -ENOTSUPP;
>
> Not that it matters for this patch, but -ENOTSUPP should not leak to
> userspace. Not sure i
> - if (code & 3 || code > 0x48)
> + if (code & 3 || (code >> 2) >= ARRAY_SIZE(intercept_funcs))
> return -ENOTSUPP;
Not that it matters for this patch, but -ENOTSUPP should not leak to
userspace. Not sure if it does somewhere, but it is used all over the
place within arch/s
v2: apply Avis suggestions about ARRAY_SIZE.
kvm_handle_sie_intercept uses a jump table to get the intercept handler
for a SIE intercept. Static code analysis revealed a potential problem:
the intercept_funcs jump table was defined to contain (0x48 >> 2) entries,
but we only checked for code > 0x4
On 01/21/2010 12:56 PM, Christian Borntraeger wrote:
Avi, Marcelo,
kvm_handle_sie_intercept uses a jump table to get the intercept handler
for a SIE intercept. Static code analysis revealed a potential problem:
the intercept_funcs jump table was defined to contain (0x48>> 2) entries,
but we onl
Avi, Marcelo,
kvm_handle_sie_intercept uses a jump table to get the intercept handler
for a SIE intercept. Static code analysis revealed a potential problem:
the intercept_funcs jump table was defined to contain (0x48 >> 2) entries,
but we only checked for code > 0x48 which would cause an off-by-o
On 01/20/2010 07:20 PM, Jan Kiszka wrote:
Major parts of this series were already posted a while ago during the
debug register switch optimizations. This version now comes with an
additional fix for VMX (patch 1) and a rework of mov dr emulation for
SVM.
Looks good.
--
error compiling commi
On 01/21/2010 11:37 AM, Sheng Yang wrote:
The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO content is sma
The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.
But this would result in a very late writing in some condition.
1. The each time write to MMIO content is small.
2. The writing interval is big.
3. No ne
On 01/21/2010 11:04 AM, Gleb Natapov wrote:
Do you mean create the stack frame manually? I'd really like to
avoid that for many reasons, one of which is performance (need to do
all the virt-to-phys walks manually), the other is that we're
certain to end up with something horribly underspecifie
On Thu, Jan 21, 2010 at 11:02:19AM +0200, Avi Kivity wrote:
> On 01/20/2010 07:43 PM, H. Peter Anvin wrote:
> >On 01/20/2010 02:02 AM, Gleb Natapov wrote:
> >>
> >>>You can have the guest OS take an exception on a vector above 31 just
> >>>fine; you just need it to tell the hypervisor which vector
On 01/20/2010 07:43 PM, H. Peter Anvin wrote:
On 01/20/2010 02:02 AM, Gleb Natapov wrote:
You can have the guest OS take an exception on a vector above 31 just
fine; you just need it to tell the hypervisor which vector it, the OS,
assigned for this purpose.
VMX doesn't allow to inject hardwar
On 01/20/2010 08:45 PM, H. Peter Anvin wrote:
On 01/20/2010 04:00 AM, Avi Kivity wrote:
On 01/20/2010 12:02 PM, Gleb Natapov wrote:
I can inject the event as HW interrupt on vector greater then 32 but not
go through APIC so EOI will not be required. This sounds
non-architectural
and I
On 01/20/2010 07:18 PM, Rik van Riel wrote:
On 01/20/2010 07:00 AM, Avi Kivity wrote:
On 01/20/2010 12:02 PM, Gleb Natapov wrote:
I can inject the event as HW interrupt on vector greater then 32 but
not
go through APIC so EOI will not be required. This sounds
non-architectural
and I am not s
The commit 0953ca73 "KVM: Simplify coalesced mmio initialization"
allocate kvm_coalesced_mmio_ring in the kvm_coalesced_mmio_init(), but
didn't discard the original allocation...
Signed-off-by: Sheng Yang
---
virt/kvm/kvm_main.c | 17 -
1 files changed, 0 insertions(+), 17 dele
> -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]
88 matches
Mail list logo
