On Wed, May 23, 2018 at 09:09:28PM +0200, Jiri Denemark wrote:
On Wed, May 23, 2018 at 16:53:37 +0200, Kashyap Chamarthy wrote:
> On Wed, May 23, 2018 at 02:43:23PM +0200, Jiri Denemark wrote:
> > On Wed, May 23, 2018 at 13:08:51 +0200, Kashyap Chamarthy wrote:
> > > On Wed, May 16, 2018 at 10:39:23AM +0200, Jiri Denemark wrote:
> > > > Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
> > > > ---
> > > > tools/virsh.pod | 8 +++++++-
> > > > 1 file changed, 7 insertions(+), 1 deletion(-)
>
> [...]
>
> > > > +Moreover, for some architectures libvirt does not know any CPU
models and
> > > > +the usable CPU models are only limited by the hypervisor.
> > >
> > > Wonder if it is worth adding a small example for the above.
> >
> > An example for what exactly?
>
> I meant an example of a usable CPU model that libvirt doesn't know for
> the said architecture(s). Maybe it's not worth it; not quite sure.
The usable models are all models accepted by hypervisor for that
architecture. So, e.g., libvirt won't list any CPU model for aarch64
when you call "virsh cpu-models aarch64", it will just print "all CPU
models are accepted" and "virsh domcapabilities --arch aarch64" will
show a very long list of CPU models libvirt would actually accept.
Similarly for s390x.
Ah, that is clearer; thank you. So if you think it is worth it, maybe
adjust your doc patch to a variant of the following:
Moreover, for some architectures libvirt does not know any CPU
models and the usable CPU models are only limited by the hypervisor
(e.g. to enumerate a list of acceptable CPU models for AArch64, use
`virsh domcapabilities --arch aarch64`; likewise for 's390x').
--
/kashyap