[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] AMD SEV's /dev/sev permissions and probing QEMU for cap
From: |
Daniel P . Berrangé |
Subject: |
Re: [Qemu-devel] AMD SEV's /dev/sev permissions and probing QEMU for capabilities |
Date: |
Fri, 15 Mar 2019 12:18:57 +0000 |
User-agent: |
Mutt/1.11.3 (2019-02-01) |
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 ?
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.
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.
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
--
|: 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 :|
- Re: [Qemu-devel] AMD SEV's /dev/sev permissions and probing QEMU for capabilities,
Daniel P . Berrangé <=