On Fri, Mar 15, 2019 at 03:51:57PM +0000, Singh, Brijesh wrote:
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!
Ok, thanks for clarifying.
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].
That's nice!
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>.
Agreed, using CPUID direct from QEMU ought to be sufficient. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|