lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190415183929.GI24010@linux.intel.com>
Date:   Mon, 15 Apr 2019 11:39:29 -0700
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH] KVM: vmx: print more APICv fields in dump_vmcs

On Mon, Apr 15, 2019 at 03:35:32PM +0200, Paolo Bonzini wrote:
> The SVI, RVI, virtual-APIC page address and APIC-access page address fields
> were left out of dump_vmcs.  Add them.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
> ---
>  arch/x86/kvm/vmx/vmx.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index ab432a930ae8..f8054dc1de65 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -5723,8 +5723,17 @@ static void dump_vmcs(void)
>  	if (secondary_exec_control & SECONDARY_EXEC_TSC_SCALING)
>  		pr_err("TSC Multiplier = 0x%016llx\n",
>  		       vmcs_read64(TSC_MULTIPLIER));
> -	if (cpu_based_exec_ctrl & CPU_BASED_TPR_SHADOW)
> -		pr_err("TPR Threshold = 0x%02x\n", vmcs_read32(TPR_THRESHOLD));
> +	if (cpu_based_exec_ctrl & CPU_BASED_TPR_SHADOW) {
> +		if (secondary_exec_control & SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY) {
> +			u16 status = vmcs_read16(GUEST_INTR_STATUS);
> +			pr_err("SVI|RVI = %02x|%02x ", status >> 8, status & 0xff);
> +		}
> +		pr_err(KERN_CONT "TPR Threshold = 0x%02x\n", vmcs_read32(TPR_THRESHOLD));

Might be worth adding a blurb in the changelog stating it's ok to use
KERN_CONT even though it's technically not SMP safe, as the whole
dump_vmcs() flow isn't exactly SMP safe.

> +		if (secondary_exec_control & (SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
> +		    			      SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE))

Do we really want to dump the APIC access page address for x2APIC?  I
assume your intent is to show the value that *could* be used if the guest
were to disable x2APIC, but that might be misleading since APIC_ACCESS_ADDR
is checked if and only if VIRTUALIZE_APIC_ACCESSES=1, e.g. someone might
think a VM-Enter failed because APIC_ACCESS_ADDR has a "bad" value even
though it's ignored.

> +			pr_err("APIC-access addr = 0x%016llx ", vmcs_read64(APIC_ACCESS_ADDR));
> +		pr_err(KERN_CONT "virt-APIC addr=0x%016llx\n", vmcs_read64(VIRTUAL_APIC_PAGE_ADDR));
> +	}
>  	if (pin_based_exec_ctrl & PIN_BASED_POSTED_INTR)
>  		pr_err("PostedIntrVec = 0x%02x\n", vmcs_read16(POSTED_INTR_NV));
>  	if ((secondary_exec_control & SECONDARY_EXEC_ENABLE_EPT))
> -- 
> 1.8.3.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