lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 6 Jun 2018 10:24:34 -0400
From:   Tony Krowiak <akrowiak@...ux.vnet.ibm.com>
To:     pmorel@...ux.ibm.com, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc:     freude@...ibm.com, schwidefsky@...ibm.com,
        heiko.carstens@...ibm.com, borntraeger@...ibm.com,
        cohuck@...hat.com, kwankhede@...dia.com,
        bjsdjshi@...ux.vnet.ibm.com, pbonzini@...hat.com,
        alex.williamson@...hat.com, pmorel@...ux.vnet.ibm.com,
        alifm@...ux.vnet.ibm.com, mjrosato@...ux.vnet.ibm.com,
        jjherne@...ux.vnet.ibm.com, thuth@...hat.com,
        pasic@...ux.vnet.ibm.com, berrange@...hat.com,
        fiuczy@...ux.vnet.ibm.com, buendgen@...ibm.com
Subject: Re: [PATCH v5 10/13] s390: vfio-ap: sysfs interface to view matrix
 mdev matrix

On 06/05/2018 08:40 AM, Pierre Morel wrote:
> On 30/05/2018 16:28, Tony Krowiak wrote:
>> On 05/24/2018 05:10 AM, Pierre Morel wrote:
>>> On 23/05/2018 16:38, Tony Krowiak wrote:
>>>> On 05/16/2018 03:55 AM, Pierre Morel wrote:
>>>>> On 07/05/2018 17:11, Tony Krowiak wrote:
>>>>>> Provides a sysfs interface to view the AP matrix configured for the
>>>>>> mediated matrix device.
>>>>>>
>>>>>> The relevant sysfs structures are:
>>>>>>
>>>>>> /sys/devices/vfio_ap
>>>>>> ... [matrix]
>>>>>> ...... [mdev_supported_types]
>>>>>> ......... [vfio_ap-passthrough]
>>>>>> ............ [devices]
>>>>>> ...............[$uuid]
>>>>>> .................. matrix
>>>>>>
>>>>>> To view the matrix configured for the mediated matrix device,
>>>>>> print the matrix file:
>>>>>
>>>>> This is the configured matrix, not the one used by the guest.
>>>>> Nothing in the patches protect against binding a queue and assigning
>>>>> a new AP when the guest runs.
>>>>> The card and queue will be showed by this entry.
>>>>
>>>> Of course, as stated above, this is the matrix configured for the
>>>> mediated matrix device. Are you suggesting here that the driver
>>>> should prevent assigning a new adapter or domain while a guest is
>>>> running? Couldn't this be a step in the process for hot (un)plugging
>>>> AP queues?
>>>
>>> No, I mean what is the point to show this?
>>> It is not what the guest sees.
>>> Has it any use case?
>>
>> The point is to display the matrix so one can view the AP queues that
>> have been assigned to the mediated matrix device. This is the only way
>> to view the matrix. Do you not find value in being able to see what
>> has been assigned to the mediated matrix device?
>
> Two things:
> 1) I think it is better to retrieve the individual masks

I am not certain what you mean by this. Are you suggesting we display the
actual mask? For example, the APM:

08000000000000001000000000000c0000000030000000000800000000000001

If that is the case, I completely disagree as that would be worthless from
a user perspective. Trying to figure out which APs are configured would be
ridiculously complicated.

Or, are you suggesting something like this:

4,67,116,117,154,155,255

Personally, I found viewing the queues to be much more valuable when
configuring the mediated device's matrix. I originally displayed the
individual adapter and domain attributes and found it cumbersome to
mentally configure what the matrix looked like. If you think of the
lszcrypt command, it outputs the adapters and queues which is the model
I used for this.

> 2) As I said above, what you show is not the effective mask used by 
> the guest

Why would a sysfs attribute for the mediated matrix device show the 
effective
mask used by the guest?

>
>
>
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