* Add nested on nested support
Thanks,
-Wei
Wei Huang (4):
KVM: x86: Factor out x86 instruction emulation with decoding
KVM: SVM: Add emulation support for #GP triggered by SVM instructions
KVM: SVM: Add support for SVM instruction address check change
KVM: SVM: Support #GP handling for th
On 1/26/21 5:52 AM, Maxim Levitsky wrote:
On Tue, 2021-01-26 at 03:18 -0500, Wei Huang wrote:
New AMD CPUs have a change that checks #VMEXIT intercept on special SVM
instructions before checking their EAX against reserved memory region.
This change is indicated by CPUID_0x800A_EDX[28
On 1/26/21 5:39 AM, Paolo Bonzini wrote:
On 26/01/21 09:18, Wei Huang wrote:
While running SVM related instructions (VMRUN/VMSAVE/VMLOAD), some AMD
CPUs check EAX against reserved memory regions (e.g. SMM memory on host)
before checking VMCB's instruction intercept. If EAX falls
as #GP is supposed to be triggered.
Co-developed-by: Bandan Das
Signed-off-by: Bandan Das
Signed-off-by: Wei Huang
Reviewed-by: Maxim Levitsky
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kvm/svm/svm.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/x86/include
igned-off-by: Bandan Das
Signed-off-by: Wei Huang
Tested-by: Maxim Levitsky
Reviewed-by: Maxim Levitsky
---
arch/x86/kvm/svm/svm.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index f9233c79265b..83c401d270
under
nested virtualization. To solve this problem, KVM needs to trap #GP and
check the instructions triggering #GP. For VM execution instructions,
KVM emulates these instructions.
Co-developed-by: Wei Huang
Signed-off-by: Wei Huang
Signed-off-by: Bandan Das
---
arch/x86/kvm/svm/svm.c | 109
-by: Wei Huang
---
arch/x86/kvm/x86.c | 62 +-
arch/x86/kvm/x86.h | 2 ++
2 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 9a8969a6dd06..a1c83cd43c1a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch
On 1/21/21 8:07 AM, Maxim Levitsky wrote:
> On Thu, 2021-01-21 at 01:55 -0500, Wei Huang wrote:
>> From: Bandan Das
>>
>> While running SVM related instructions (VMRUN/VMSAVE/VMLOAD), some AMD
>> CPUs check EAX against reserved memory regions (e.g. SMM memory on host
On 1/21/21 8:23 AM, Paolo Bonzini wrote:
> On 21/01/21 15:04, Maxim Levitsky wrote:
>>> +int x86_emulate_decoded_instruction(struct kvm_vcpu *vcpu, int
>>> emulation_type,
>>> + void *insn, int insn_len)
>> Isn't the name of this function wrong? This function decodes the
>>
as #GP is supposed to be triggered.
Co-developed-by: Bandan Das
Signed-off-by: Bandan Das
Signed-off-by: Wei Huang
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kvm/svm/svm.c | 6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm
uest VM's X86_FEATURE_SVME_ADDR_CHK bit for KVM running inside VM to
receive the notification and change behavior.
Co-developed-by: Bandan Das
Signed-off-by: Bandan Das
Signed-off-by: Wei Huang
---
arch/x86/kvm/svm/svm.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --g
under
nested virtualization. To solve this problem, KVM needs to trap #GP and
check the instructions triggering #GP. For VM execution instructions,
KVM emulates these instructions.
Co-developed-by: Wei Huang
Signed-off-by: Wei Huang
Signed-off-by: Bandan Das
---
arch/x86/kvm/svm/svm.c | 99
-by: Wei Huang
---
arch/x86/kvm/x86.c | 63 +-
arch/x86/kvm/x86.h | 2 ++
2 files changed, 42 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 9a8969a6dd06..580883cee493 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch
;v2:
* Factor out instruction decode for sharing
* Re-org gp_interception() handling for both #GP and vmware_backdoor
* Use kvm_cpu_cap for X86_FEATURE_SVME_ADDR_CHK feature support
* Add nested on nested support
Thanks,
-Wei
Wei Huang (4):
KVM: x86: Factor out x86 instruction emulat
On 1/12/21 8:01 AM, Paolo Bonzini wrote:
> On 12/01/21 07:37, Wei Huang wrote:
>> static int gp_interception(struct vcpu_svm *svm)
>> {
>> struct kvm_vcpu *vcpu = >vcpu;
>> u32 error_code = svm->vmcb->control.exit_info_1;
>> -
&g
On 1/12/21 12:58 PM, Andy Lutomirski wrote:
Andrew Cooper points out that there may be a nicer workaround. Make
sure that the SMRAM and HT region (FFFD - ) are
marked as reserved in the guest, too.
In theory this proposed solution can avoid intercepting #GP. But in
On 1/12/21 11:59 AM, Sean Christopherson wrote:
On Tue, Jan 12, 2021, Sean Christopherson wrote:
On Tue, Jan 12, 2021, Wei Huang wrote:
From: Bandan Das
While running VM related instructions (VMRUN/VMSAVE/VMLOAD), some AMD
CPUs check EAX against reserved memory regions (e.g. SMM memory
On 1/12/21 11:56 AM, Sean Christopherson wrote:
On Tue, Jan 12, 2021, Andy Lutomirski wrote:
On Jan 12, 2021, at 7:46 AM, Bandan Das wrote:
Andy Lutomirski writes:
...
#endif diff --git a/arch/x86/kvm/mmu/mmu.c
b/arch/x86/kvm/mmu/mmu.c index 6d16481aa29d..c5c4aaf01a1a 100644
---
On 1/12/21 6:15 AM, Vitaly Kuznetsov wrote:
Wei Huang writes:
From: Bandan Das
While running VM related instructions (VMRUN/VMSAVE/VMLOAD), some AMD
CPUs check EAX against reserved memory regions (e.g. SMM memory on host)
before checking VMCB's instruction intercept. If EAX falls
On 1/12/21 5:09 AM, Maxim Levitsky wrote:
On Tue, 2021-01-12 at 00:37 -0600, Wei Huang wrote:
From: Bandan Das
While running VM related instructions (VMRUN/VMSAVE/VMLOAD), some AMD
CPUs check EAX against reserved memory regions (e.g. SMM memory on host)
before checking VMCB's instruction
isn't supposed to be triggered.
Co-developed-by: Bandan Das
Signed-off-by: Bandan Das
Signed-off-by: Wei Huang
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kvm/svm/svm.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/cpufeatures.h
under
nested virtualization. To solve this problem, KVM needs to trap #GP and
check the instructions triggering #GP. For VM execution instructions,
KVM emulates these instructions; otherwise it re-injects #GP back to
guest VMs.
Signed-off-by: Bandan Das
Co-developed-by: Wei Huang
Signed-off
On 12/21/20 11:09 PM, Gabriel C wrote:
Am Di., 22. Dez. 2020 um 05:33 Uhr schrieb Wei Huang :
On 12/21/20 9:58 PM, Guenter Roeck wrote:
Hi,
On 12/21/20 5:45 PM, Gabriel C wrote:
Hello Guenter,
while trying to add ZEN3 support for zenpower out of tree modules, I find out
the in-kernel
On 12/21/20 9:58 PM, Guenter Roeck wrote:
Hi,
On 12/21/20 5:45 PM, Gabriel C wrote:
Hello Guenter,
while trying to add ZEN3 support for zenpower out of tree modules, I find out
the in-kernel k10temp driver is broken with ZEN3 ( and partially ZEN2 even ).
commit
On 12/7/20 4:30 PM, Borislav Petkov wrote:
> On Mon, Dec 07, 2020 at 04:07:52PM -0600, Wei Huang wrote:
>> I think we shouldn't override zen2 if _PSD is correct. In my opinion,
>> there are two approaches:
>>
>> * Keep override_acpi_psd()
>> Let us keep the ori
On 12/7/20 2:26 PM, Borislav Petkov wrote:
> On Mon, Dec 07, 2020 at 02:20:55PM -0600, Wei Huang wrote:
>> In summary, this patch is fine if Punit already verified it. My only
>> concern is the list can potentially increase over the time, and we will
>> keep coming back to
ase over the time, and we will
keep coming back to fix override_acpi_psd() function.
> certain earlier systems. Update the check, to skip the override for
> Zen2 processors known to work without the override.
>
> Signed-off-by: Punit Agrawal
> Cc: Wei Huang
> ---
> drivers
On 11/25/20 8:48 AM, Punit Agrawal wrote:
> Re-factor the code to override the firmware provided frequency domain
> information (via PSD) to localise the checks in one function.
>
> No functional change intended.
>
> Signed-off-by: Punit Agrawal
> Cc: Wei Huang
> ---
: acd316248205 ("acpi-cpufreq: Add quirk to disable _PSD usage on all AMD
CPUs")
Signed-off-by: Wei Huang
---
drivers/cpufreq/acpi-cpufreq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index e4
On 10/16 04:58, Rafael J. Wysocki wrote:
> On Wed, Oct 7, 2020 at 10:44 PM Wei Huang wrote:
> >
> > acpi-cpufreq has a old quirk that overrides the _PSD table supplied by
> > BIOS on AMD CPUs. However the _PSD table of new AMD CPUs (Family 19h+)
> > now accurately rep
: acd316248205 ("acpi-cpufreq: Add quirk to disable _PSD usage on all AMD
CPUs")
Signed-off-by: Wei Huang
---
drivers/cpufreq/acpi-cpufreq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index e4
On 09/17 03:23, Cathy Avery wrote:
> svm->vmcb will now point to either a separate vmcb L1 ( not nested ) or L2
> vmcb ( nested ).
>
> Issues:
>
> 1) There is some wholesale copying of vmcb.save and vmcb.contol
>areas which will need to be refined.
>
> 2) There is a workaround in
On 09/16 09:33, Dr. David Alan Gilbert wrote:
> * Wei Huang (wei.hua...@amd.com) wrote:
> > On 09/15 05:51, Dr. David Alan Gilbert wrote:
> > > * Vitaly Kuznetsov (vkuzn...@redhat.com) wrote:
> > > > With QEMU and newer AMD CPUs (namely: Epyc 'Rome') the curren
> Tested-by: Dr. David Alan Gilbert
>
I tested on two platforms and the patches worked fine. So no objection on the
design.
Tested-by: Wei Huang
> > Vitaly Kuznetsov (2):
> > KVM: x86: allocate vcpu->arch.cpuid_entries dynamically
> > KVM
Zen3 thermal info is supported via a new PCI device ID. Also the voltage
telemetry registers and the current factors need to be defined. k10temp
driver then searches for CPU family 0x19 and configures k10temp_data
accordingly.
Signed-off-by: Wei Huang
---
drivers/hwmon/k10temp.c | 24
Many SMN thermal registers in Zen CPU families are common across different
generations. For long-term code maintenance, it is better to rename these
macro and function names to Zen.
Signed-off-by: Wei Huang
---
drivers/hwmon/k10temp.c | 56 +
1 file
The voltage telemetry registers for Zen2 are different from Zen1. Also
the factors of CPU current values are changed on Zen2. Add new definitions
for these register.
Signed-off-by: Wei Huang
---
drivers/hwmon/k10temp.c | 20
1 file changed, 12 insertions(+), 8 deletions
Using space in module alias makes it harder to parse modules.alias.
Replace it by a star(*).
Reviewed-by: Peter Kästle
Signed-off-by: Chih-Wei Huang
---
drivers/platform/x86/acerhdf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/acerhdf.c b/drivers
On 04/30 06:45, Li RongQing wrote:
> Guest kernel reports a fixed cpu frequency in /proc/cpuinfo,
> this is confused to user when turbo is enable, and aperf/mperf
> can be used to show current cpu frequency after 7d5905dc14a
> "(x86 / CPU: Always show current CPU frequency in /proc/cpuinfo)"
> so
aling with EFER.
>
> Signed-off-by: Kirill A. Shutemov
> Fixes: b677dfae5aa1 ("x86/boot/compressed/64: Set EFER.LME=1 in 32-bit
> trampoline before returning to long mode")
> Reported-by: Kyle D Pelton
> Cc: Wei Huang
> ---
> arch/x86/boot/compressed/head_64.S | 2 ++
&
Commit-ID: b677dfae5aa197afc5191755a76a8727ffca538a
Gitweb: https://git.kernel.org/tip/b677dfae5aa197afc5191755a76a8727ffca538a
Author: Wei Huang
AuthorDate: Thu, 3 Jan 2019 23:44:11 -0600
Committer: Thomas Gleixner
CommitDate: Tue, 29 Jan 2019 21:58:59 +0100
x86/boot/compressed/64
On 1/7/19 3:53 PM, Benjamin Gilbert wrote:
> On Mon, Jan 07, 2019 at 02:03:15PM -0600, Wei Huang wrote:
>> On 1/7/19 2:25 AM, Kirill A. Shutemov wrote:
>>> On Fri, Jan 04, 2019 at 05:44:11AM +, Wei Huang wrote:
>>>> In some old AMD KVM implementation, guest's
[adding lkml and linux-x86_64]
On 1/7/19 2:25 AM, Kirill A. Shutemov wrote:
> On Fri, Jan 04, 2019 at 05:44:11AM +0000, Wei Huang wrote:
>> In some old AMD KVM implementation, guest's EFER.LME bit is cleared by KVM
>> when the hypervsior detects guest sets CR0.PG to 0. This
on
between guest VM's CR4 and CPUID bits.
Signed-off-by: Wei Huang
---
tools/testing/selftests/kvm/Makefile | 1 +
tools/testing/selftests/kvm/cr4_cpuid_sync_test.c | 129 ++
2 files changed, 130 insertions(+)
create mode 100644 tools/testing/sel
on
between guest VM's CR4 and CPUID bits.
Signed-off-by: Wei Huang
---
tools/testing/selftests/kvm/Makefile | 1 +
tools/testing/selftests/kvm/cr4_cpuid_sync_test.c | 129 ++
2 files changed, 130 insertions(+)
create mode 100644 tools/testing/sel
On 05/25/2017 10:28 AM, Will Deacon wrote:
> Hi Wei,
>
> On Wed, May 24, 2017 at 09:36:41AM -0500, Wei Huang wrote:
>> We saw perf IRQ init failures when running Linux kernel in an ACPI
>> guest without PMU (i.e. pmu=off). This is because perf IRQ is not
&g
On 05/25/2017 10:28 AM, Will Deacon wrote:
> Hi Wei,
>
> On Wed, May 24, 2017 at 09:36:41AM -0500, Wei Huang wrote:
>> We saw perf IRQ init failures when running Linux kernel in an ACPI
>> guest without PMU (i.e. pmu=off). This is because perf IRQ is not
&g
4ac
[4.073210] [] cpuhp_thread_fun+0xd4/0x11c
[4.074132] [] smpboot_thread_fn+0x1b4/0x1c4
[4.075081] [] kthread+0x10c/0x138
[4.075921] [] ret_from_fork+0x10/0x50
[4.076947] genirq: Setting trigger mode 4 for irq 43 failed
(gic_set_type+0x0/0x74)
Signed-off-by: Wei Huang
4ac
[4.073210] [] cpuhp_thread_fun+0xd4/0x11c
[4.074132] [] smpboot_thread_fn+0x1b4/0x1c4
[4.075081] [] kthread+0x10c/0x138
[4.075921] [] ret_from_fork+0x10/0x50
[4.076947] genirq: Setting trigger mode 4 for irq 43 failed
(gic_set_type+0x0/0x74)
Signed-off-by: Wei Huang
---
driv
On 11/21/2016 03:40 PM, Christopher Covington wrote:
> Hi Wei,
>
> On 11/21/2016 03:24 PM, Wei Huang wrote:
>> From: Christopher Covington <c...@codeaurora.org>
>
> I really appreciate your work on these patches. If for any or all of these
> you have more lines ad
On 11/21/2016 03:40 PM, Christopher Covington wrote:
> Hi Wei,
>
> On 11/21/2016 03:24 PM, Wei Huang wrote:
>> From: Christopher Covington
>
> I really appreciate your work on these patches. If for any or all of these
> you have more lines added/modified than me (o
Changes from v9:
* Move PMCCNTR related configuration from pmu_init() to sub-tests
* Change the name of loop test function to precise_cycles_loop()
* Print out error detail for each test case in check_cpi()
* Fix cpi convertion from argv
* Change the loop calculation in measure_instrs() after cpi
Changes from v9:
* Move PMCCNTR related configuration from pmu_init() to sub-tests
* Change the name of loop test function to precise_cycles_loop()
* Print out error detail for each test case in check_cpi()
* Fix cpi convertion from argv
* Change the loop calculation in measure_instrs() after cpi
From: Christopher Covington <c...@codeaurora.org>
Beginning with a simple sanity check of the control register, add
a unit test for the ARM Performance Monitors Unit (PMU).
Signed-off-by: Christopher Covington <c...@codeaurora.org>
Signed-off-by: Wei Huang <w...@redhat.com>
R
From: Christopher Covington
Beginning with a simple sanity check of the control register, add
a unit test for the ARM Performance Monitors Unit (PMU).
Signed-off-by: Christopher Covington
Signed-off-by: Wei Huang
Reviewed-by: Andrew Jones
---
arm/Makefile.common | 3 ++-
arm/pmu.c
topher Covington <c...@codeaurora.org>
Signed-off-by: Wei Huang <w...@redhat.com>
---
arm/pmu.c | 119 +-
arm/unittests.cfg | 14 +++
2 files changed, 132 insertions(+), 1 deletion(-)
diff --git a/arm/pmu.c b/arm/pmu.c
index 176b0
From: Christopher Covington
Calculate the numbers of cycles per instruction (CPI) implied by ARM
PMU cycle counter values. The code includes a strict checking facility
intended for the -icount option in TCG mode in the configuration file.
Signed-off-by: Christopher Covington
Signed-off-by: Wei
From: Christopher Covington <c...@codeaurora.org>
Ensure that reads of the PMCCNTR_EL0 are monotonically increasing,
even for the smallest delta of two subsequent reads.
Signed-off-by: Christopher Covington <c...@codeaurora.org>
Signed-off-by: Wei Huang <w...@redhat.com>
--
From: Christopher Covington
Ensure that reads of the PMCCNTR_EL0 are monotonically increasing,
even for the smallest delta of two subsequent reads.
Signed-off-by: Christopher Covington
Signed-off-by: Wei Huang
---
arm/pmu.c | 156
From: Christopher Covington <c...@codeaurora.org>
Beginning with a simple sanity check of the control register, add
a unit test for the ARM Performance Monitors Unit (PMU).
Signed-off-by: Christopher Covington <c...@codeaurora.org>
Signed-off-by: Wei Huang <w...@redhat.com>
R
From: Christopher Covington
Beginning with a simple sanity check of the control register, add
a unit test for the ARM Performance Monitors Unit (PMU).
Signed-off-by: Christopher Covington
Signed-off-by: Wei Huang
Reviewed-by: Andrew Jones
---
arm/Makefile.common | 3 ++-
arm/pmu.c
.
Thanks,
-Wei
Wei Huang (3):
arm: Add PMU test
arm: pmu: Check cycle count increases
arm: pmu: Add CPI checking
arm/Makefile.common | 3 +-
arm/pmu.c | 339
arm/unittests.cfg | 19 +++
3 files changed, 360 insertions(+), 1
From: Christopher Covington <c...@codeaurora.org>
Ensure that reads of the PMCCNTR_EL0 are monotonically increasing,
even for the smallest delta of two subsequent reads.
Signed-off-by: Christopher Covington <c...@codeaurora.org>
Signed-off-by: Wei Huang <w...@redhat.com>
--
topher Covington <c...@codeaurora.org>
Signed-off-by: Wei Huang <w...@redhat.com>
---
arm/pmu.c | 111 +-
arm/unittests.cfg | 14 +++
2 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/arm/pmu.c b/arm/pmu.c
index fa87d
.
Thanks,
-Wei
Wei Huang (3):
arm: Add PMU test
arm: pmu: Check cycle count increases
arm: pmu: Add CPI checking
arm/Makefile.common | 3 +-
arm/pmu.c | 339
arm/unittests.cfg | 19 +++
3 files changed, 360 insertions(+), 1
From: Christopher Covington
Ensure that reads of the PMCCNTR_EL0 are monotonically increasing,
even for the smallest delta of two subsequent reads.
Signed-off-by: Christopher Covington
Signed-off-by: Wei Huang
---
arm/pmu.c | 156
From: Christopher Covington
Calculate the numbers of cycles per instruction (CPI) implied by ARM
PMU cycle counter values. The code includes a strict checking facility
intended for the -icount option in TCG mode in the configuration file.
Signed-off-by: Christopher Covington
Signed-off-by: Wei
To support this patch and to prevent duplicated definitions, a limited
set of ARMv8 perf event types were relocated from perf_event.c to
asm/perf_event.h.
Signed-off-by: Wei Huang <w...@redhat.com>
---
arch/arm64/include/asm/perf_event.h | 10 +-
arch/arm64/kernel/perf_e
To support this patch and to prevent duplicated definitions, a limited
set of ARMv8 perf event types were relocated from perf_event.c to
asm/perf_event.h.
Signed-off-by: Wei Huang
---
arch/arm64/include/asm/perf_event.h | 10 +-
arch/arm64/kernel/perf_event.c | 10 +-
virt/kvm
On 11/10/2016 11:17 AM, Will Deacon wrote:
> On Thu, Nov 10, 2016 at 03:32:12PM +, Marc Zyngier wrote:
>> On 10/11/16 15:12, Wei Huang wrote:
>>>
>>>
>>> On 11/10/2016 03:10 AM, Marc Zyngier wrote:
>>>> Hi Wei,
>>>>
>>&
On 11/10/2016 11:17 AM, Will Deacon wrote:
> On Thu, Nov 10, 2016 at 03:32:12PM +, Marc Zyngier wrote:
>> On 10/11/16 15:12, Wei Huang wrote:
>>>
>>>
>>> On 11/10/2016 03:10 AM, Marc Zyngier wrote:
>>>> Hi Wei,
>>>>
>>&
On 11/10/2016 03:10 AM, Marc Zyngier wrote:
> Hi Wei,
>
> On 09/11/16 19:57, Wei Huang wrote:
>> This patch moves ARMv8-related perf event definitions from perf_event.c
>> to asm/perf_event.h; so KVM code can use them directly. This also help
>> remove a dupli
On 11/10/2016 03:10 AM, Marc Zyngier wrote:
> Hi Wei,
>
> On 09/11/16 19:57, Wei Huang wrote:
>> This patch moves ARMv8-related perf event definitions from perf_event.c
>> to asm/perf_event.h; so KVM code can use them directly. This also help
>> remove a dupli
This patch moves ARMv8-related perf event definitions from perf_event.c
to asm/perf_event.h; so KVM code can use them directly. This also help
remove a duplicated definition of SW_INCR in perf_event.h.
Signed-off-by: Wei Huang <w...@redhat.com>
---
arch/arm64/include/asm/perf_event.h
Signed-off-by: Wei Huang <w...@redhat.com>
---
virt/kvm/arm/pmu.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 6e9c40e..69ccce3 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -305,
This patch moves ARMv8-related perf event definitions from perf_event.c
to asm/perf_event.h; so KVM code can use them directly. This also help
remove a duplicated definition of SW_INCR in perf_event.h.
Signed-off-by: Wei Huang
---
arch/arm64/include/asm/perf_event.h | 161
Signed-off-by: Wei Huang
---
virt/kvm/arm/pmu.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 6e9c40e..69ccce3 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -305,7 +305,7 @@ void kvm_pmu_software_increment(struc
On 02/11/2016 09:33 AM, Julien Grall wrote:
> Introduce a structure which are filled up by the arch timer driver and
> used by the virtual timer in KVM.
>
> The first member of this structure will be the timecounter. More members
> will be added later.
>
> This is also dropping
On 02/11/2016 09:33 AM, Julien Grall wrote:
> Introduce a structure which are filled up by the arch timer driver and
> used by the virtual timer in KVM.
>
> The first member of this structure will be the timecounter. More members
> will be added later.
>
> This is also dropping
On 02/11/2016 09:33 AM, Julien Grall wrote:
> Hello,
>
> This small series allows an ARM64 ACPI based platform to use KVM.
>
> Currently the KVM code has to parse the firmware table to get the necessary
> information to setup the virtual timer and virtual GIC.
>
> However the parsing of those
On 02/11/2016 09:33 AM, Julien Grall wrote:
> Hello,
>
> This small series allows an ARM64 ACPI based platform to use KVM.
>
> Currently the KVM code has to parse the firmware table to get the necessary
> information to setup the virtual timer and virtual GIC.
>
> However the parsing of those
On 02/09/2016 02:49 PM, Christoffer Dall wrote:
> On Mon, Feb 08, 2016 at 04:47:27PM +, Julien Grall wrote:
>> For now, the firmware tables are parsed 2 times: once in the GIC
>> drivers, the other timer when initializing the vGIC. It means code
>> duplication and make more tedious to add
On 02/09/2016 02:49 PM, Christoffer Dall wrote:
> On Mon, Feb 08, 2016 at 04:47:27PM +, Julien Grall wrote:
>> For now, the firmware tables are parsed 2 times: once in the GIC
>> drivers, the other timer when initializing the vGIC. It means code
>> duplication and make more tedious to add
On 10/03/2015 05:04 AM, Marc Zyngier wrote:
> On Fri, 2 Oct 2015 16:06:05 -0500
> Wei Huang wrote:
>
> Hi Wei,
>
>> Hi Marc,
>
> [...]
>
>>> +struct acpi_probe_entry {
>>> + __u8 id[ACPI_TABLE_ID_LEN];
>>> + __u8 type
On 10/03/2015 05:04 AM, Marc Zyngier wrote:
> On Fri, 2 Oct 2015 16:06:05 -0500
> Wei Huang <w...@redhat.com> wrote:
>
> Hi Wei,
>
>> Hi Marc,
>
> [...]
>
>>> +struct acpi_probe_entry {
>>> + __u8 id[ACPI_TABLE_ID_LEN];
>&
Hi Marc,
On 09/28/2015 09:49 AM, Marc Zyngier wrote:
> IRQ controllers and timers are the two types of device the kernel
> requires before being able to use the device driver model.
>
> ACPI so far lacks a proper probing infrastructure similar to the one
> we have with DT, where we're able to
Hi Marc,
On 09/28/2015 09:49 AM, Marc Zyngier wrote:
> IRQ controllers and timers are the two types of device the kernel
> requires before being able to use the device driver model.
>
> ACPI so far lacks a proper probing infrastructure similar to the one
> we have with DT, where we're able to
On 8/11/15 08:21, Paolo Bonzini wrote:
On 07/08/2015 21:53, Wei Huang wrote:
These two trivial patches are related to x86 vPMU code. They were
actually suggested by Andrew Jones while he was reviewing the last
big vPMU patch set.
These patches have been compiled and tested on AMD system
On 8/11/15 08:21, Paolo Bonzini wrote:
On 07/08/2015 21:53, Wei Huang wrote:
These two trivial patches are related to x86 vPMU code. They were
actually suggested by Andrew Jones while he was reviewing the last
big vPMU patch set.
These patches have been compiled and tested on AMD system
Instead of being defined in a common header file, the kvm_pmu_ops struct
is arch (vmx/svm) specific. This trivial patch relocates two extern
variable definition to their arch-specific files.
Signed-off-by: Wei Huang
---
arch/x86/kvm/pmu.h | 2 --
arch/x86/kvm/svm.c | 1 +
arch/x86/kvm/vmx.c | 1
According to AMD programmer's manual, AMD PERFCTRn is 64-bit MSR which,
unlike Intel perf counters, doesn't require signed extension. This
patch removes the unnecessary conversion in SVM vPMU code when PERFCTRn
is being updated.
Signed-off-by: Wei Huang
---
arch/x86/kvm/pmu_amd.c | 2 --
1 file
). No obvious problems were found.
Thanks,
-Wei
Wei Huang (2):
KVM: x86/vPMU: Move the definition of kvm_pmu_ops to arch-specific
files
KVM: x86/vPMU: Fix unnecessary signed extesion for AMD PERFCTRn
arch/x86/kvm/pmu.h | 2 --
arch/x86/kvm/pmu_amd.c | 2 --
arch/x86/kvm/svm.c | 1
). No obvious problems were found.
Thanks,
-Wei
Wei Huang (2):
KVM: x86/vPMU: Move the definition of kvm_pmu_ops to arch-specific
files
KVM: x86/vPMU: Fix unnecessary signed extesion for AMD PERFCTRn
arch/x86/kvm/pmu.h | 2 --
arch/x86/kvm/pmu_amd.c | 2 --
arch/x86/kvm/svm.c | 1
According to AMD programmer's manual, AMD PERFCTRn is 64-bit MSR which,
unlike Intel perf counters, doesn't require signed extension. This
patch removes the unnecessary conversion in SVM vPMU code when PERFCTRn
is being updated.
Signed-off-by: Wei Huang w...@redhat.com
---
arch/x86/kvm/pmu_amd.c
Instead of being defined in a common header file, the kvm_pmu_ops struct
is arch (vmx/svm) specific. This trivial patch relocates two extern
variable definition to their arch-specific files.
Signed-off-by: Wei Huang w...@redhat.com
---
arch/x86/kvm/pmu.h | 2 --
arch/x86/kvm/svm.c | 1 +
arch
On 01/22/2015 02:51 AM, Marc Zyngier wrote:
> On Thu, Jan 22 2015 at 5:07:04 am GMT, Stephen Rothwell
> wrote:
>
> Hi Stephen,
>
>> Today's linux-next merge of the kvm-arm tree got a conflict in
>> arch/arm64/include/asm/kvm_arm.h between commit 6e53031ed840 ("arm64:
>> kvm: remove ESR_EL2_*
On 01/22/2015 02:51 AM, Marc Zyngier wrote:
On Thu, Jan 22 2015 at 5:07:04 am GMT, Stephen Rothwell
s...@canb.auug.org.au wrote:
Hi Stephen,
Today's linux-next merge of the kvm-arm tree got a conflict in
arch/arm64/include/asm/kvm_arm.h between commit 6e53031ed840 (arm64:
kvm: remove
Commit-ID: cc6cd47e7395bc05c5077009808b820633eb3f18
Gitweb: http://git.kernel.org/tip/cc6cd47e7395bc05c5077009808b820633eb3f18
Author: Wei Huang
AuthorDate: Wed, 24 Sep 2014 22:55:14 -0500
Committer: Ingo Molnar
CommitDate: Fri, 3 Oct 2014 06:04:41 +0200
perf/x86: Tone down kernel
Commit-ID: cc6cd47e7395bc05c5077009808b820633eb3f18
Gitweb: http://git.kernel.org/tip/cc6cd47e7395bc05c5077009808b820633eb3f18
Author: Wei Huang w...@redhat.com
AuthorDate: Wed, 24 Sep 2014 22:55:14 -0500
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 3 Oct 2014 06:04:41 +0200
Hi Ingo, tglx and hpa,
Any comment on this patch? Thanks.
-Wei
On 09/24/2014 10:55 PM, Wei Huang wrote:
PMU checking can fail due to various reasons. On native machine,
this is mostly caused by faulty hardware and it is reasonable to
use KERN_ERR in reporting. However, when kernel is running
1 - 100 of 115 matches
Mail list logo
