On 09/12/2012 03:56 AM, Jack Morgenstein wrote: > On the Hypervisor, however, we assume that if both versions of the pkey are in its pkey table, > then for its own infiniband operation (as opposed to performing its pkey virtualizing function), > it should operate with the highest membership type in its table for a given 15-bit pkey. That's what I was looking for. So, how can you know this assumption is correct? It seems to me that if someone wanted to restrict membership of the hypervisor as part of a security lockdown, then give full membership to a guest because that guest is some high security, single task guest, then this assumption would break things (the user would be able to assign the full membership key to the guest OK, but regardless of how they wanted the hypervisor to be subscribed to that particular pkey, it would always get the full membership from the guest). >> Shouldn't we pick the >> pkey that's appropriate for the vHCA sending the message? > > We do. When QPs on the guests are created, the modify-qp commands are not executed on the guest, > but rather are passed to the PPF for processing. The PPF replaces the guest-provided virtual pkey-index > value with the appropriate physical pkey-index value. See procedure "update_pkey_index" in file > resource_tracker.c, and all the places it is called (i.e., in the wrapper functions for the various > modify-qp firmware commands). That's fine for the guest, but I don't see how this solves the assumption issue. My concern is that I could see a valid scenario that a user might want to implement for security reasons that I think makes your assumption above incorrect. -- Doug Ledford GPG KeyID: 0E572FDD http://people.redhat.com/dledford