Messages in this thread | | | Subject | Re: [PATCH v11 26/26] s390: doc: detailed specifications for AP virtualization | From | Tony Krowiak <> | Date | Thu, 27 Sep 2018 09:12:39 -0400 |
| |
On 09/27/2018 07:59 AM, Christian Borntraeger wrote: > > > On 09/27/2018 01:51 PM, Cornelia Huck wrote: >> On Thu, 27 Sep 2018 13:29:43 +0200 >> Halil Pasic <pasic@linux.ibm.com> wrote: >> >>> On 09/27/2018 12:42 AM, Alex Williamson wrote: >>>> On Tue, 25 Sep 2018 19:16:41 -0400 >>>> Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote: >>>>> + This is how the matrix is configured for Guest2: >>>>> + >>>>> + echo 5 > assign_adapter >>>>> + echo 0x47 > assign_domain >>>>> + echo 0xff > assign_domain >>>>> + >>>>> + This is how the matrix is configured for Guest3: >>>>> + >>>>> + echo 6 > assign_adapter >>>>> + echo 0x47 > assign_domain >>>>> + echo 0xff > assign_domain >>>>> + >>>> >>>> I'm curious why this interface didn't adopt the +/- notation invented >>>> above for consistency. Too difficult to do rollbacks with a string on >>>> entries? >>>> >>> >>> I remember that we did discuss that possibility around v9, but I can't >>> tell why did we decide to not implement it. Maybe Tony has an answer. >> >> IIRC, that was a discussion on the base ap driver interfaces rather >> than vfio-ap. >> >>> >>> Anyway, if we were to do that, we would use different attribute names >>> (e.g. just domain_mask, or something similar instead of >>> (assign|unassign)_xxx). So I think such an interface can still be added >>> on top of the existing one. Having that said having multiple interfaces >>> for the very same thing is usually not so nice IMHO. >> >> Nod to all of your points. >> >> As we do the configuration while the guest is not running anyway, the >> different interfaces probably do not make that much difference in >> practice. It should be fine to stick to the current interface for now >> and only add a new one if we really think it is significantly better. > > Tony, can you maybe provide a quick on-top patch that clarifies Alex > comments regarding the documentation? (State that is is big endian, > fixup the small things etc). > I can then either fold it in or provide it as an on top patch depending > on how much has changed.
Will do.
>
| |