[libvirt] AMD SEV's /dev/sev permissions and probing QEMU for capabilities

[Singh, Brijesh]

Hi Daniel,


On 3/15/19 7:18 AM, Daniel P. Berrangé wrote:
> On Fri, Jan 18, 2019 at 12:51:50PM +0000, Singh, Brijesh wrote:
>>
>> On 1/18/19 3:39 AM, Erik Skultety wrote:
>>> I proceeded with cloning [1] to systemd and creating an udev rule that I planned
>>> on submitting to systemd upstream - the initial idea was to mimic /dev/kvm and
>>> make it world accessible to which Brijesh from AMD expressed a concern that
>>> regular users might deplete the resources (limit on the number of guests
>>> allowed by the platform).
> 
> [snip]
> 
>>> But since the limit is claimed to be around 4, Dan
>>
>>
>> FYI, the limit on EPYC is 15.
> 
> Do any cRyzen CPUs support SEV, and if so is their limit also 15 ?
> 

SEV support is *not* available on any of Ryzen's yet!


> Regardless, I'm assuming this limit is liable to change at any time
> in future CPU generations, so from the the mgmt app perspective I
> think is is important that QEMU / libvirt can both report what this
> limit is.
> 

Yes, the limit may change on future CPU generations. We can query the
limit through the CPUID Fn0x8000_001f[ECX].


> For QEMU I think query-sev-capabilities probably should report the
> guest limit.  I guess QEMU would in turn want to ask the kernel,
> rather than hardcode info itself. So if this info isn't already
> exposed by the kernel we might need work there too.
> 


I don't think we need to add a kernel interface for querying this
information, it can be obtained using the cpuid instruction or
access its via /dev/cpuid/<cpu>.


> For libvirt we can then put this in the domain capabilities where
> we report SEV support.
>  > This will enable OpenStack and similar apps to plan which host they
> place a new VM on, to ensure there is SEV resource available for it
> to use.
> 
> Regards,
> Daniel
>