Re: linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi all,

On Tue, 2 Jun 2020 14:53:58 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kernel/kvm.c
> 
> between commit:
> 
>   a707ae1a9bbb ("x86/entry: Switch page fault exception to IDTENTRY_RAW")
> 
> from the tip tree and commit:
> 
>   68fd66f100d1 ("KVM: x86: extend struct kvm_vcpu_pv_apf_data with token 
> info")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/kernel/kvm.c
> index 07dc47359c4f,d6f22a3a1f7d..
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@@ -217,23 -218,23 +217,23 @@@ again
>   }
>   EXPORT_SYMBOL_GPL(kvm_async_pf_task_wake);
>   
> - u32 noinstr kvm_read_and_reset_pf_reason(void)
>  -u32 kvm_read_and_reset_apf_flags(void)
> ++u32 noinstr kvm_read_and_reset_apf_flags(void)
>   {
> - u32 reason = 0;
> + u32 flags = 0;
>   
>   if (__this_cpu_read(apf_reason.enabled)) {
> - reason = __this_cpu_read(apf_reason.reason);
> - __this_cpu_write(apf_reason.reason, 0);
> + flags = __this_cpu_read(apf_reason.flags);
> + __this_cpu_write(apf_reason.flags, 0);
>   }
>   
> - return reason;
> + return flags;
>   }
> - EXPORT_SYMBOL_GPL(kvm_read_and_reset_pf_reason);
> + EXPORT_SYMBOL_GPL(kvm_read_and_reset_apf_flags);
>  -NOKPROBE_SYMBOL(kvm_read_and_reset_apf_flags);
>   
>  -bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
>  +noinstr bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
>   {
> - u32 reason = kvm_read_and_reset_pf_reason();
> + u32 reason = kvm_read_and_reset_apf_flags();
>  +bool rcu_exit;
>   
>   switch (reason) {
>   case KVM_PV_REASON_PAGE_NOT_PRESENT:

This is now a conflict between the tip tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpQBxIQK4a8B.pgp
Description: OpenPGP digital signature

Re: "x86: Remove Intel MPX" is wrong (Re: linux-next: manual merge of the kvm tree with the tip tree)

[Paolo Bonzini]

On 19/12/18 22:28, Dave Hansen wrote:
> 
> On 12/19/18 1:00 PM, Paolo Bonzini wrote:
>> On 19/12/18 21:54, Dave Hansen wrote:
>>> I should have called this out in the changelog, but I removed *all* the
>>> support because I assumed that guests don't need MPX because no other OS
>>> supported it that I know of.
>>
>> Well, as long as you could have code that sets the MPX bits in XCR0, KVM
>> will have to support it.  My employer happens to sell one such kernel
>> and will probably do so a little less than ten years from now. :)
> 
> Does your employer sell a system that supports live migration across
> major releases?  Or, is it always that you support migration to _newer_
> releases but not older?

Only to the immediately following major release, but a major release has
a long lifetime.  So guests running on RHEL6 will have to reboot
when moving to RHEL8, and will drop MPX support.  But RHEL8 is stuck
supporting MPX even if it's off by default because guests can be
migrated from RHEL7 hosts to RHEL8.

>> In fact I'm not sure we want to ever remove XSAVE support for MPX in KVM
>> as long as the processor supports it.  That is, when KVM does
>> xsave/xrstor of the guest_fpu, we probably want to include MPX in there.
>> That can be contained within KVM, Linux need not enable it in XCR0, 
> 
> I believe you need the feature bit set in XCR0 for XSAVE* to be able to
> operate on it.  So, you could do this, but you would need to save XCR0,
> set the XCR0 MPX bits, do XSAVE or XRSTOR, and restore XCR0 all with
> preemption (and interrupts?) off.

Yes, and on context switch KVM does rely on the kernel saving/restoring
MPX state to userspace (QEMU)'s FPU struct though.  However, I can move
that to the preempt notifier, either open coded or wrapped with XSETBVs.
 One more reason to do our own xsave/xrstor in non-compacted format when
loading/storing guest_fpu.

Paolo

> You could just open-code the MPX save/restore, though.  MPX is
> XSAVE-managed, but not XSAVE-enabled like some other features, IIRC.

Re: "x86: Remove Intel MPX" is wrong (Re: linux-next: manual merge of the kvm tree with the tip tree)

[Dave Hansen]

On 12/19/18 1:00 PM, Paolo Bonzini wrote:
> On 19/12/18 21:54, Dave Hansen wrote:
>> I should have called this out in the changelog, but I removed *all* the
>> support because I assumed that guests don't need MPX because no other OS
>> supported it that I know of.
> 
> Well, as long as you could have code that sets the MPX bits in XCR0, KVM
> will have to support it.  My employer happens to sell one such kernel
> and will probably do so a little less than ten years from now. :)

Does your employer sell a system that supports live migration across
major releases?  Or, is it always that you support migration to _newer_
releases but not older?

>>> A simple fix would be to leave the XSAVE state enabled in the kernel
>>> unconditionally even if all the other gunk is removed; alternatively
>>> I can also try to save/restore it only for the guest FPU.
>>
>> We could do this in two phases: remove the APIs now, and then remove the
>> XSAVE enabling later (4.22 or whenever).
>>
>> But, on the other hand, if we want to remove XSAVE support for MPX,
>> we'll have to break live migration at _some_ point, so why not just do
>> it now?
> 
> In fact I'm not sure we want to ever remove XSAVE support for MPX in KVM
> as long as the processor supports it.  That is, when KVM does
> xsave/xrstor of the guest_fpu, we probably want to include MPX in there.
> That can be contained within KVM, Linux need not enable it in XCR0, 

