public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
	Janosch Frank <frankja@linux.vnet.ibm.com>
Cc: KVM <kvm@vger.kernel.org>, Cornelia Huck <cohuck@redhat.com>,
	linux-s390 <linux-s390@vger.kernel.org>
Subject: Re: [PATCH] KVM: s390: force bp isolation for VSIE
Date: Wed, 14 Feb 2018 11:37:30 +0100	[thread overview]
Message-ID: <2fee7e07-d85f-191a-40c1-42a13704efee@redhat.com> (raw)
In-Reply-To: <d452d4fe-f603-79f4-b83e-24badafb41a6@de.ibm.com>

On 14.02.2018 11:14, Christian Borntraeger wrote:
> 
> 
> On 02/14/2018 11:06 AM, David Hildenbrand wrote:
>> On 14.02.2018 09:34, Christian Borntraeger wrote:
>>> If the guest runs with bp isolation when doing a SIE instruction,
>>> we must also run the nested guest with bp isolation when emulating
>>> that SIE instruction.
>>>
>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>> ---
>>>  arch/s390/kvm/vsie.c | 15 +++++++++++++++
>>>  1 file changed, 15 insertions(+)
>>>
>>> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
>>> index ec772700ff96..b8e7660d7207 100644
>>> --- a/arch/s390/kvm/vsie.c
>>> +++ b/arch/s390/kvm/vsie.c
>>> @@ -821,6 +821,7 @@ static int do_vsie_run(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>>>  {
>>>  	struct kvm_s390_sie_block *scb_s = &vsie_page->scb_s;
>>>  	struct kvm_s390_sie_block *scb_o = vsie_page->scb_o;
>>> +	int guest_bp_isolation;
>>>  	int rc;
>>>  
>>>  	handle_last_fault(vcpu, vsie_page);
>>> @@ -831,6 +832,15 @@ static int do_vsie_run(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>>>  		s390_handle_mcck();
>>>  
>>>  	srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
>>> +
>>> +	/* save current guest state of bp isolation override */
>>> +	guest_bp_isolation = test_thread_flag(TIF_ISOLATE_BP_GUEST);
>>
>> If I am not wrong, this is not "guest state". The guest state is
>> vcpu->arch.sie_block->fpf . This is host state of a thread.
> 
> Yes, this is the host thread that is going to "emulate" the vsie instruction
> by calling sie64a.
> 
>>
>>> +
>>> +	/* if guest runs with bp isolation force it on nested guest */
>>> +	if (test_kvm_facility(vcpu->kvm, 82) &&
>>> +	    vcpu->arch.sie_block->fpf & FPF_BPBC)
>>> +		set_thread_flag(TIF_ISOLATE_BP_GUEST);
>>> +
>>>  	local_irq_disable();
>>>  	guest_enter_irqoff();
>>>  	local_irq_enable();
>>> @@ -840,6 +850,11 @@ static int do_vsie_run(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>>>  	local_irq_disable();
>>>  	guest_exit_irqoff();
>>>  	local_irq_enable();
>>> +
>>> +	/* restore guest state for bp isolation override */
>>> +	if (!guest_bp_isolation)
>>> +		clear_thread_flag(TIF_ISOLATE_BP_GUEST);
>>> +
>>>  	vcpu->srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
>>>  
>>>  	if (rc == -EINTR) {
>>>
>>
>> You are trying to optimize the following case here:
> 
> I am trying to fix a case where vsie would allow to disable branch prediction blocking.
>>
>> 1. TIF_ISOLATE_BP_GUEST is not set
>> 2. The guest has facility 82 and enabled FPF_BPBC
> 
> 
>> As the vSIE guest can change its FPF_BPBC, there is basically no
>> guarantee to that. So, when entering/leaving the nested guest, you act
>> like the hardware would be doing FPF_BPBC - as it could be disabled for
>> the nested guest / the nested guest can change the state itself.
> 
> The BPBC is an effective control, so if you enter SIE with bp blocking,
> then the guest will have bp blocking "forced" on.

The guest can at least disable BPBC logically. (you can enable the
control in the SCB but the guest can simply turn it off) - that's why we
sync it back in unshadow_scb().

I now understand it like this:

LPAR (BPBC = on) -> Guest BPBC value ignored
LPAR (BPBC = off) -> Guest BPBC value used
LPAR (BPBC = off) -> Guest (BPBC = off) -> Nested guest value used

And you are fixing this case:
LPAR (BPBC = off) -> Guest (BPBC = on) -> Nested guest ignored

And you do this by setting LPAR (BPBC = on) while running the nested guest.

If so, please add a comment

/*
 * The guest is running with BPBC, so we have to force it on for our
 * nested guest. This is done by enabling BPBC globally, so the BPBC
 * control in the SCB (which the nested guest can modify) is simply
 * ignored.
 */
> 
>>
>> However I wonder what the semantics of FPF_BPBC should be. Shouldn't it
>> be the case that if the guest has enabled FPF_BPBC, that it is forced on
>> for the nested guest? (HW is missing a control to force it on).
> 
> the forcing happens by being an effective control. Imagine it like setting
> the TIF bit will basically turn on FPF_BPBC on the LPAR level before going
> into SIE and the  effective value for guest3 running via vsie as guest2 
> will be that this guest3 can do ppa12/13 as it likes, it will always run
> with bp blocking.
> 



-- 

Thanks,

David / dhildenb

  parent reply	other threads:[~2018-02-14 10:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-14  8:34 [PATCH] KVM: s390: force bp isolation for VSIE Christian Borntraeger
2018-02-14 10:06 ` David Hildenbrand
2018-02-14 10:14   ` Christian Borntraeger
2018-02-14 10:20     ` Christian Borntraeger
2018-02-14 10:37     ` David Hildenbrand [this message]
2018-02-14 11:05       ` Christian Borntraeger
2018-02-14 11:16         ` David Hildenbrand
2018-02-14 11:44         ` Janosch Frank

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2fee7e07-d85f-191a-40c1-42a13704efee@redhat.com \
    --to=david@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=frankja@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox