[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interce
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception |
Date: |
Mon, 9 Apr 2018 12:51:04 +0200 |
On Mon, 9 Apr 2018 12:37:42 +0200
Halil Pasic <address@hidden> wrote:
> On 04/09/2018 11:32 AM, Cornelia Huck wrote:
> >> We can kind of (i.e. modulo EECA.28) ensure this in a different fashion I
> >> think. How
> >> about proclaiming a 'has ap instructions, but nothing to see here' in the
> >> SIE interpreted flavor (ECA.28 set) the default way of having ap
> >> instructions
> >> under KVM. This should be easily accomplished with an all zero CRYCB and
> >> eca.28
> >> set. The for the guest to actually get real work done with AP we would
> >> still require some sort of driver to either provide a non-zero matrix by
> >> altering the CRYCB or unsettling ECA.28 and doing the intercepted flavor.
> >>
> >> Please notice, the cpu facility ap would still keep it's semantic
> >> 'has ap instructions' (opposed to 'has ap instructions implemented in
> >> SIE interpreted flavor). And give us all the flexibility.
> >>
> >> Yet implementing what we want to have in absence of a driver would become
> >> much easier (under the assumption that ECA.28 equals EECA.28).
> >>
> >> How about this?
> > Unfortunately, this is really hard to follow without the AR... let me
> > summarize it to check whether I got the gist of it :)
> >
> > - If the "ap" cpu feature is specified, set a bit that indicates "hey,
> > we basically have have AP support" and create the basics, but don't
> > enable actual SIE handling. This means the guest gets exceptions from
> > the SIE already and we don't need to emulate them.
>
> Kind of. The bit is ECA.28 and tells SIE 'hey SIE shall interpret ap
> instructions for the guest (as specified)'. Then SIE has an SD satellite
> called CRYCB that contains the which ap resources is the guest authorized
> to use. These are the masks. If we set each mask to all zero, we will
> effectively accomplish 'hey,we basically have have AP support but no
> resources at the moment'. So, right, we don't have to emulate that.
>
> I don't know what do you mean by exceptions. For most legit requests the
> SIE should say APQN invalid, with QCI being a notable exception. But
> of course SIE would inject program exceptions (access, specification,
> and privileged operation) accordingly I guess.
I meant "emulate exceptions"...
>
>
> In short, the SIE would do what we are trying to emulate in this patch.
...so yes, exactly that.
>
> > - Actually enable the missing pieces if a vfio device is created. This
> > would enable processing by the SIE, and we would not need to do
> > emulation, either (for most of it, IIRC).
>
> Yes. It would actually assign resources to the guest. That would enable
> doing real work with the AP instructions.
Ok.
>
> >
> > I may be all wrong, though... can we at least have a translation of
> > ECA.28 and EECA.28 (the "ap is there" bit and the "ap instructions are
> > interpreted" bit?)
> >
>
> I think we have a misunderstanding here. I will wait for Tony. Maybe
> he can understand this better or explain in more accessible way.
From what I get from your explanation, this approach sounds like a good
way forward. But let's wait for Tony.
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, (continued)
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Tony Krowiak, 2018/04/05
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Halil Pasic, 2018/04/05
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Cornelia Huck, 2018/04/06
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, David Hildenbrand, 2018/04/06
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Halil Pasic, 2018/04/06
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Halil Pasic, 2018/04/06
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Daniel P . Berrangé, 2018/04/06
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Halil Pasic, 2018/04/06
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Cornelia Huck, 2018/04/09
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Halil Pasic, 2018/04/09
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception,
Cornelia Huck <=
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Tony Krowiak, 2018/04/11
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Halil Pasic, 2018/04/11
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Tony Krowiak, 2018/04/12
- Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Tony Krowiak, 2018/04/12
Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Pierre Morel, 2018/04/04
Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Tony Krowiak, 2018/04/04
Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Pierre Morel, 2018/04/04
Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, Tony Krowiak, 2018/04/04