I believe you need the feature bit set in XCR0 for XSAVE* to be able to
operate on it.  So, you could do this, but you would need to save XCR0,
set the XCR0 MPX bits, do XSAVE or XRSTOR, and restore XCR0 all with
preemption (and interrupts?) off.

You could just open-code the MPX save/restore, though.  MPX is
XSAVE-managed, but not XSAVE-enabled like some other features, IIRC.

Re: "x86: Remove Intel MPX" is wrong (Re: linux-next: manual merge of the kvm tree with the tip tree)

[Paolo Bonzini]

On 19/12/18 21:54, Dave Hansen wrote:
> I should have called this out in the changelog, but I removed *all* the
> support because I assumed that guests don't need MPX because no other OS
> supported it that I know of.

Well, as long as you could have code that sets the MPX bits in XCR0, KVM
will have to support it.  My employer happens to sell one such kernel
and will probably do so a little less than ten years from now. :)

>> A simple fix would be to leave the XSAVE state enabled in the kernel
>> unconditionally even if all the other gunk is removed; alternatively
>> I can also try to save/restore it only for the guest FPU.
> 
> We could do this in two phases: remove the APIs now, and then remove the
> XSAVE enabling later (4.22 or whenever).
> 
> But, on the other hand, if we want to remove XSAVE support for MPX,
> we'll have to break live migration at _some_ point, so why not just do
> it now?

In fact I'm not sure we want to ever remove XSAVE support for MPX in KVM
as long as the processor supports it.  That is, when KVM does
xsave/xrstor of the guest_fpu, we probably want to include MPX in there.
 That can be contained within KVM, Linux need not enable it in XCR0, but
there is one ugly thing: the xsavec offsets would be different between
guest_fpu and other FPUs.  Since KVM is not using supervisor states,
perhaps it's better if that part of the KVM code is completely detached
from the kernel FPU code and uses xsaveopt/xrstoropt instead.

So perhaps the plan should be:

1) remove MPX APIs now

2) then stop using kernel xsave code for KVM's guest_fpu

3) then stop enabling MPX XSAVE in core kernel.

Paolo

>> If this patch can be bumped to 4.22, I would prefer that because it
>> would save me and Linus some merge window headaches.  Considering that
>> the patch lacked my Cc or Ack, perhaps it's the right thing to do.
> 
> That's fine with me as well.

Re: "x86: Remove Intel MPX" is wrong (Re: linux-next: manual merge of the kvm tree with the tip tree)

[Dave Hansen]

On 12/19/18 12:32 PM, Paolo Bonzini wrote:
> On 19/12/18 05:12, Stephen Rothwell wrote:
>> I fixed it up (the former removed some code updated by the latter, so I
>> did that) and can carry the fix as necessary. This is now fixed as far as
>> linux-next is concerned, but any non trivial conflicts should be mentioned
>> to your upstream maintainer when your tree is submitted for merging.
>> You may also want to consider cooperating with the maintainer of the
>> conflicting tree to minimise any particularly complex conflicts.
> 
> Ouch, this resolution is wrong.  KVM will lack support for MPX in guests
> now, and that is bad because it breaks live migration.

I should have called this out in the changelog, but I removed *all* the
support because I assumed that guests don't need MPX because no other OS
supported it that I know of.

> A simple fix would be to leave the XSAVE state enabled in the kernel
> unconditionally even if all the other gunk is removed; alternatively
> I can also try to save/restore it only for the guest FPU.

We could do this in two phases: remove the APIs now, and then remove the
XSAVE enabling later (4.22 or whenever).

But, on the other hand, if we want to remove XSAVE support for MPX,
we'll have to break live migration at _some_ point, so why not just do
it now?

> If this patch can be bumped to 4.22, I would prefer that because it
> would save me and Linus some merge window headaches.  Considering that
> the patch lacked my Cc or Ack, perhaps it's the right thing to do.

That's fine with me as well.

"x86: Remove Intel MPX" is wrong (Re: linux-next: manual merge of the kvm tree with the tip tree)

[Paolo Bonzini]

On 19/12/18 05:12, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/x86.c
> 
> between commit:
> 
>   eb012ef3b4e3 ("x86: Remove Intel MPX")
> 
> from the tip tree and commit:
> 
>   b666a4b69739 ("kvm: x86: Dynamically allocate guest_fpu")
> 
> from the kvm tree.
> 
> I fixed it up (the former removed some code updated by the latter, so I
> did that) and can carry the fix as necessary. This is now fixed as far as
> linux-next is concerned, but any non trivial conflicts should be mentioned
> to your upstream maintainer when your tree is submitted for merging.
> You may also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.

Ouch, this resolution is wrong.  KVM will lack support for MPX in guests
now, and that is bad because it breaks live migration.  A simple fix
would be to leave the XSAVE state enabled in the kernel unconditionally
even if all the other gunk is removed; alternatively I can also try to
save/restore it only for the guest FPU.

If this patch can be bumped to 4.22, I would prefer that because it
would save me and Linus some merge window headaches.  Considering that
the patch lacked my Cc or Ack, perhaps it's the right thing to do.

Paolo

Re: linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi all,

