Re: [PATCH v2 05/13] s390x: protvirt: Add pv state to cpu env

[David Hildenbrand <david@redhat.com>]

On 06.12.19 10:50, Janosch Frank wrote:
> On 11/29/19 11:30 AM, David Hildenbrand wrote:
>> On 29.11.19 10:48, Janosch Frank wrote:
>>> We need to know if we run in pv state or not when emulating
>>> instructions.
>>>
>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>>> ---
>>>  hw/s390x/s390-virtio-ccw.c | 2 ++
>>>  target/s390x/cpu.h         | 1 +
>>>  2 files changed, 3 insertions(+)
>>>
>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>> index e2a302398d..6fcd695b81 100644
>>> --- a/hw/s390x/s390-virtio-ccw.c
>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>> @@ -357,6 +357,7 @@ static void s390_machine_reset(MachineState *machine)
>>>                  s390_pv_vcpu_destroy(t);
>>>              }
>>>              s390_pv_vm_destroy();
>>> +            env->pv = false;
>>>          }
>>>  
>>>          qemu_devices_reset();
>>> @@ -406,6 +407,7 @@ static void s390_machine_reset(MachineState *machine)
>>>          s390_ipl_pv_unpack();
>>>          /* Verify integrity */
>>>          s390_pv_verify();
>>> +        env->pv = true;
>>>          s390_cpu_set_state(S390_CPU_STATE_OPERATING, cpu);
>>>          break;
>>>      default:
>>> diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
>>> index d2af13b345..43e6c286d2 100644
>>> --- a/target/s390x/cpu.h
>>> +++ b/target/s390x/cpu.h
>>> @@ -116,6 +116,7 @@ struct CPUS390XState {
>>>  
>>>      /* Fields up to this point are cleared by a CPU reset */
>>>      struct {} end_reset_fields;
>>> +    bool pv; /* protected virtualization */
>>
>> so ... the preceding patches fail to compile?
>>
>> Please properly squash that ...
>>
> 
> As it turns out, this patch doesn't really support multiple cpus, since
> we only mark the ipl cpu as protected. We also need to mark all others
> (we can do that in the create cpu call) and have a machine flag, so we
> also mark hotplug cpus.

Setting a machine state flag when enabling/disabling prot feels right.
But not sure about the performance implications when always having to
look up the machine state ... maybe you have to cache it in all CPUs, or
somewhere else ("global variable").

> 
> I need to think about that a bit more.
> 


-- 
Thanks,

David / dhildenb