At 02/28/2012 01:26 PM, Wen Congyang Wrote:
> At 02/27/2012 11:08 PM, Jan Kiszka Wrote:
>> On 2012-02-27 04:01, Wen Congyang wrote:
>>> We can know the guest is paniced when the guest runs on xen.
>>> But we do not have such feature on kvm. This patch implemnts
>>> this feature, and the implementat
At 02/27/2012 11:08 PM, Jan Kiszka Wrote:
> On 2012-02-27 04:01, Wen Congyang wrote:
>> We can know the guest is paniced when the guest runs on xen.
>> But we do not have such feature on kvm. This patch implemnts
>> this feature, and the implementation is the same as xen:
>> register panic notifier
On Mon, Feb 13, 2012 at 10:24 AM, Peter Lieven wrote:
>
> Am 11.02.2012 um 09:55 schrieb Corentin Chary:
>
>> On Thu, Feb 9, 2012 at 7:08 PM, Peter Lieven wrote:
>>> Hi,
>>>
>>> is anyone aware if there are still problems when enabling the threaded vnc
>>> server?
>>> I saw some VMs crashing when
On 2012-02-19 21:13, Thomas Fjellstrom wrote:
> I'm pretty much stumped on this. So I decided to try re-creating the vm
> through virt-manager. Its up and running now. The only to major differences I
> can see in the old and new config is the machine (-M pc-0.12 vs -M pc-1.0)
> parameter, and th
On 2012-02-28 09:23, Wen Congyang wrote:
> At 02/27/2012 11:08 PM, Jan Kiszka Wrote:
>> On 2012-02-27 04:01, Wen Congyang wrote:
>>> We can know the guest is paniced when the guest runs on xen.
>>> But we do not have such feature on kvm. This patch implemnts
>>> this feature, and the implementation
On Mon, Feb 27, 2012 at 07:48:45PM +, Ian Campbell wrote:
> On Mon, 2012-02-27 at 17:53 +, Dave Martin wrote:
> > On Thu, Feb 23, 2012 at 05:48:22PM +, Stefano Stabellini wrote:
> > > We need a register to pass the hypercall number because we might not
> > > know it at compile time and
On 02/24/2012 08:58 PM, Andy Lutomirski wrote:
> On Thu, Feb 23, 2012 at 8:34 PM, H. Peter Anvin wrote:
> > On 02/16/2012 09:39 AM, Avi Kivity wrote:
> >>>
> >>> Yes, this is on purpose
> >
> > Why?
>
> I think the "this" refers to the PF_INSTR fault when executing at
> 0xff600xxx. That's
At 02/28/2012 05:34 PM, Jan Kiszka Wrote:
> On 2012-02-28 09:23, Wen Congyang wrote:
>> At 02/27/2012 11:08 PM, Jan Kiszka Wrote:
>>> On 2012-02-27 04:01, Wen Congyang wrote:
We can know the guest is paniced when the guest runs on xen.
But we do not have such feature on kvm. This patch im
On 02/23/2012 03:25 PM, Peter Zijlstra wrote:
> On Thu, 2012-02-23 at 20:33 +0900, Takuya Yoshikawa wrote:
> > - Stop allocating extra dirty bitmap buffer area
> >
> > According to Peter, mmu_notifier has become preemptible. If we can
> > change mmu_lock from spin_lock to mutex_lock, as Avi s
On Tue, 2012-02-28 at 09:46 +, Dave Martin wrote:
> On Mon, Feb 27, 2012 at 07:48:45PM +, Ian Campbell wrote:
> > Given that Stefano is proposing to make the ISS a (per-hypervisor)
> > constant we could consider just defining the Thumb and non-Thumb
> > constants instead of doing all the co
On Mon, 2012-02-27 at 21:05 +, Peter Maydell wrote:
> On 27 February 2012 16:27, Ian Campbell wrote:
> > R12 is not accessible from the 16 bit "T1" Thumb encoding of mov
> > immediate (which can only target r0..r7).
> >
> > Since we support only ARMv7+ there are "T2" and "T3" encodings availab
On 2012-02-28 10:42, Wen Congyang wrote:
> At 02/28/2012 05:34 PM, Jan Kiszka Wrote:
>> On 2012-02-28 09:23, Wen Congyang wrote:
>>> At 02/27/2012 11:08 PM, Jan Kiszka Wrote:
On 2012-02-27 04:01, Wen Congyang wrote:
> We can know the guest is paniced when the guest runs on xen.
> But w
On Mon, Feb 27, 2012 at 07:33:39PM +, Ian Campbell wrote:
> On Mon, 2012-02-27 at 18:03 +, Dave Martin wrote:
> > On Mon, Feb 27, 2012 at 04:27:23PM +, Ian Campbell wrote:
> > > On Thu, 2012-02-23 at 17:48 +, Stefano Stabellini wrote:
> > > > We need a register to pass the hypercall
>
> My point is that
>
> qemu-version-A [-cpu whatever]
>
> should provide the same VM as
>
> qemu-version-B -machine pc-A [-cpu whatever]
>
> specifically if you leave out the cpu specification.
>
> So the compat machine could establish a feature mask (e.g. append some
> "-tsc_deadline"
On Tue, Feb 28, 2012 at 11:19:47AM +0100, Jan Kiszka wrote:
> On 2012-02-28 10:42, Wen Congyang wrote:
> > At 02/28/2012 05:34 PM, Jan Kiszka Wrote:
> >> On 2012-02-28 09:23, Wen Congyang wrote:
> >>> At 02/27/2012 11:08 PM, Jan Kiszka Wrote:
> On 2012-02-27 04:01, Wen Congyang wrote:
> >
On Tue, 2012-02-28 at 10:20 +, Dave Martin wrote:
> On Mon, Feb 27, 2012 at 07:33:39PM +, Ian Campbell wrote:
> > On Mon, 2012-02-27 at 18:03 +, Dave Martin wrote:
> > > > Since we support only ARMv7+ there are "T2" and "T3" encodings available
> > > > which do allow direct mov of an im
On 27.02.2012, at 20:28, Scott Wood wrote:
> On 02/24/2012 08:26 AM, Alexander Graf wrote:
>> -void kvmppc_core_prepare_to_enter(struct kvm_vcpu *vcpu)
>> +int kvmppc_core_prepare_to_enter(struct kvm_vcpu *vcpu)
>> {
>> unsigned long *pending = &vcpu->arch.pending_exceptions;
>> unsigne
On (Tue) 28 Feb 2012 [12:00:34], Avi Kivity wrote:
> On 02/24/2012 08:58 PM, Andy Lutomirski wrote:
> > On Thu, Feb 23, 2012 at 8:34 PM, H. Peter Anvin wrote:
> > > On 02/16/2012 09:39 AM, Avi Kivity wrote:
> > >>>
> > >>> Yes, this is on purpose
> > >
> > > Why?
> >
> > I think the "this" refers
On 02/21/2012 11:41 PM, Linus Torvalds wrote:
> Btw, I really don't like what arch/x86/kvm/ does with CR0.TS and the FP
> state. I'm not at all sure that's all kosher. But I don't know the
> code, so I just made sure that at no point did any of the semantics
> change.
>
Can you elaborate on wha
On 02/27/2012 05:01 AM, Wen Congyang wrote:
> We can know the guest is paniced when the guest runs on xen.
> But we do not have such feature on kvm. This patch implemnts
> this feature, and the implementation is the same as xen:
> register panic notifier, and call hypercall when the guest
> is pani
On 24.02.2012 08:23, Stefan Hajnoczi wrote:
On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi wrote:
On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi wrote:
On Thu, Feb 23, 2012 at 7:08 PM, peter.lie...@gmail.com wrote:
Stefan Hajnoczi schrieb:
On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieve
On 02/23/2012 01:35 PM, Takuya Yoshikawa wrote:
> We have seen some problems of the current implementation of
> get_dirty_log() which uses synchronize_srcu_expedited() for updating
> dirty bitmaps; e.g. it is noticeable that this sometimes gives us ms
> order of latency when we use VGA displays.
>
On 28.02.2012 09:37, Corentin Chary wrote:
On Mon, Feb 13, 2012 at 10:24 AM, Peter Lieven wrote:
Am 11.02.2012 um 09:55 schrieb Corentin Chary:
On Thu, Feb 9, 2012 at 7:08 PM, Peter Lieven wrote:
Hi,
is anyone aware if there are still problems when enabling the threaded vnc
server?
I saw s
Hello everybody,
I don't know if someone has already seen my request…
I got crashes on my KVM hosts. They are in a 6 nodes cluster of Proxmox VE
(1.9), the VM disks are LV through AoE and i use Coraid SAN storage (all the
device inside guests are Virtio - /dev/vdX, network).
For one of them (N
On Tue, Feb 28, 2012 at 11:46 AM, Peter Lieven wrote:
> On 24.02.2012 08:23, Stefan Hajnoczi wrote:
>>
>> On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi
>> wrote:
>>>
>>> On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi
>>> wrote:
On Thu, Feb 23, 2012 at 7:08 PM, peter.lie...@gmail.c
On Tue, Feb 28, 2012 at 11:50 AM, Germain Maurice
wrote:
> I don't know if someone has already seen my request…
If you're not getting responses it could be because you are using
Proxmox VE, so the kernel and qemu-kvm might have patches. Have you
asked the Proxmox community/company for support?
On Tue, 28 Feb 2012, Dave Martin wrote:
> > Given that Stefano is proposing to make the ISS a (per-hypervisor)
> > constant we could consider just defining the Thumb and non-Thumb
> > constants instead of doing all the construction with the __HVC_IMM stuff
> > -- that would remove a big bit of the
On 28.02.2012 13:05, Stefan Hajnoczi wrote:
On Tue, Feb 28, 2012 at 11:46 AM, Peter Lieven wrote:
On 24.02.2012 08:23, Stefan Hajnoczi wrote:
On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi
wrote:
On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi
wrote:
On Thu, Feb 23, 2012 at 7:08 PM, p
On Tue, 28 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-28 at 10:20 +, Dave Martin wrote:
> > On Mon, Feb 27, 2012 at 07:33:39PM +, Ian Campbell wrote:
> > > On Mon, 2012-02-27 at 18:03 +, Dave Martin wrote:
> > > > > Since we support only ARMv7+ there are "T2" and "T3" encodings
>
On 02/27/2012 03:07 PM, Nadav Har'El wrote:
> This is a tiny, but important, patch to vhost.
>
> Vhost's worker thread only called schedule() when it had no work to do, and
> it wanted to go to sleep. But if there's always work to do, e.g., the guest
> is running a network-intensive program like ne
https://bugzilla.kernel.org/show_bug.cgi?id=42829
Steve changed:
What|Removed |Added
CC||ru...@rustcorp.com.au
Kernel Version|3.3.0-r
On 02/23/2012 06:42 PM, Stefan Hajnoczi wrote:
> On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven wrote:
> > However, in a virtual machine I have not observed the above slow down to
> > that extend
> > while the benefit of zero after free in a virtualisation environment is
> > obvious:
> >
> > 1) zer
On 02/24/2012 08:41 AM, Stefan Hajnoczi wrote:
> >
> > I dont think that it is cpu intense. All user pages are zeroed anyway, but
> > at allocation time it shouldnt be a big difference in terms of cpu power.
>
> It's easy to find a scenario where eagerly zeroing pages is wasteful.
> Imagine a proc
PCI 2.3 allows to generically disable IRQ sources at device level. This
enables us to share legacy IRQs of such devices with other host devices
when passing them to a guest.
The new IRQ sharing feature introduced here is optional, user space has
to request it explicitly. Moreover, user space can i
On 28.02.2012 14:16, Avi Kivity wrote:
On 02/24/2012 08:41 AM, Stefan Hajnoczi wrote:
I dont think that it is cpu intense. All user pages are zeroed anyway, but at
allocation time it shouldnt be a big difference in terms of cpu power.
It's easy to find a scenario where eagerly zeroing pages is
You are using old kernels on our Proxmox VE 1.9 - upgrade to latest stable, see
http://forum.proxmox.com/threads/8399-New-2-6-32-Kernel-for-Proxmox-VE-1-9-stable
If you still got issues, post in our Proxmox forum.
Martin
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-
https://bugzilla.kernel.org/show_bug.cgi?id=42829
--- Comment #1 from Steve 2012-02-28 13:49:24 ---
Also this sites described similar problems:
https://bugzilla.redhat.com/show_bug.cgi?id=520119
http://www.mail-archive.com/scientific-linux-users@
listserv.fnal.gov/msg10661.html
Let me kno
On 02/28/2012 03:20 PM, Peter Lieven wrote:
> On 28.02.2012 14:16, Avi Kivity wrote:
>> On 02/24/2012 08:41 AM, Stefan Hajnoczi wrote:
I dont think that it is cpu intense. All user pages are zeroed
anyway, but at allocation time it shouldnt be a big difference in
terms of cpu power.
On Tue, Feb 28, 2012, Avi Kivity wrote about "Re: [PATCH] vhost: don't forget
to schedule()":
> > + if (need_resched())
> > + schedule();
>
> This is cond_resched(), no?
It indeed looks similar, but it appears there are some slightly
different things h
On 02/28/2012 04:00 PM, Nadav Har'El wrote:
> On Tue, Feb 28, 2012, Avi Kivity wrote about "Re: [PATCH] vhost: don't forget
> to schedule()":
> > > + if (need_resched())
> > > + schedule();
> >
> > This is cond_resched(), no?
>
> It indeed looks similar, bu
VMStateDescription vmstate_pit = {
.name = "i8254",
.version_id = 3,
.minimum_version_id = 2,
.minimum_version_id_old = 1,
.load_state_old = pit_load_old,
.fields = (VMStateField []) {
<<< HEAD
VMSTATE_UINT32(flags, PITState),
||| merged common ancestor
On Mon, Feb 27, 2012 at 10:06 PM, Anthony Liguori wrote:
> On 02/27/2012 03:58 PM, Paolo Bonzini wrote:
>>
>> Il 27/02/2012 18:21, Eric Blake ha scritto:
>
> Please send in any agenda items you are interested in covering.
>>>
>>> Given all the threads on snapshot/mirror/migrate/reopen in t
On 2012-02-28 15:32, Avi Kivity wrote:
>
> VMStateDescription vmstate_pit = {
> .name = "i8254",
> .version_id = 3,
> .minimum_version_id = 2,
> .minimum_version_id_old = 1,
> .load_state_old = pit_load_old,
> .fields = (VMStateField []) {
> <<< HEAD
> VMST
On 02/28/2012 04:40 PM, Jan Kiszka wrote:
> On 2012-02-28 15:32, Avi Kivity wrote:
> >
> > VMStateDescription vmstate_pit = {
> > .name = "i8254",
> > .version_id = 3,
> > .minimum_version_id = 2,
> > .minimum_version_id_old = 1,
> > .load_state_old = pit_load_old,
> > .fie
Il 28/02/2012 15:39, Stefan Hajnoczi ha scritto:
> I'm not a fan of transactions or freeze/thaw (if used to atomically
> perform other commands).
>
> We should not export low-level block device operations so that
> external software can micromanage via QMP. I don't think this is a
> good idea bec
On Tue, Feb 28, 2012 at 2:47 PM, Paolo Bonzini wrote:
> Il 28/02/2012 15:39, Stefan Hajnoczi ha scritto:
>> I'm not a fan of transactions or freeze/thaw (if used to atomically
>> perform other commands).
>>
>> We should not export low-level block device operations so that
>> external software can
It turned out that a performance counter on AMD does not
count at all when the GO or HO bit is set in the control
register and SVM is disabled in EFER.
This patch works around this issue by masking out the HO bit
in the performance counter control register when SVM is not
enabled.
The GO bit is n
On Tue, Feb 28, 2012 at 3:21 AM, Avi Kivity wrote:
>
> Can you elaborate on what you don't like in the kvm code (apart from "it
> does virtualiztion")?
It doesn't fit any of the patterns of the x87 save/restore code, and I
don't know what it does.
It does clts on its own, in random places withou
On 02/28/2012 07:58 AM, Stefan Hajnoczi wrote:
> On Tue, Feb 28, 2012 at 2:47 PM, Paolo Bonzini wrote:
>> Il 28/02/2012 15:39, Stefan Hajnoczi ha scritto:
>>> I'm not a fan of transactions or freeze/thaw (if used to atomically
>>> perform other commands).
>>>
>>> We should not export low-level blo
Il 28/02/2012 17:07, Eric Blake ha scritto:
> { 'enum': 'BlockdevOp',
> 'data': [ 'snapshot', 'snapshot-mirror', 'reopen' ] }
> { 'type': 'BlockdevAction',
> 'data': {'device': 'str', 'op': 'BlockdevOp',
>'file': 'str', '*format': 'str', '*reuse': 'bool',
>'*mirror': 'st
Hi,
I could reproduce it and I bisected it down to this commit.
12d4536f7d911b6d87a766ad7300482ea663cea2 is the first bad commit
commit 12d4536f7d911b6d87a766ad7300482ea663cea2
Author: Anthony Liguori
Date: Mon Aug 22 08:24:58 2011 -0500
-martin
On 22.02.2012 20:53, Stefan Hajnoczi wrote:
On Tue, Feb 28, 2012 at 4:39 PM, Martin Mailand wrote:
> I could reproduce it and I bisected it down to this commit.
>
> 12d4536f7d911b6d87a766ad7300482ea663cea2 is the first bad commit
> commit 12d4536f7d911b6d87a766ad7300482ea663cea2
> Author: Anthony Liguori
> Date: Mon Aug 22 08:24:58 2011
Hi Stefan,
I was bisecting qemu-kvm.git.
git remote show origin
* remote origin
Fetch URL: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
Push URL: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
The bisect log is:
git bisect start
# good: [b8095f24f24e50a7d4be33d8a79474aff3324295]
On 02/28/2012 05:03 AM, Alexander Graf wrote:
>
> On 27.02.2012, at 20:28, Scott Wood wrote:
>
>> If there is a signal pending and MSR[WE] is set, we'll loop forever
>> without reaching this check.
>
> Good point. How about something like this on top (will fold in later)?
>
> diff --git a/arch/
On 02/28/2012 06:05 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2012 at 3:21 AM, Avi Kivity wrote:
> >
> > Can you elaborate on what you don't like in the kvm code (apart from "it
> > does virtualiztion")?
>
> It doesn't fit any of the patterns of the x87 save/restore code, and I
> don't know what
On 02/28/2012 05:55 PM, Joerg Roedel wrote:
>
> __init int amd_pmu_init(void)
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 5fa553b..773fee2 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -29,6 +29,7 @@
> #include
> #include
>
> +#include
> #include
>
https://bugzilla.kernel.org/show_bug.cgi?id=42812
Jan Kiszka changed:
What|Removed |Added
CC||jan.kis...@web.de
--- Comment #1 from Ja
On Tue Feb 28, 2012, you wrote:
> On 2012-02-19 21:13, Thomas Fjellstrom wrote:
> > I'm pretty much stumped on this. So I decided to try re-creating the vm
> > through virt-manager. Its up and running now. The only to major
> > differences I can see in the old and new config is the machine (-M
> >
On 2/28/12 10:24 AM, Avi Kivity wrote:
On 02/28/2012 05:55 PM, Joerg Roedel wrote:
__init int amd_pmu_init(void)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 5fa553b..773fee2 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -29,6 +29,7 @@
#include
#include
+#incl
On Tue, Feb 28, 2012 at 9:21 AM, Avi Kivity wrote:
>
> What you described is the slow path.
Indeed. I'd even call it the "glacial and stupid" path.
>The fast path is
>
> void kvm_load_guest_fpu(struct kvm_vcpu *vcpu)
> {
> if (vcpu->guest_fpu_loaded)
> return;
>
> If we're emulat
On 02/28/2012 07:36 PM, David Ahern wrote:
> On 2/28/12 10:24 AM, Avi Kivity wrote:
>> On 02/28/2012 05:55 PM, Joerg Roedel wrote:
>>>
>>> __init int amd_pmu_init(void)
>>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>>> index 5fa553b..773fee2 100644
>>> --- a/arch/x86/kvm/svm.c
>>> +++
On Tue, Feb 28, 2012 at 9:37 AM, Linus Torvalds
wrote:
>
> So where's the comment about why you actually own and control CR0.TS,
> and nobody else does?
So what I think KVM should strive for (but I really don't know the
code, so maybe there are good reasons why it is impossible) is to just
never
On 02/28/2012 07:37 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2012 at 9:21 AM, Avi Kivity wrote:
> >
> > What you described is the slow path.
>
> Indeed. I'd even call it the "glacial and stupid" path.
Right. It won't be offended, since it's almost never called.
> >The fast path is
> >
> > v
On 02/28/2012 08:08 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2012 at 9:37 AM, Linus Torvalds
> wrote:
> >
> > So where's the comment about why you actually own and control CR0.TS,
> > and nobody else does?
>
> So what I think KVM should strive for (but I really don't know the
> code, so maybe t
On Tue, Feb 28, 2012 at 10:09 AM, Avi Kivity wrote:
>
> This is done by preempt notifiers. Whenever a task switch happens we
> push the guest fpu state into memory (if loaded) and let the normal
> stuff happen. So the if we had a task switch during instruction
> emulation, for example, then we'd
On 02/28/2012 08:34 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2012 at 10:09 AM, Avi Kivity wrote:
> >
> > This is done by preempt notifiers. Whenever a task switch happens we
> > push the guest fpu state into memory (if loaded) and let the normal
> > stuff happen. So the if we had a task switc
On 02/27/2012 03:42 PM, Lukas Doktor wrote:
Hi,
This is a complete rework of cgroup test from subtests to singe-test-execution.
It improves stability of testing and allows better test customisation. The
speed is similar/faster in single variant execution and a bit slower in
all-variants execu
On Tue, Feb 28, 2012 at 11:06 AM, Avi Kivity wrote:
>
> No, the scheduler saves the state into task_struct. I need it saved
> into the vcpu structure. We have two fpu states, the user state, and
> the guest state. APIs that take a task_struct as a parameter, or
> reference current implicitly, a
On 02/28/2012 09:26 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2012 at 11:06 AM, Avi Kivity wrote:
> >
> > No, the scheduler saves the state into task_struct. I need it saved
> > into the vcpu structure. We have two fpu states, the user state, and
> > the guest state. APIs that take a task_str
On 02/28/2012 04:42 PM, Avi Kivity wrote:
I'm getting a crash now:
#0 0x74ea0285 in raise() from /lib64/libc.so.6
#1 0x74ea1b9b in abort() from /lib64/libc.so.6
#2 0x74e98e9e in __assert_fail_base ()from /lib64/libc.so.6
#3 0x74e98f42 in __assert_
On 2012-02-28 20:50, Avi Kivity wrote:
> On 02/28/2012 04:42 PM, Avi Kivity wrote:
>
>
>
> I'm getting a crash now:
>
> #0 0x74ea0285 in raise() from /lib64/libc.so.6
> #1 0x74ea1b9b in abort() from /lib64/libc.so.6
> #2 0x74e98e9e in __assert_fail_base ()
From: Scott Wood
We'll use it on e500mc as well.
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_book3s.h |3 ++
arch/powerpc/include/asm/kvm_booke.h |3 ++
arch/powerpc/include/asm/kvm_ppc.h|5
arch/powerpc/kvm/book3s_64_mmu_hv.c
From: Scott Wood
Rather than invalidate everything when a TLB1 entry needs to be
taken down, keep track of which host TLB1 entries are used for
a given guest TLB1 entry, and invalidate just those entries.
Based on code from Ashish Kalra
and Liu Yu .
Signed-off-by: Scott Wood
Signed-off-by: Al
If we hit any exception whatsoever in the restore path and r1/r2 aren't the
host registers, we don't get a working oops. So it's always a good idea to
restore them as early as possible.
This time, it actually has practical reasons to do so too, since we need to
have the host page fault handler fix
We can't run e500v2 kvm on e500mc kernels, so indicate that by
making the 2 options mutually exclusive in kconfig.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kcon
When we fail to emulate an instruction for the guest, we better go in and
tell it that we failed to emulate it, by throwing an illegal instruction
exception.
Please beware that we basically never get around to telling the guest that
we failed thanks to the debugging code right above it. If user sp
There's always a chance we're unable to read a guest instruction. The guest
could have its TLB mapped execute-, but not readable, something odd happens
and our TLB gets flushed. So it's a good idea to be prepared for that case
and have a fallback that allows us to fix things up in that case.
Add f
The e500mc patches left some debug code in that we don't need. Remove it.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 9fcc760..17d5318 100644
---
From: Scott Wood
e500mc has a normal PPC FPU, rather than SPE which is found
on e500v1/v2.
Based on code from Liu Yu .
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/system.h |1 +
arch/powerpc/kvm/booke.c | 44
So far, we've always called prepare_to_enter even when all we did was return
to the host. This patch changes that semantic to only call prepare_to_enter
when we actually want to get back into the guest.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c | 18 ++
1 files
When we get a performance monitor interrupt, we need to make sure that
the host receives it. So reinject it like we reinject the other host
destined interrupts.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- call regs sync directly
---
arch/powerpc/include/asm/hw_irq.h |1 +
arch/powerpc
The tlbncfg registers should be populated with their respective TLB's
values. Fix the obvious typo.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/e500_tlb.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
When during guest context we get a performance monitor interrupt, we
currently bail out and oops. Let's route it to its correct handler
instead.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm
When reinjecting an interrupt into the host interrupt handler after we're
back in host kernel land, we need to tell the kernel where the interrupt
happened. We can't tell it that we were in guest state, because that might
lead to random code walking host addresses. So instead, we tell it that
we ca
For BookE HV the guest visible MSR is shared->msr and is identical to
the MSR that is in use while the guest is running, because we can't trap
reads from/to MSR.
So shadow_msr is unused there. Indicate that with a comment.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_host.h |
There was some unused code in the exit code path that must have been
a leftover from earlier iterations. While it did no harm, it's superfluous
and thus should be removed.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- fix commit message
- also remove "lwzr9, VCPU_KVM(r4)" which was as
When during guest execution we get a machine check interrupt, we don't
know how to handle it yet. So let's add the error printing code back
again that we dropped accidently earlier and tell user space that something
went really wrong.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c |
From: Scott Wood
Split e500 (v1/v2) and e500mc/e5500 to allow optimization of feature
checks that differ between the two.
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/cputable.h | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff
The comment for program interrupts triggered when using bookehv was
misleading. Update it to mention why MSR_GS indicates that we have
to inject an interrupt into the guest again, not emulate it.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c | 10 --
1 files changed, 8 ins
We need to make sure that no MAS updates happen automatically while we
have the guest MAS registers loaded. So move the disabling code a bit
higher up so that it covers the full time we have guest values in MAS
registers.
The race this patch fixes should never occur, but it makes the code a
bit mo
From: Scott Wood
Chips such as e500mc that implement category E.HV in Power ISA 2.06
provide hardware virtualization features, including a new MSR mode for
guest state. The guest OS can perform many operations without trapping
into the hypervisor, including transitions to and from guest userspac
From: Scott Wood
Add processor support for e500mc, using hardware virtualization support
(GS-mode).
Current issues include:
- No support for external proxy (coreint) interrupt mode in the guest.
Includes work by Ashish Kalra ,
Varun Sethi , and
Liu Yu .
Signed-off-by: Scott Wood
Signed-off-b
Instead if doing
#ifndef CONFIG_64BIT
...
#else
...
#endif
we should rather do
#ifdef CONFIG_64BIT
...
#else
...
#endif
which is a lot easier to read. Change the bookehv implementation to
stick with this rule.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/bookehv_int
The SET_VCPU macro is a leftover from times when the vcpu struct wasn't
stored in the thread on vcpu_load/put. It's not needed anymore. Remove it.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/bookehv_interrupts.S |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git
The CONFIG_KVM_E500 option really indicates that we're running on a V2 machine,
not on a machine of the generic E500 class. So indicate that properly and
change the config name accordingly.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/Kconfig|8
arch/powerpc/kvm/Makefile
When using exit timing stats, we clobber r9 in the NEED_EMU case,
so better move that part down a few lines and fix it that way.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/bookehv_interrupts.S |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kv
The semantics of BOOKE_IRQPRIO_MAX changed to denote the highest available
irqprio + 1, so let's reflect that in the code too.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powe
When one vcpu wants to kick another, it can issue a special IPI instruction
called msgsnd. This patch emulates this instruction, its clearing counterpart
and the infrastructure required to actually trigger that interrupt inside
a guest vcpu.
With this patch, SMP guests on e500mc work.
Signed-off-
Instead of checking whether we should reschedule only when we exited
due to an interrupt, let's always check before entering the guest back
again. This gets the target more in line with the other archs.
Also while at it, generalize the whole thing so that eventually we could
have a single kvmppc_p
From: Scott Wood
DO_KVM will need to identify the particular exception type.
There is an existing set of arbitrary numbers that Linux passes,
but it's an undocumented mess that sort of corresponds to server/classic
exception vectors but not really.
Signed-off-by: Scott Wood
Signed-off-by: Alex
1 - 100 of 120 matches
Mail list logo