On Wed, 8 Aug 2018 13:54:45 +1000 Stephen Rothwell  
wrote:
>
> Paolo pointed out a semantic conflict between the kvm tree and the tip
> tree in
> 
>   arch/x86/kernel/kvm.c
> 
> between commit:
> 
>   368a540e0232 ("x86/kvmclock: Remove memblock dependency")
> 
> from the tip tree and commit:
> 
>   d63bae079b64 ("KVM: X86: Add kvm hypervisor init time platform setup 
> callback")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> I applied the following (as suggested) after the automatic merge:
> 
> From: Stephen Rothwell 
> Date: Wed, 8 Aug 2018 13:48:34 +1000
> Subject: [PATCH] kvm: x86: fix semantic conflict in platform init
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/x86/kernel/kvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 0906b8731393..e2499bad3209 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -714,13 +714,13 @@ static void __init kvm_apic_init(void)
>  static void __init kvm_init_platform(void)
>  {
>   x86_platform.apic_post_init = kvm_apic_init;
> + kvmclock_init();
>  }
>  
>  const __initconst struct hypervisor_x86 x86_hyper_kvm = {
>   .name   = "KVM",
>   .detect = kvm_detect,
>   .type   = X86_HYPER_KVM,
> - .init.init_platform = kvmclock_init,
>   .init.guest_late_init   = kvm_guest_init,
>   .init.x2apic_available  = kvm_para_available,
>   .init.init_platform = kvm_init_platform,
> -- 
> 2.18.0

This is now a conflict between Linus' tree and the kvm tree.
-- 
Cheers,
Stephen Rothwell


pgpR6IrpU56nd.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi all,

On Wed, 8 Aug 2018 13:54:45 +1000 Stephen Rothwell  
wrote:
>
> Paolo pointed out a semantic conflict between the kvm tree and the tip
> tree in
> 
>   arch/x86/kernel/kvm.c
> 
> between commit:
> 
>   368a540e0232 ("x86/kvmclock: Remove memblock dependency")
> 
> from the tip tree and commit:
> 
>   d63bae079b64 ("KVM: X86: Add kvm hypervisor init time platform setup 
> callback")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> I applied the following (as suggested) after the automatic merge:
> 
> From: Stephen Rothwell 
> Date: Wed, 8 Aug 2018 13:48:34 +1000
> Subject: [PATCH] kvm: x86: fix semantic conflict in platform init
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/x86/kernel/kvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 0906b8731393..e2499bad3209 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -714,13 +714,13 @@ static void __init kvm_apic_init(void)
>  static void __init kvm_init_platform(void)
>  {
>   x86_platform.apic_post_init = kvm_apic_init;
> + kvmclock_init();
>  }
>  
>  const __initconst struct hypervisor_x86 x86_hyper_kvm = {
>   .name   = "KVM",
>   .detect = kvm_detect,
>   .type   = X86_HYPER_KVM,
> - .init.init_platform = kvmclock_init,
>   .init.guest_late_init   = kvm_guest_init,
>   .init.x2apic_available  = kvm_para_available,
>   .init.init_platform = kvm_init_platform,
> -- 
> 2.18.0

This is now a conflict between Linus' tree and the kvm tree.
-- 
Cheers,
Stephen Rothwell


pgpR6IrpU56nd.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the kvm tree with the tip tree

[Tianyu Lan]

Hi Stephen:
Thanks for fix. I will discuss with maintainer about how to deal with 
the issue.

On 8/6/2018 1:12 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>arch/x86/include/asm/trace/hyperv.h
> 
> between commit:
> 
>58ec5e9c9044 ("x86/hyper-v: Trace PV IPI send")
> 
> from the tip tree and commit:
> 
>47c054685621 ("X86/Hyper-V: Add hyperv_nested_flush_guest_mapping ftrace 
> support")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Re: linux-next: manual merge of the kvm tree with the tip tree

[Tianyu Lan]

Hi Stephen:
Thanks for fix. I will discuss with maintainer about how to deal with 
the issue.

On 8/6/2018 1:12 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>arch/x86/include/asm/trace/hyperv.h
> 
> between commit:
> 
>58ec5e9c9044 ("x86/hyper-v: Trace PV IPI send")
> 
> from the tip tree and commit:
> 
>47c054685621 ("X86/Hyper-V: Add hyperv_nested_flush_guest_mapping ftrace 
> support")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Re: linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi all,

On Mon, 28 Aug 2017 14:52:09 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/mmu.c
> 
> between commit:
> 
>   ea2800ddb20d ("kvm/x86: Avoid clearing the C-bit in rsvd_bits()")
> 
> from the tip tree and commit:
> 
>   d6321d493319 ("KVM: x86: generalize guest_cpuid_has_ helpers")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/kvm/mmu.c
> index 04d750813c9d,2a8a6e3e2a31..
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@@ -4116,21 -4157,11 +4162,21 @@@ reset_shadow_zero_bits_mask(struct kvm_
>* Passing "true" to the last argument is okay; it adds a check
>* on bit 8 of the SPTEs which KVM doesn't use anyway.
>*/
>  -__reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
>  +shadow_zero_check = >shadow_zero_check;
>  +__reset_rsvds_bits_mask(vcpu, shadow_zero_check,
>   boot_cpu_data.x86_phys_bits,
>   context->shadow_root_level, uses_nx,
> - guest_cpuid_has_gbpages(vcpu), is_pse(vcpu),
> - true);
> + guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
> + is_pse(vcpu), true);
>  +
>  +if (!shadow_me_mask)
>  +return;
>  +
>  +for (i = context->shadow_root_level; --i >= 0;) {
>  +shadow_zero_check->rsvd_bits_mask[0][i] &= ~shadow_me_mask;
>  +shadow_zero_check->rsvd_bits_mask[1][i] &= ~shadow_me_mask;
>  +}
>  +
>   }
>   EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
>   

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi all,

On Mon, 28 Aug 2017 14:52:09 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/mmu.c
> 
> between commit:
> 
>   ea2800ddb20d ("kvm/x86: Avoid clearing the C-bit in rsvd_bits()")
> 
> from the tip tree and commit:
> 
>   d6321d493319 ("KVM: x86: generalize guest_cpuid_has_ helpers")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/kvm/mmu.c
> index 04d750813c9d,2a8a6e3e2a31..
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@@ -4116,21 -4157,11 +4162,21 @@@ reset_shadow_zero_bits_mask(struct kvm_
>* Passing "true" to the last argument is okay; it adds a check
>* on bit 8 of the SPTEs which KVM doesn't use anyway.
>*/
>  -__reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
>  +shadow_zero_check = >shadow_zero_check;
>  +__reset_rsvds_bits_mask(vcpu, shadow_zero_check,
>   boot_cpu_data.x86_phys_bits,
>   context->shadow_root_level, uses_nx,
> - guest_cpuid_has_gbpages(vcpu), is_pse(vcpu),
> - true);
> + guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
> + is_pse(vcpu), true);
>  +
>  +if (!shadow_me_mask)
>  +return;
>  +
>  +for (i = context->shadow_root_level; --i >= 0;) {
>  +shadow_zero_check->rsvd_bits_mask[0][i] &= ~shadow_me_mask;
>  +shadow_zero_check->rsvd_bits_mask[1][i] &= ~shadow_me_mask;
>  +}
>  +
>   }
>   EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
>   

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kvm tree with the tip tree

[Ingo Molnar]

* Paolo Bonzini  wrote:

> On 25/08/2017 22:41, Brijesh Singh wrote:
> 
> > 
> >> Neither my version nor yours is correct. :)  The right one has [0][i]
> >> and [1][i] (I inverted the indices by mistake).
> >>
> >> With that change, you can include my
> >>
> >> Acked-by: Paolo Bonzini 
> >>
> > 
> > Ingo,
> > 
> > I assuming that this patch should be sent through the tip since SME support
> > came from tip. I will be submitting the patch very soon.
> 
> Yes, that is correct.  I cannot apply it directly to the KVM tree.

I've merged it to tip:x86/mm where the SME bits live and will propagate it to 
linux-next ASAP, once it's gone through my local testing.

Thanks,

Ingo

Re: linux-next: manual merge of the kvm tree with the tip tree

[Ingo Molnar]

* Paolo Bonzini  wrote:

> On 25/08/2017 22:41, Brijesh Singh wrote:
> 
> > 
> >> Neither my version nor yours is correct. :)  The right one has [0][i]
> >> and [1][i] (I inverted the indices by mistake).
> >>
> >> With that change, you can include my
> >>
> >> Acked-by: Paolo Bonzini 
> >>
> > 
> > Ingo,
> > 
> > I assuming that this patch should be sent through the tip since SME support
> > came from tip. I will be submitting the patch very soon.
> 
> Yes, that is correct.  I cannot apply it directly to the KVM tree.

I've merged it to tip:x86/mm where the SME bits live and will propagate it to 
linux-next ASAP, once it's gone through my local testing.

Thanks,

Ingo

Re: linux-next: manual merge of the kvm tree with the tip tree

[Paolo Bonzini]

On 25/08/2017 22:41, Brijesh Singh wrote:

> 
>> Neither my version nor yours is correct. :)  The right one has [0][i]
>> and [1][i] (I inverted the indices by mistake).
>>
>> With that change, you can include my
>>
>> Acked-by: Paolo Bonzini 
>>
> 
> Ingo,
> 
> I assuming that this patch should be sent through the tip since SME support
> came from tip. I will be submitting the patch very soon.

Yes, that is correct.  I cannot apply it directly to the KVM tree.

Paolo

Re: linux-next: manual merge of the kvm tree with the tip tree

[Paolo Bonzini]

On 25/08/2017 22:41, Brijesh Singh wrote:

> 
>> Neither my version nor yours is correct. :)  The right one has [0][i]
>> and [1][i] (I inverted the indices by mistake).
>>
>> With that change, you can include my
>>
>> Acked-by: Paolo Bonzini 
>>
> 
> Ingo,
> 
> I assuming that this patch should be sent through the tip since SME support
> came from tip. I will be submitting the patch very soon.

