support
* 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 handl
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 into
ts 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/in
Signed-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..83c40
oblem 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
ff-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
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
>> in
ts 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/includ
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(-)
dif
oblem 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
ff-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
1->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 = &svm->vcpu;
>> u32 error_code = svm->vmcb->control.exit_info_1;
>>
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
real
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
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
--- a/arch
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 instru
e #GP 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/cpu
oblem 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-o
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 55163a1c00fcb526e2aa9f7f952f
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 th
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
increase 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
> ---
> dr
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
> ---
Fixes: 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
ind
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
Fixes: 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
ind
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 nested_svm
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')
s to work for me, so:
>
> 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_entri
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 g
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&#x
[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 c
ization
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/t
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
>>
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
>
> 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 i
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
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
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
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
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
(i.e. 0x11).
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 +
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 duplicat
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
.e. 0x11).
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_
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 arch_timer_get_t
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 the
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
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 dec
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
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
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_* m
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
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
is annoying to see
an error message on splash screen, even though we know such failure
is benign on virtualized environment.
This patch checks if kernel is running in virtualized environment.
If so, it will use KERN_INFO in reporting. This patch was tested
successfully on KVM.
Signed-off-by: Wei
>>
>>
>> Is this specified anywhere in SDM as a requirement for x86 OS? If so,
>> maybe provide a pointer to support this.
>
>
> In the case of the Intel manuals, it mentions in several places that
> SS.DPL=CPL. All the mentions are in the VMX sections of the manual, though
> I've found non-Intel
>> During task switch, all of CS.DPL, CS.RPL, SS.DPL must match (in addition
>> to all the other requirements) and will be the new CPL. So far this
>> worked by carefully setting the CS selector and flag before doing the
>
> s/flag/EFLAGS/
>
>> task switch; however, this will not work once we get
> CS.RPL is not equal to the CPL in the few instructions between
> setting CR0.PE and reloading CS. And CS.DPL is also not equal
> to the CPL for conforming code segments.
Out of my curiousity, could you elaborate the problem of this
CPL gap window, such as breaking any VMs or tests? From Linux k
On Sat, May 24, 2014 at 1:12 PM, Wei Huang wrote:
> Table 7-1 of the SDM mentions a check that the code segment's
> DPL must match the selector's RPL. This was not done by KVM,
> fix it.
>
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/emulate.c | 31 +
> Not needed anymore now that the CPL is computed directly
> by the task switch code.
Given the current form, looks OK to me.
Reviewed-by: Wei Huang
>
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/include/asm/kvm_emulate.h | 1 -
> arch/x86/kvm/x86.c
> Another day, another CPL patch...
>
> It turns out that the simple approach of getting CPL from SS.DPL
> broke x86/taskswitch2.flat. To fix that, already "imagine" that the
> CPL is CS.RPL, or 3 for VM86 tasks, while loading segment descriptors
> during task switches. This removes the hack wher
79 matches
Mail list logo
