[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] How do we do user input bitmap properties?
From: |
Andrew Jones |
Subject: |
Re: [Qemu-devel] How do we do user input bitmap properties? |
Date: |
Wed, 15 May 2019 13:42:44 +0200 |
User-agent: |
NeoMutt/20180716 |
On Wed, May 15, 2019 at 12:00:45PM +0100, Dave Martin wrote:
> On Wed, May 15, 2019 at 09:18:54AM +0100, Andrew Jones wrote:
> > On Tue, May 14, 2019 at 04:48:38PM +0200, Igor Mammedov wrote:
> > > On Tue, 14 May 2019 11:02:25 +0200
> > > Andrew Jones <address@hidden> wrote:
> > > > My thought is primarily machines. If a human wants to use the command
> > > > line and SVE, then I'm assuming they'll be happy with sve-max-vq or
> > > > figuring out a map they like once and then sticking to it.
> > >
> > > maybe naive question, but why not use a property/bit as user facing
> > > interface,
> > > in line with what we do with CPUID bits. (that's assuming that bits have
> > > fixed meaning).
> > > Yes, it's verbose but follows current practice and works fine with -cpu
> > > and
> > > -device.
> > > (I really hate custom preprocessing of -cpu and we were working hard to
> > > remove
> > > that in favor of canonical properties at the expense of more verbose CLI).
> > >
> >
> > Are you asking if we should do something like the following?
> >
> > -cpu host,sve1=on,sve=2=on,sve3=off,sve4=on
>
> Note, there is nothing SVE-specific about this.
In the above example there is some specific SVE stuff there. If the
command line has sve4=on, then it must also have sve1=on and sve2=on,
per the architecture requiring all smaller power-of-2 vector lengths.
Only sve3 is optional, but because it's optional we have to explicitly
state when it's on or off in order to ensure we can cleanly fail a
migration to a host that doesn't support that option.
>
> Either enabling features on a per-vcpu basis is justified, or it isn't:
> if it's justified, then it would be better to have a general way of
> specifying per-vcpu properties, rather than it being reinvented per
> feature.
>
> Creating mismatched configurations is allowed by the architecture and so
> it's useful for testing the kernel, but probably less useful for real-
> world use cases today.
>
> So it may be a good idea to get the symmetric support sorted out first
> before thinking about whether and how to specify asymmetric
> configurations.
These properties are per-vcpu for KVM only. QEMU doesn't have a way
to allow per-vcpu features to be described on the command line yet.
With '-cpu host,...' The '...' applies to all vcpus. So we are "just"
working on the symmetric support now.
Thanks,
drew
- Re: [Qemu-devel] How do we do user input bitmap properties?, (continued)
- Re: [Qemu-devel] How do we do user input bitmap properties?, Igor Mammedov, 2019/05/14
- Re: [Qemu-devel] How do we do user input bitmap properties?, Andrew Jones, 2019/05/15
- Re: [Qemu-devel] How do we do user input bitmap properties?, Igor Mammedov, 2019/05/15
- Re: [Qemu-devel] How do we do user input bitmap properties?, Andrew Jones, 2019/05/15
- Re: [Qemu-devel] How do we do user input bitmap properties?, Dave Martin, 2019/05/15
- Re: [Qemu-devel] How do we do user input bitmap properties?, Dr. David Alan Gilbert, 2019/05/15
- Re: [Qemu-devel] How do we do user input bitmap properties?, Dave Martin, 2019/05/15
- Re: [Qemu-devel] How do we do user input bitmap properties?,
Andrew Jones <=
- Re: [Qemu-devel] How do we do user input bitmap properties?, Dave Martin, 2019/05/15
Re: [Qemu-devel] How do we do user input bitmap properties?, Dave Martin, 2019/05/14