Yes, that is correct.  I cannot apply it directly to the KVM tree.

Paolo

Re: linux-next: manual merge of the kvm tree with the tip tree

[Brijesh Singh]

On 08/25/2017 03:05 PM, Paolo Bonzini wrote:

On 25/08/2017 18:53, Brijesh Singh wrote:





Neither my version nor yours is correct. :)  The right one has [0][i]
and [1][i] (I inverted the indices by mistake).

With that change, you can include my

Acked-by: Paolo Bonzini 



Ingo,

I assuming that this patch should be sent through the tip since SME support
came from tip. I will be submitting the patch very soon.

-Brijesh

Re: linux-next: manual merge of the kvm tree with the tip tree

[Brijesh Singh]

On 08/25/2017 03:05 PM, Paolo Bonzini wrote:

On 25/08/2017 18:53, Brijesh Singh wrote:





Neither my version nor yours is correct. :)  The right one has [0][i]
and [1][i] (I inverted the indices by mistake).

With that change, you can include my

Acked-by: Paolo Bonzini 



Ingo,

I assuming that this patch should be sent through the tip since SME support
came from tip. I will be submitting the patch very soon.

-Brijesh

Re: linux-next: manual merge of the kvm tree with the tip tree

[Paolo Bonzini]

On 25/08/2017 18:53, Brijesh Singh wrote:
>>
> 
> Thanks for the tip, I have expanded the patch to cover tdp cases and
> have verified
> that it works fine with SME enabled KVM. If you are okay with this then
> I can
> send patch.
> 
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ccb70b8..7a8edc0 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -4109,16 +4109,30 @@ void
>  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu
> *context)
>  {
> bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
> +   struct rsvd_bits_validate *shadow_zero_check;
> +   int i;
>  
> /*
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ccb70b8..7a8edc0 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -4109,16 +4109,30 @@ void
>  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu
> *context)
>  {
> bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
> +   struct rsvd_bits_validate *shadow_zero_check;
> +   int i;
>  
> /*
>  * Passing "true" to the last argument is okay; it adds a check
>  * on bit 8 of the SPTEs which KVM doesn't use anyway.
>  */
> -   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
> +   shadow_zero_check = >shadow_zero_check;
> +   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
> boot_cpu_data.x86_phys_bits,
> context->shadow_root_level, uses_nx,
> guest_cpuid_has_gbpages(vcpu),
> is_pse(vcpu),
> true);
> +
> +   if (!shadow_me_mask)
> +   return;
> +
> +   for (i = context->shadow_root_level; --i >= 0;) {
> +   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;

Neither my version nor yours is correct. :)  The right one has [0][i]
and [1][i] (I inverted the indices by mistake).

