On Thu, Oct 12, 2017 at 04:52:32PM -0500, Brijesh Singh wrote:
> See my above comment, I think the simplest solution is remove psp->sev_misc
Ok, so far so good.
But now you still need to track which is the last psp device and to call
misc_deregister() only when the last device exits. Because if
On Thu, Oct 12, 2017 at 04:52:32PM -0500, Brijesh Singh wrote:
> See my above comment, I think the simplest solution is remove psp->sev_misc
Ok, so far so good.
But now you still need to track which is the last psp device and to call
misc_deregister() only when the last device exits. Because if
On 10/12/17 4:41 PM, Borislav Petkov wrote:
> On Thu, Oct 12, 2017 at 04:11:18PM -0500, Brijesh Singh wrote:
>> The sev_exit() will be called for all the psp_device instance. we need
>> to set psp_misc_dev = NULL after deregistering the device.
>>
>> if (psp_misc_dev) {
>>
On 10/12/17 4:41 PM, Borislav Petkov wrote:
> On Thu, Oct 12, 2017 at 04:11:18PM -0500, Brijesh Singh wrote:
>> The sev_exit() will be called for all the psp_device instance. we need
>> to set psp_misc_dev = NULL after deregistering the device.
>>
>> if (psp_misc_dev) {
>>
On Thu, Oct 12, 2017 at 04:11:18PM -0500, Brijesh Singh wrote:
> The sev_exit() will be called for all the psp_device instance. we need
> to set psp_misc_dev = NULL after deregistering the device.
>
> if (psp_misc_dev) {
> misc_deregister(psp_misc_dev);
> psp_misc_dev = NULL;
Right, except
On Thu, Oct 12, 2017 at 04:11:18PM -0500, Brijesh Singh wrote:
> The sev_exit() will be called for all the psp_device instance. we need
> to set psp_misc_dev = NULL after deregistering the device.
>
> if (psp_misc_dev) {
> misc_deregister(psp_misc_dev);
> psp_misc_dev = NULL;
Right, except
On 10/12/17 9:08 AM, Borislav Petkov wrote:
...
> Well, if you're going to have a global var, why not pull up the misc
> device instead?
>
> And mind you, I've moved out this assignments:
>
> + psp->sev_misc = psp_misc_dev;
> + init_waitqueue_head(>sev_int_queue);
> +
On 10/12/17 9:08 AM, Borislav Petkov wrote:
...
> Well, if you're going to have a global var, why not pull up the misc
> device instead?
>
> And mind you, I've moved out this assignments:
>
> + psp->sev_misc = psp_misc_dev;
> + init_waitqueue_head(>sev_int_queue);
> +
On 10/12/17 1:21 PM, Borislav Petkov wrote:
.
> Btw, that function returns 0 unconditionally. So you can make it return
> void and...
Will do
>> +if (ret)
>> +goto unlock;
> ... remove this check and initialize ret to 0 at the beginning.
>
Will do
On 10/12/17 1:21 PM, Borislav Petkov wrote:
.
> Btw, that function returns 0 unconditionally. So you can make it return
> void and...
Will do
>> +if (ret)
>> +goto unlock;
> ... remove this check and initialize ret to 0 at the beginning.
>
Will do
On Wed, Oct 11, 2017 at 11:50:30AM -0500, Brijesh Singh wrote:
> +static int sev_do_cmd(int cmd, void *data, int *psp_ret)
> +{
> + unsigned int phys_lsb, phys_msb;
> + struct psp_device *psp;
> + unsigned int reg, ret;
> + struct sp_device *sp;
> +
> + sp =
On Wed, Oct 11, 2017 at 11:50:30AM -0500, Brijesh Singh wrote:
> +static int sev_do_cmd(int cmd, void *data, int *psp_ret)
> +{
> + unsigned int phys_lsb, phys_msb;
> + struct psp_device *psp;
> + unsigned int reg, ret;
> + struct sp_device *sp;
> +
> + sp =
On Wed, Oct 11, 2017 at 11:50:30AM -0500, Brijesh Singh wrote:
> AMD's new Secure Encrypted Virtualization (SEV) feature allows the
> memory contents of virtual machines to be transparently encrypted with a
> key unique to the VM. The programming and management of the encryption
> keys are handled
On Wed, Oct 11, 2017 at 11:50:30AM -0500, Brijesh Singh wrote:
> AMD's new Secure Encrypted Virtualization (SEV) feature allows the
> memory contents of virtual machines to be transparently encrypted with a
> key unique to the VM. The programming and management of the encryption
> keys are handled
AMD's new Secure Encrypted Virtualization (SEV) feature allows the
memory contents of virtual machines to be transparently encrypted with a
key unique to the VM. The programming and management of the encryption
keys are handled by the AMD Secure Processor (AMD-SP) which exposes the
commands for
AMD's new Secure Encrypted Virtualization (SEV) feature allows the
memory contents of virtual machines to be transparently encrypted with a
key unique to the VM. The programming and management of the encryption
keys are handled by the AMD Secure Processor (AMD-SP) which exposes the
commands for
16 matches
Mail list logo
