[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [PATCH v8 3/6] s390x/kvm: enable/disable AP instruction

From: David Hildenbrand
Subject: Re: [qemu-s390x] [PATCH v8 3/6] s390x/kvm: enable/disable AP instruction interpretation for guest
Date: Wed, 19 Sep 2018 09:53:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

Am 19.09.18 um 00:23 schrieb Halil Pasic:
> On 09/18/2018 06:59 PM, Tony Krowiak wrote:
>> I've discussed this with Halil -- Pierre is out until next week. We
>> are in agreement that while these changes are viable, they result in
>> a slightly more complicated implementation compared to previous versions 
>> (e.g.
>> kernel v9 QEMU v7), and locks us into a model that may limit design choices
>> down the road if/when virtual and/or emulated AP devices are implemented.
> Just want to confirm, that I did slightly change my mind compared to some 
> weeks
> ago regarding the introducing the dynamic toggle in this stage. Back then I 
> was
> like it's good, because it makes the interface complete. After thinking some
> more, it appears to me alone it does not buy us (or userspace) a thing. If
> userspace wants to emulate the ap instructions in the first place it can just
> clear away the KVM_S390_VM_CPU_FEAT_AP bit (if offered) before applying the 
> cpu
> model. And I can't think of an situation where dynamically switching one way 
> or
> the other would make sense without additional kernel interfaces.

The main point is: QEMU does at that stage not know which device will
get plugged. Is it a vfio-ap device? Is it an emulated ap device? If
there is a dynamic toggle, that can simply be switched when said device
is hotplugged (and with no devices, we can for now always rely on the
kernel doing it by enabling apie).

We can enforce in QEMU all-emulated or all-vfio.

Am I missing something?

Having that said, I already asked too many dumb questions regarding to
AP and learned a lot. I am happy with the CPU model part. If you both
think that this interface is the way to go, I will not object. (merely
leave that to Christian and Frank, but I assume they will rely on the
hard work of all of you).

I will respond with my thought about the interface to Tonys mail.



David / dhildenb

reply via email to

[Prev in Thread] Current Thread [Next in Thread]