With that change, you can include my

Acked-by: Paolo Bonzini 

> +   }
> +
>  }
>  EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
>  
> @@ -4136,8 +4150,13 @@ static void
>  reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu *vcpu,
> struct kvm_mmu *context)
>  {
> +   struct rsvd_bits_validate *shadow_zero_check;
> +   int i;
> +
> +   shadow_zero_check = >shadow_zero_check;
> +
> if (boot_cpu_is_amd())
> -   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
> +   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
> boot_cpu_data.x86_phys_bits,
> context->shadow_root_level, false,
> boot_cpu_has(X86_FEATURE_GBPAGES),

Please use shadow_zero_check here too:

__reset_rsvds_bits_mask_ept(>shadow_zero_check,

Thanks,

Paolo

> @@ -4147,6 +4166,15 @@ reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu
> *vcpu,
> boot_cpu_data.x86_phys_bits,
> false);
>  
> +   if (!shadow_me_mask)
> +   return;
> +
> +   for (i = context->shadow_root_level; --i >= 0;) {
> +   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;
> +   }
>  }
>  
>  /*
> diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
> index 3cc7255..d7d248a 100644
> --- a/arch/x86/kvm/mmu.h
> +++ b/arch/x86/kvm/mmu.h
> @@ -48,7 +48,7 @@
>  
>  static inline u64 rsvd_bits(int s, int e)
>  {
> -   return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
> +   return ((1ULL << (e - s + 1)) - 1) << s;
>  }
>  
>  void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value);
> 
> 

Re: linux-next: manual merge of the kvm tree with the tip tree

[Paolo Bonzini]

On 25/08/2017 18:53, Brijesh Singh wrote:
>>
> 
> Thanks for the tip, I have expanded the patch to cover tdp cases and
> have verified
> that it works fine with SME enabled KVM. If you are okay with this then
> I can
> send patch.
> 
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ccb70b8..7a8edc0 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -4109,16 +4109,30 @@ void
>  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu
> *context)
>  {
> bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
> +   struct rsvd_bits_validate *shadow_zero_check;
> +   int i;
>  
> /*
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ccb70b8..7a8edc0 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -4109,16 +4109,30 @@ void
>  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu
> *context)
>  {
> bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
> +   struct rsvd_bits_validate *shadow_zero_check;
> +   int i;
>  
> /*
>  * Passing "true" to the last argument is okay; it adds a check
>  * on bit 8 of the SPTEs which KVM doesn't use anyway.
>  */
> -   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
> +   shadow_zero_check = >shadow_zero_check;
> +   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
> boot_cpu_data.x86_phys_bits,
> context->shadow_root_level, uses_nx,
> guest_cpuid_has_gbpages(vcpu),
> is_pse(vcpu),
> true);
> +
> +   if (!shadow_me_mask)
> +   return;
> +
> +   for (i = context->shadow_root_level; --i >= 0;) {
> +   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;

Neither my version nor yours is correct. :)  The right one has [0][i]
and [1][i] (I inverted the indices by mistake).

With that change, you can include my

Acked-by: Paolo Bonzini 

> +   }
> +
>  }
>  EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
>  
> @@ -4136,8 +4150,13 @@ static void
>  reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu *vcpu,
> struct kvm_mmu *context)
>  {
> +   struct rsvd_bits_validate *shadow_zero_check;
> +   int i;
> +
> +   shadow_zero_check = >shadow_zero_check;
> +
> if (boot_cpu_is_amd())
> -   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
> +   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
> boot_cpu_data.x86_phys_bits,
> context->shadow_root_level, false,
> boot_cpu_has(X86_FEATURE_GBPAGES),

Please use shadow_zero_check here too:

__reset_rsvds_bits_mask_ept(>shadow_zero_check,

Thanks,

Paolo

> @@ -4147,6 +4166,15 @@ reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu
> *vcpu,
> boot_cpu_data.x86_phys_bits,
> false);
>  
> +   if (!shadow_me_mask)
> +   return;
> +
> +   for (i = context->shadow_root_level; --i >= 0;) {
> +   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
> +   shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;
> +   }
>  }
>  
>  /*
> diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
> index 3cc7255..d7d248a 100644
> --- a/arch/x86/kvm/mmu.h
> +++ b/arch/x86/kvm/mmu.h
> @@ -48,7 +48,7 @@
>  
>  static inline u64 rsvd_bits(int s, int e)
>  {
> -   return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
> +   return ((1ULL << (e - s + 1)) - 1) << s;
>  }
>  
>  void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value);
> 
> 

Re: linux-next: manual merge of the kvm tree with the tip tree

[Brijesh Singh]

Hi Paolo,


On 08/25/2017 08:57 AM, Tom Lendacky wrote:

On 8/25/2017 1:39 AM, Paolo Bonzini wrote:

On 25/08/2017 06:39, Stephen Rothwell wrote:



First, rsvd_bits is just a simple function to return some 1 bits.  Applying
a mask based on properties of the host MMU is incorrect.

Second, the masks computed by __reset_rsvds_bits_mask also apply to
guest page tables, where the C bit is reserved since we don't emulate
SME.

Something like this:




Thanks for the tip, I have expanded the patch to cover tdp cases and have 
verified
that it works fine with SME enabled KVM. If you are okay with this then I can
send patch.

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ccb70b8..7a8edc0 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4109,16 +4109,30 @@ void
 reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
 {
bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+   struct rsvd_bits_validate *shadow_zero_check;
+   int i;
 
/*

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ccb70b8..7a8edc0 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4109,16 +4109,30 @@ void
 reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
 {
bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+   struct rsvd_bits_validate *shadow_zero_check;
+   int i;
 
/*

 * Passing "true" to the last argument is okay; it adds a check
 * on bit 8 of the SPTEs which KVM doesn't use anyway.
 */
