Re: [libvirt] AMD SEV's /dev/sev permissions and probing QEMU for capabilities
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