This patch replaces the empty AMD vPMU functions (in pmu_amd.c) with real
implementation.
Signed-off-by: Wei Huang
---
arch/x86/kvm/pmu_amd.c | 122 ++---
1 file changed, 116 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/pmu_amd.c b/arch/x86
This patch splits existing vPMU code into a common vPMU interface (pmc.c)
and Intel specific vPMU code (pmu_intel.c) using the following steps:
- Part of arechitectural vPMU code is extracted and moved to pmu_intel.c
file. They are hooked up with the newly-defined intel_pmu_ops, which will
be
This patch enables AMD guest VM to access (R/W) PMU related MSRs, which
include PERFCTR[0..3] and EVNTSEL[0..3].
Signed-off-by: Wei Huang
---
arch/x86/kvm/x86.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/
This patch defines a new function pointer struct (kvm_pmu_ops) to
support vPMU for both Intel and AMD. The functions pointers defined in
this new struct will be linked with Intel and AMD functions later. In the
meanwhile the struct that maps from event_sel bits to PERF_TYPE_HARDWARE
events is renam
Currently KVM only supports vPMU for Intel CPUs. This patchset enables
KVM vPMU support for AMD platform by creating a common PMU interface for
x86. By refractoring, PMU related MSR accesses from guest VMs are dispatched
to corresponding functions defined in arch specific files.
V3:
* Rebase the
From: Radim Krčmář
As noted by Andy Lutomirski, kvm does not follow the documented version
protocol. Fix it.
Note: this bug results in a race which can occur if the following three
conditions are met:
1) There is KVM guest time update (there is one every 5 minutes).
2) Which races with a thre
On Fri, Apr 17, 2015 at 05:04:29PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 17, 2015 at 4:38 PM, Marcelo Tosatti wrote:
> >
> > From: Radim Krčmář
> >
> > As noted by Andy Lutomirski, kvm does not follow the documented version
> > protocol. Fix it.
> >
> > Note: this bug results in a race whic
On Fri, Apr 17, 2015 at 05:04:29PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 17, 2015 at 4:38 PM, Marcelo Tosatti wrote:
> >
> > From: Radim Krčmář
> >
> > As noted by Andy Lutomirski, kvm does not follow the documented version
> > protocol. Fix it.
> >
> > Note: this bug results in a race whic
On Fri, Apr 17, 2015 at 4:38 PM, Marcelo Tosatti wrote:
>
> From: Radim Krčmář
>
> As noted by Andy Lutomirski, kvm does not follow the documented version
> protocol. Fix it.
>
> Note: this bug results in a race which can occur if the following three
> conditions are met:
>
> 1) There is KVM gues
On Fri, Apr 17, 2015 at 03:25:28PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 17, 2015 at 3:04 PM, Linus Torvalds
> wrote:
> > On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski
> > wrote:
> >>
> >> Muahaha. The auditors have invaded your system. (I did my little
> >> benchmark with a more sens
From: Radim Krčmář
As noted by Andy Lutomirski, kvm does not follow the documented version
protocol. Fix it.
Note: this bug results in a race which can occur if the following three
conditions are met:
1) There is KVM guest time update (there is one every 5 minutes).
2) Which races with a thre
On Fri, Apr 17, 2015 at 3:04 PM, Linus Torvalds
wrote:
> On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski wrote:
>>
>> Muahaha. The auditors have invaded your system. (I did my little
>> benchmark with a more sensible configuration -- see way below).
>>
>> Can you send the output of:
>>
>> # au
On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski wrote:
>
> Muahaha. The auditors have invaded your system. (I did my little
> benchmark with a more sensible configuration -- see way below).
>
> Can you send the output of:
>
> # auditctl -s
> # auditctl -l
# auditctl -s
enabled 1
flag 1
On Fri, Apr 17, 2015 at 2:28 PM, Linus Torvalds
wrote:
> On Fri, Apr 17, 2015 at 4:39 PM, Andy Lutomirski wrote:
>>
>> On my box, vclock_gettime using kvm-clock is about 40 ns. An empty
>> syscall is about 33 ns. clock_gettime *should* be around 17 ns.
>>
>> The clock_gettime syscall is about 7
On Fri, Apr 17, 2015 at 4:39 PM, Andy Lutomirski wrote:
>
> On my box, vclock_gettime using kvm-clock is about 40 ns. An empty
> syscall is about 33 ns. clock_gettime *should* be around 17 ns.
>
> The clock_gettime syscall is about 73 ns.
>
> Could we figure out why clock_gettime (the syscall) i
On Fri, Apr 17, 2015 at 1:18 PM, Marcelo Tosatti wrote:
> On Fri, Apr 17, 2015 at 09:57:12PM +0200, Paolo Bonzini wrote:
>>
>>
>> >> From 4eb9d7132e1990c0586f28af3103675416d38974 Mon Sep 17 00:00:00 2001
>> >> From: Paolo Bonzini
>> >> Date: Fri, 17 Apr 2015 14:57:34 +0200
>> >> Subject: [PATCH]
2015-04-17 19:12+0200, Jan Kiszka:
> On 2015-04-17 18:43, Radim Krčmář wrote:
> > 2015-04-13 07:16+0200, Jan Kiszka:
> >> PS: If someone has a good idea for a simple test case on machines
> >> without IOMMU (like my current boxes), thus without a chance to use
> >> device pass-through to stress gue
On Fri, Apr 17, 2015 at 09:57:12PM +0200, Paolo Bonzini wrote:
>
>
> >> From 4eb9d7132e1990c0586f28af3103675416d38974 Mon Sep 17 00:00:00 2001
> >> From: Paolo Bonzini
> >> Date: Fri, 17 Apr 2015 14:57:34 +0200
> >> Subject: [PATCH] sched: add CONFIG_TASK_MIGRATION_NOTIFIER
> >>
> >> The task mi
>> From 4eb9d7132e1990c0586f28af3103675416d38974 Mon Sep 17 00:00:00 2001
>> From: Paolo Bonzini
>> Date: Fri, 17 Apr 2015 14:57:34 +0200
>> Subject: [PATCH] sched: add CONFIG_TASK_MIGRATION_NOTIFIER
>>
>> The task migration notifier is only used in x86 paravirt. Make it
>> possible to compile
On Fri, Apr 17, 2015 at 12:01 PM, Marcelo Tosatti wrote:
> On Fri, Apr 17, 2015 at 03:38:58PM +0200, Paolo Bonzini wrote:
>> On 17/04/2015 15:10, Peter Zijlstra wrote:
>> > On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote:
>> >> On 17/04/2015 12:55, Peter Zijlstra wrote:
>> >>> Also,
On Fri, Apr 17, 2015 at 03:38:58PM +0200, Paolo Bonzini wrote:
> On 17/04/2015 15:10, Peter Zijlstra wrote:
> > On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote:
> >> On 17/04/2015 12:55, Peter Zijlstra wrote:
> >>> Also, it looks like you already do exactly this for other things, look
On 2015-04-17 18:43, Radim Krčmář wrote:
> 2015-04-13 07:16+0200, Jan Kiszka:
>> PS: If someone has a good idea for a simple test case on machines
>> without IOMMU (like my current boxes), thus without a chance to use
>> device pass-through to stress guest PAT settings, I would be all ears.
>
> No
2015-04-13 08:58+0200, Jan Kiszka:
> When hardware supports the g_pat VMCB field, we can use it for emulating
> the PAT configuration that the guest configures by writing to the
> corresponding MSR.
>
> Signed-off-by: Jan Kiszka
> ---
Reviewed-by: Radim Krčmář
--
To unsubscribe from this list:
2015-04-13 07:16+0200, Jan Kiszka:
> Hi all,
>
> while digging into the PAT topic for Jailhouse, I also wondered how KVM
> deals with it. And I'm still not getting it complete - or there is a bug:
>
> KVM intercepts all guest writes to the PAT MSR and instead keeps the
> guest value in vcpu->arch
Thanks, Paolo, for the document reference and the fixup.
Greg: Sorry for the standard newbie gaffs.
On Fri, Apr 17, 2015 at 3:16 AM, Paolo Bonzini wrote:
>
>
> On 17/04/2015 07:10, Wanpeng Li wrote:
>>> >
>>> >Before the change, if guest CR4.MCE==0, then the machine check is
>>> >escalated to Ca
Hi Alex,
On 04/17/2015 04:29 PM, Alex Williamson wrote:
> On Fri, 2015-04-17 at 15:37 +0200, Eric Auger wrote:
>> This patch introduces a specialized vfio platform driver for the
>> calxeda xgmac. On top of the generic vfio platform driver functionalities,
>> it implements the reset modality. This
On 17/04/2015 15:43, Peter Zijlstra wrote:
> On Fri, Apr 17, 2015 at 03:38:58PM +0200, Paolo Bonzini wrote:
>>> The path this notifier is called from has nothing to do with those
>>> costs.
>
> Its attributed to the entity doing the migration, which can be the
> wakeup path or a softirq. And we v
On Fri, 2015-04-17 at 15:37 +0200, Eric Auger wrote:
> We intend to derive the platform driver into specialized ones, featuring
> reset modality. In order to avoid duplication, let's export the functions
> that can be reused in all vfio_platform drivers:
> - get_platform_resource
> - get_platform_i
On Fri, 2015-04-17 at 15:37 +0200, Eric Auger wrote:
> This patch introduces a specialized vfio platform driver for the
> calxeda xgmac. On top of the generic vfio platform driver functionalities,
> it implements the reset modality. This latter basically disables interrupts
> and stops DMA transfe
On Fri, 2015-04-17 at 15:37 +0200, Eric Auger wrote:
> This patch adds support for vfio platform reset. The modality only is
> exposed when a specialized VFIO driver populates the reset callback.
> For the generic vfio platform/amba driver, the modality is not supported
> since the driver is by ess
In situations where the userspace driver is stopped abnormally and the
VFIO platform device is released, the assigned HW device currently is
left running. As a consequence the HW device might continue issuing IRQs
and performing DMA accesses.
On release, no physical IRQ handler is setup anymore. A
This patch adds support for vfio platform reset. The modality only is
exposed when a specialized VFIO driver populates the reset callback.
For the generic vfio platform/amba driver, the modality is not supported
since the driver is by essence a metadriver and does not know how to
reset the underlyi
We intend to derive the platform driver into specialized ones, featuring
reset modality. In order to avoid duplication, let's export the functions
that can be reused in all vfio_platform drivers:
- get_platform_resource
- get_platform_irq
- vfio_platform_probe
- vfio_platform_remove
Practically, o
On Fri, Apr 17, 2015 at 03:38:58PM +0200, Paolo Bonzini wrote:
> > The path this notifier is called from has nothing to do with those
> > costs.
>
> How not? The task is going to incur those costs, it's not like half
> a dozen extra instruction make any difference. But anyway...
Its attributed
This patch introduces a specialized vfio platform driver for the
calxeda xgmac. On top of the generic vfio platform driver functionalities,
it implements the reset modality. This latter basically disables interrupts
and stops DMA transfers.
Code is inherited from calxeda xgmac native driver
Sign
On 17/04/2015 15:10, Peter Zijlstra wrote:
> On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote:
>> On 17/04/2015 12:55, Peter Zijlstra wrote:
>>> Also, it looks like you already do exactly this for other things, look
>>> at:
>>>
>>> kvm_sched_in()
>>> kvm_arch_vcpu_load()
>>>
On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote:
> On 17/04/2015 12:55, Peter Zijlstra wrote:
> > Also, it looks like you already do exactly this for other things, look
> > at:
> >
> > kvm_sched_in()
> > kvm_arch_vcpu_load()
> > if (unlikely(vcpu->cpu != cpu) ... )
On 17/04/2015 12:55, Peter Zijlstra wrote:
> Also, it looks like you already do exactly this for other things, look
> at:
>
> kvm_sched_in()
> kvm_arch_vcpu_load()
> if (unlikely(vcpu->cpu != cpu) ... )
>
> So no, I don't believe for one second you need this.
You're mis
On Fri, Apr 17, 2015 at 12:38:07PM +0200, Paolo Bonzini wrote:
>
>
> On 17/04/2015 12:36, Peter Zijlstra wrote:
> > Now you make everybody pay for your crap, x86-64 paravirt or not. Keep
> > the cost by those who need it.
> >
> > Please take it out, ASAP.
>
> I'll just implement the static key.
On 17/04/2015 12:36, Peter Zijlstra wrote:
> Now you make everybody pay for your crap, x86-64 paravirt or not. Keep
> the cost by those who need it.
>
> Please take it out, ASAP.
I'll just implement the static key.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the
On Fri, Apr 17, 2015 at 12:09:49PM +0200, Paolo Bonzini wrote:
>
>
> On 17/04/2015 11:17, Peter Zijlstra wrote:
> > On Fri, Apr 17, 2015 at 10:52:38AM +0200, Peter Zijlstra wrote:
> >> On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote:
> >>> include/linux/sched.h
On 17/04/2015 07:10, Wanpeng Li wrote:
>> >
>> >Before the change, if guest CR4.MCE==0, then the machine check is
>> >escalated to Catastrophic Error (CATERR) and the machine dies.
> Could you point out which section of SDM describes that the machine check
> is escalated to a CATERR if CR4.MCE==
On 17/04/2015 10:55, Greg KH wrote:
> On Thu, Apr 16, 2015 at 11:58:05AM -0700, Ben Serebrin wrote:
>> > The host's decision to enable machine check exceptions should remain
>> > in force during non-root mode. KVM was writing 0 to cr4 on VCPU reset
>> > and passed a slightly-modified 0 to the vm
On 17/04/2015 11:17, Peter Zijlstra wrote:
> On Fri, Apr 17, 2015 at 10:52:38AM +0200, Peter Zijlstra wrote:
>> On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote:
>>> include/linux/sched.h |8 +
>>> kernel/sched/core.c|
On Fri, Apr 17, 2015 at 10:52:38AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote:
> > include/linux/sched.h |8 +
> > kernel/sched/core.c| 15 +
>
> Can you please not puke over the sc
On Fri, 10 Apr 2015 12:15:00 +0200
Greg Kurz wrote:
> Hi,
>
> This patchset allows vhost to be used with legacy virtio when guest and host
> have a different endianness.
>
> Patch 7 got rewritten according to Cornelia's and Michael's comments. I have
> also introduced patch 8 that brings BE vne
On Thu, Apr 16, 2015 at 11:58:05AM -0700, Ben Serebrin wrote:
> The host's decision to enable machine check exceptions should remain
> in force during non-root mode. KVM was writing 0 to cr4 on VCPU reset
> and passed a slightly-modified 0 to the vmcs.guest_cr4 value.
>
> Tested: Built.
> On earl
On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote:
> include/linux/sched.h |8 +
> kernel/sched/core.c| 15 +
Can you please not puke over the scheduler without Acks from at least
one maintainer?
I complained about thi
This reverts commit ea5d404655ba ("vhost: fix release path lockdep checks")
In commit 47283bef7ed3 ("vhost: move memory pointer to VQs"), RCU
operations have been replaced by mutex, we need to remove the no longer
used `locked' parameter by reverting original patch.
Conflicts:
drivers/vho
This reverts commit ea5d404655ba3b356d0c06d6a3c4f24112124522.
In commit 47283bef7ed356629467d1fac61687756e48f254(vhost: move memory
pointer to VQs), rcu_ operation has been replaced by mutex, and original
issue fixed in sea5d404655 has gone as well, we need to remove the
no-longer-used `locked' va
50 matches
Mail list logo