-   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
+   shadow_zero_check = >shadow_zero_check;
+   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
boot_cpu_data.x86_phys_bits,
context->shadow_root_level, uses_nx,
guest_cpuid_has_gbpages(vcpu), is_pse(vcpu),
true);
+
+   if (!shadow_me_mask)
+   return;
+
+   for (i = context->shadow_root_level; --i >= 0;) {
+   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;
+   }
+
 }
 EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
 
@@ -4136,8 +4150,13 @@ static void

 reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu *vcpu,
struct kvm_mmu *context)
 {
+   struct rsvd_bits_validate *shadow_zero_check;
+   int i;
+
+   shadow_zero_check = >shadow_zero_check;
+
if (boot_cpu_is_amd())
-   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
+   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
boot_cpu_data.x86_phys_bits,
context->shadow_root_level, false,
boot_cpu_has(X86_FEATURE_GBPAGES),
@@ -4147,6 +4166,15 @@ reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu *vcpu,
boot_cpu_data.x86_phys_bits,
false);
 
+   if (!shadow_me_mask)

+   return;
+
+   for (i = context->shadow_root_level; --i >= 0;) {
+   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;
+   }
 }
 
 /*

diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 3cc7255..d7d248a 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -48,7 +48,7 @@
 
 static inline u64 rsvd_bits(int s, int e)

 {
-   return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
+   return ((1ULL << (e - s + 1)) - 1) << s;
 }
 
 void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value);







Thanks Paolo, Brijesh and I will test this and make sure everything works
properly with this patch.

Thanks,
Tom



diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2dafd36368cc..e0597d703d72 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4142,16 +4142,24 @@ void
  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
  {
  bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+struct rsvd_bits_validate *shadow_zero_check;
+int i;
  /*
   * Passing "true" to the last argument is okay; it adds a check
   * on bit 8 of the SPTEs which KVM doesn't use anyway.
   */
-__reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
+shadow_zero_check = >shadow_zero_check;
+__reset_rsvds_bits_mask(vcpu, shadow_zero_check,
  

Re: linux-next: manual merge of the kvm tree with the tip tree

[Brijesh Singh]

Hi Paolo,


On 08/25/2017 08:57 AM, Tom Lendacky wrote:

On 8/25/2017 1:39 AM, Paolo Bonzini wrote:

On 25/08/2017 06:39, Stephen Rothwell wrote:



First, rsvd_bits is just a simple function to return some 1 bits.  Applying
a mask based on properties of the host MMU is incorrect.

Second, the masks computed by __reset_rsvds_bits_mask also apply to
guest page tables, where the C bit is reserved since we don't emulate
SME.

Something like this:




Thanks for the tip, I have expanded the patch to cover tdp cases and have 
verified
that it works fine with SME enabled KVM. If you are okay with this then I can
send patch.

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ccb70b8..7a8edc0 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4109,16 +4109,30 @@ void
 reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
 {
bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+   struct rsvd_bits_validate *shadow_zero_check;
+   int i;
 
/*

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ccb70b8..7a8edc0 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4109,16 +4109,30 @@ void
 reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
 {
bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+   struct rsvd_bits_validate *shadow_zero_check;
+   int i;
 
/*

 * Passing "true" to the last argument is okay; it adds a check
 * on bit 8 of the SPTEs which KVM doesn't use anyway.
 */
-   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
+   shadow_zero_check = >shadow_zero_check;
+   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
boot_cpu_data.x86_phys_bits,
context->shadow_root_level, uses_nx,
guest_cpuid_has_gbpages(vcpu), is_pse(vcpu),
true);
+
+   if (!shadow_me_mask)
+   return;
+
+   for (i = context->shadow_root_level; --i >= 0;) {
+   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;
+   }
+
 }
 EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
 
@@ -4136,8 +4150,13 @@ static void

 reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu *vcpu,
struct kvm_mmu *context)
 {
+   struct rsvd_bits_validate *shadow_zero_check;
+   int i;
+
+   shadow_zero_check = >shadow_zero_check;
+
if (boot_cpu_is_amd())
-   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
+   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
boot_cpu_data.x86_phys_bits,
context->shadow_root_level, false,
boot_cpu_has(X86_FEATURE_GBPAGES),
@@ -4147,6 +4166,15 @@ reset_tdp_shadow_zero_bits_mask(struct kvm_vcpu *vcpu,
boot_cpu_data.x86_phys_bits,
false);
 
+   if (!shadow_me_mask)

+   return;
+
+   for (i = context->shadow_root_level; --i >= 0;) {
+   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][2] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][3] &= ~shadow_me_mask;
+   }
 }
 
 /*

diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 3cc7255..d7d248a 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -48,7 +48,7 @@
 
 static inline u64 rsvd_bits(int s, int e)

 {
-   return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
+   return ((1ULL << (e - s + 1)) - 1) << s;
 }
 
 void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value);







Thanks Paolo, Brijesh and I will test this and make sure everything works
properly with this patch.

Thanks,
Tom



diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2dafd36368cc..e0597d703d72 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4142,16 +4142,24 @@ void
  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
  {
  bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+struct rsvd_bits_validate *shadow_zero_check;
+int i;
  /*
   * Passing "true" to the last argument is okay; it adds a check
   * on bit 8 of the SPTEs which KVM doesn't use anyway.
   */
