> > If I understanding correctly then you are recommending that instead of
> > exporting various functions from PSP drv we should expose one function
> > for the all the guest command handling (something like this).
> >
> > My understanding is that a user could exhaust the ASIDs for encrypted
> >
Hi Paolo,
On 10/17/2016 03:14 PM, Paolo Bonzini wrote:
I am not sure if I fully understand this feedback. Let me summaries what
we have right now.
At highest level SEV key management commands are divided into two sections:
- platform management : commands used during platform provisioning.
> I am not sure if I fully understand this feedback. Let me summaries what
> we have right now.
>
> At highest level SEV key management commands are divided into two sections:
>
> - platform management : commands used during platform provisioning. PSP
> drv provides ioctl's for these commands.
Hi Paolo,
On 10/13/2016 05:45 AM, Paolo Bonzini wrote:
On 23/08/2016 01:28, Brijesh Singh wrote:
The ioctl will be used by qemu to issue the Secure Encrypted
Virtualization (SEV) guest commands to transition a guest into
into SEV-enabled mode.
a typical usage:
struct kvm_sev_launch_start
On 23/08/2016 01:28, Brijesh Singh wrote:
> The ioctl will be used by qemu to issue the Secure Encrypted
> Virtualization (SEV) guest commands to transition a guest into
> into SEV-enabled mode.
>
> a typical usage:
>
> struct kvm_sev_launch_start start;
> struct kvm_sev_issue_cmd data;
>
>
The ioctl will be used by qemu to issue the Secure Encrypted
Virtualization (SEV) guest commands to transition a guest into
into SEV-enabled mode.
a typical usage:
struct kvm_sev_launch_start start;
struct kvm_sev_issue_cmd data;
data.cmd = KVM_SEV_LAUNCH_START;
data.opaque =
ret = ioctl(fd,
