lkml.org 
[lkml]   [2022]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v12 3/3] KVM: s390: resetting the Topology-Change-Report
From


On 7/13/22 11:01, Janosch Frank wrote:
> On 7/12/22 13:17, Pierre Morel wrote:
>>
>>
>> On 7/12/22 10:47, Janis Schoetterl-Glausch wrote:
>>> On 7/12/22 09:24, Pierre Morel wrote:
>>>>
>>>>

...

>> kernel.
>>
>> In userland we check any wrong selector before the instruction goes back
>> to the guest.
>
> I opt for passing the lower selectors down for QEMU to handle.

OK

>
>>
>>> But that's only relevant if STSI can be extended without a
>>> capability, which is why I asked about that.
>>
>> Logicaly any change, extension, in the architecture should be signaled
>> by a facility bit or something.
>>
>>>
>>>> Even testing the facility or PV in the kernel is for my opinion
>>>> arguable in the case we do not do any treatment in the kernel.
>
> That's actually a good point.
>
> New instruction interceptions for PV will need to be enabled by KVM via
> a switch somewhere since the UV can't rely on the fact that KVM will
> correctly handle it without an enablement.
>
>
> So please remove the pv check

OK

>

...

>>>>>>     +static int kvm_s390_set_topology(struct kvm *kvm, struct
>>>>>> kvm_device_attr *attr)
>>>>>
>>>>> kvm_s390_set_topology_changed maybe?
>>>>> kvm_s390_get_topology_changed below then.
>
> kvm_s390_set_topology_change_indication
>
> It's long but it's rarely used.
> Maybe shorten topology to "topo"

OK
I use
kvm_s390_get_topo_change_indication()


Thanks.

Regards,
Pierre

--
Pierre Morel
IBM Lab Boeblingen

\
 
 \ /
  Last update: 2022-07-14 10:33    [W:0.996 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site