-__reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
+shadow_zero_check = >shadow_zero_check;
+__reset_rsvds_bits_mask(vcpu, shadow_zero_check,
  

Re: linux-next: manual merge of the kvm tree with the tip tree

[Tom Lendacky]

On 8/25/2017 1:39 AM, Paolo Bonzini wrote:

On 25/08/2017 06:39, Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

   arch/x86/kvm/mmu.h

between commit:

   d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")

from the tip tree and commit:

   d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its physical 
address width.")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.



Thomas L., Ingo,

this is completely wrong:



  static inline u64 rsvd_bits(int s, int e)
  {
-   return ((1ULL << (e - s + 1)) - 1) << s;
+   return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
  }
  


First, rsvd_bits is just a simple function to return some 1 bits.  Applying
a mask based on properties of the host MMU is incorrect.

Second, the masks computed by __reset_rsvds_bits_mask also apply to
guest page tables, where the C bit is reserved since we don't emulate
SME.

Something like this:


Thanks Paolo, Brijesh and I will test this and make sure everything works
properly with this patch.

Thanks,
Tom



diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2dafd36368cc..e0597d703d72 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4142,16 +4142,24 @@ void
  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
  {
bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+   struct rsvd_bits_validate *shadow_zero_check;
+   int i;
  
  	/*

 * Passing "true" to the last argument is okay; it adds a check
 * on bit 8 of the SPTEs which KVM doesn't use anyway.
 */
-   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
+shadow_zero_check = >shadow_zero_check;
+   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
boot_cpu_data.x86_phys_bits,
context->shadow_root_level, uses_nx,
guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
is_pse(vcpu), true);
+
+   for (i = context->shadow_root_level; --i >= 0; ) {
+   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
+   }
  }
  EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
  


Can you please fix it up?   Please Cc me at paolo.bonz...@gmail.com too
because I'll be on vacation next week.

(And thanks Stephen for the heads-up!)

Paolo

Re: linux-next: manual merge of the kvm tree with the tip tree

[Tom Lendacky]

On 8/25/2017 1:39 AM, Paolo Bonzini wrote:

On 25/08/2017 06:39, Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

   arch/x86/kvm/mmu.h

between commit:

   d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")

from the tip tree and commit:

   d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its physical 
address width.")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.



Thomas L., Ingo,

this is completely wrong:



  static inline u64 rsvd_bits(int s, int e)
  {
-   return ((1ULL << (e - s + 1)) - 1) << s;
+   return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
  }
  


First, rsvd_bits is just a simple function to return some 1 bits.  Applying
a mask based on properties of the host MMU is incorrect.

Second, the masks computed by __reset_rsvds_bits_mask also apply to
guest page tables, where the C bit is reserved since we don't emulate
SME.

Something like this:


Thanks Paolo, Brijesh and I will test this and make sure everything works
properly with this patch.

Thanks,
Tom



diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2dafd36368cc..e0597d703d72 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4142,16 +4142,24 @@ void
  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
  {
bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+   struct rsvd_bits_validate *shadow_zero_check;
+   int i;
  
  	/*

 * Passing "true" to the last argument is okay; it adds a check
 * on bit 8 of the SPTEs which KVM doesn't use anyway.
 */
-   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
+shadow_zero_check = >shadow_zero_check;
+   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
boot_cpu_data.x86_phys_bits,
context->shadow_root_level, uses_nx,
guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
is_pse(vcpu), true);
+
+   for (i = context->shadow_root_level; --i >= 0; ) {
+   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
+   }
  }
  EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
  


Can you please fix it up?   Please Cc me at paolo.bonz...@gmail.com too
because I'll be on vacation next week.

(And thanks Stephen for the heads-up!)

Paolo

Re: linux-next: manual merge of the kvm tree with the tip tree

[Paolo Bonzini]

On 25/08/2017 06:39, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/mmu.h
> 
> between commit:
> 
>   d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")
> 
> from the tip tree and commit:
> 
>   d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its 
> physical address width.")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Thomas L., Ingo,

this is completely wrong:

> 
>  static inline u64 rsvd_bits(int s, int e)
>  {
> - return ((1ULL << (e - s + 1)) - 1) << s;
> + return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
>  }
>  

First, rsvd_bits is just a simple function to return some 1 bits.  Applying
a mask based on properties of the host MMU is incorrect.

Second, the masks computed by __reset_rsvds_bits_mask also apply to 
guest page tables, where the C bit is reserved since we don't emulate
SME.

Something like this:

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2dafd36368cc..e0597d703d72 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4142,16 +4142,24 @@ void
 reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
 {
bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+   struct rsvd_bits_validate *shadow_zero_check;
+   int i;
 
/*
 * Passing "true" to the last argument is okay; it adds a check
 * on bit 8 of the SPTEs which KVM doesn't use anyway.
 */
-   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
+shadow_zero_check = >shadow_zero_check;
+   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
boot_cpu_data.x86_phys_bits,
context->shadow_root_level, uses_nx,
guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
is_pse(vcpu), true);
+
+   for (i = context->shadow_root_level; --i >= 0; ) {
+   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
+   }
 }
 EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
 

Can you please fix it up?   Please Cc me at paolo.bonz...@gmail.com too 
because I'll be on vacation next week.

(And thanks Stephen for the heads-up!)

Paolo

Re: linux-next: manual merge of the kvm tree with the tip tree

[Paolo Bonzini]

On 25/08/2017 06:39, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kvm/mmu.h
> 
> between commit:
> 
>   d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")
> 
> from the tip tree and commit:
> 
>   d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its 
> physical address width.")
> 
> from the kvm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Thomas L., Ingo,

this is completely wrong:

> 
>  static inline u64 rsvd_bits(int s, int e)
>  {
> - return ((1ULL << (e - s + 1)) - 1) << s;
> + return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
>  }
>  

First, rsvd_bits is just a simple function to return some 1 bits.  Applying
a mask based on properties of the host MMU is incorrect.

Second, the masks computed by __reset_rsvds_bits_mask also apply to 
guest page tables, where the C bit is reserved since we don't emulate
SME.

Something like this:

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2dafd36368cc..e0597d703d72 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4142,16 +4142,24 @@ void
 reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
 {
bool uses_nx = context->nx || context->base_role.smep_andnot_wp;
+   struct rsvd_bits_validate *shadow_zero_check;
+   int i;
 
/*
 * Passing "true" to the last argument is okay; it adds a check
 * on bit 8 of the SPTEs which KVM doesn't use anyway.
 */
-   __reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
+shadow_zero_check = >shadow_zero_check;
+   __reset_rsvds_bits_mask(vcpu, shadow_zero_check,
boot_cpu_data.x86_phys_bits,
context->shadow_root_level, uses_nx,
guest_cpuid_has(vcpu, X86_FEATURE_GBPAGES),
is_pse(vcpu), true);
+
+   for (i = context->shadow_root_level; --i >= 0; ) {
+   shadow_zero_check->rsvd_bits_mask[i][0] &= ~shadow_me_mask;
+   shadow_zero_check->rsvd_bits_mask[i][1] &= ~shadow_me_mask;
+   }
 }
 EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);
 

Can you please fix it up?   Please Cc me at paolo.bonz...@gmail.com too 
because I'll be on vacation next week.

(And thanks Stephen for the heads-up!)

Paolo

Re: linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi Thomas,

On Thu, 17 Nov 2016 08:07:27 +0100 (CET) Thomas Gleixner  
wrote:
>
> On Thu, 17 Nov 2016, Stephen Rothwell wrote:
> > + /* Please keep the leaf sorted by cpuid_bit.level for faster search. */
> > + static const struct cpuid_bit cpuid_bits[] = {
> > +   { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> > +   { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> > ++  { X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> > ++  { X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> > ++  { X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> > +   { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> > +   { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> > +   { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> > +   { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> > +   { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> > +   { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> > +   { 0, 0, 0, 0, 0 }
> >   };  
> 
> This should be
> 
> > + static const struct cpuid_bit cpuid_bits[] = {
> > +   { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> > +   { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> > +   { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> > +   { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> > +   { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> > ++  { X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> > ++  { X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> > ++  { X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> > +   { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> > +   { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> > +   { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> > +   { 0, 0, 0, 0, 0 }
> >   };  

Thanks for letting me know.

> tip will carry a proper resolution today.

Too easy.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi Thomas,

On Thu, 17 Nov 2016 08:07:27 +0100 (CET) Thomas Gleixner  
wrote:
>
> On Thu, 17 Nov 2016, Stephen Rothwell wrote:
> > + /* Please keep the leaf sorted by cpuid_bit.level for faster search. */
> > + static const struct cpuid_bit cpuid_bits[] = {
> > +   { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> > +   { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> > ++  { X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> > ++  { X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> > ++  { X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> > +   { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> > +   { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> > +   { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> > +   { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> > +   { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> > +   { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> > +   { 0, 0, 0, 0, 0 }
> >   };  
> 
> This should be
> 
> > + static const struct cpuid_bit cpuid_bits[] = {
> > +   { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> > +   { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> > +   { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> > +   { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> > +   { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> > ++  { X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> > ++  { X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> > ++  { X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> > +   { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> > +   { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> > +   { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> > +   { 0, 0, 0, 0, 0 }
> >   };  

Thanks for letting me know.

> tip will carry a proper resolution today.

Too easy.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kvm tree with the tip tree

[Thomas Gleixner]

On Thu, 17 Nov 2016, Stephen Rothwell wrote:
> + /* Please keep the leaf sorted by cpuid_bit.level for faster search. */
> + static const struct cpuid_bit cpuid_bits[] = {
> + { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> + { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> ++{ X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> ++{ X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> ++{ X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> + { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> + { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> + { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> + { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> + { 0, 0, 0, 0, 0 }
>   };

This should be

> + static const struct cpuid_bit cpuid_bits[] = {
> + { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> + { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> + { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> ++{ X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> ++{ X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> ++{ X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> + { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> + { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> + { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> + { 0, 0, 0, 0, 0 }
>   };

tip will carry a proper resolution today.

Thanks,

tglx

Re: linux-next: manual merge of the kvm tree with the tip tree

[Thomas Gleixner]

On Thu, 17 Nov 2016, Stephen Rothwell wrote:
> + /* Please keep the leaf sorted by cpuid_bit.level for faster search. */
> + static const struct cpuid_bit cpuid_bits[] = {
> + { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> + { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> ++{ X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> ++{ X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> ++{ X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> + { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> + { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> + { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> + { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> + { 0, 0, 0, 0, 0 }
>   };

This should be

> + static const struct cpuid_bit cpuid_bits[] = {
> + { X86_FEATURE_APERFMPERF,   CPUID_ECX,  0, 0x0006, 0 },
> + { X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
> + { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
> + { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
> ++{ X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
> ++{ X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
> ++{ X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
> + { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
> + { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
> + { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> + { 0, 0, 0, 0, 0 }
>   };

tip will carry a proper resolution today.

Thanks,

tglx