On 20.11.19 15:04, Eduardo Habkost wrote:
On Wed, Nov 20, 2019 at 11:28:29AM +0100, David Hildenbrand wrote:
On 19.11.19 20:42, Eduardo Habkost wrote:
On Tue, Nov 19, 2019 at 12:00:14PM +0100, David Hildenbrand wrote:
On 19.11.19 11:36, Peter Maydell wrote:
On Tue, 19 Nov 2019 at 09:59, David
On Wed, Nov 20, 2019 at 11:28:29AM +0100, David Hildenbrand wrote:
> On 19.11.19 20:42, Eduardo Habkost wrote:
> > On Tue, Nov 19, 2019 at 12:00:14PM +0100, David Hildenbrand wrote:
> > > On 19.11.19 11:36, Peter Maydell wrote:
> > > > On Tue, 19 Nov 2019 at 09:59, David Hildenbrand
> > > > wrote
On 19.11.19 20:42, Eduardo Habkost wrote:
On Tue, Nov 19, 2019 at 12:00:14PM +0100, David Hildenbrand wrote:
On 19.11.19 11:36, Peter Maydell wrote:
On Tue, 19 Nov 2019 at 09:59, David Hildenbrand wrote:
On 19.11.19 10:22, Peter Maydell wrote:
I don't hugely care about query-cpu-model-expan
On Tue, Nov 19, 2019 at 12:00:14PM +0100, David Hildenbrand wrote:
> On 19.11.19 11:36, Peter Maydell wrote:
> > On Tue, 19 Nov 2019 at 09:59, David Hildenbrand wrote:
> > >
> > > On 19.11.19 10:22, Peter Maydell wrote:
> > > > I don't hugely care about query-cpu-model-expansion. I
> > > > just d
On 19.11.19 11:36, Peter Maydell wrote:
On Tue, 19 Nov 2019 at 09:59, David Hildenbrand wrote:
On 19.11.19 10:22, Peter Maydell wrote:
I don't hugely care about query-cpu-model-expansion. I
just don't want it to have bad effects on the semantics
of user-facing stuff like x- properties.
IMHO
On Tue, 19 Nov 2019 at 09:59, David Hildenbrand wrote:
>
> On 19.11.19 10:22, Peter Maydell wrote:
> > I don't hugely care about query-cpu-model-expansion. I
> > just don't want it to have bad effects on the semantics
> > of user-facing stuff like x- properties.
>
> IMHO, max should really include
On 19.11.19 10:22, Peter Maydell wrote:
On Mon, 18 Nov 2019 at 22:04, Eduardo Habkost wrote:
On Mon, Nov 18, 2019 at 09:19:55PM +, Peter Maydell wrote:
Why should it matter whether a feature is enabled
or disabled by default in the CPU type? It ought to be probeable
by QMP either way (ie
On Mon, 18 Nov 2019 at 22:04, Eduardo Habkost wrote:
>
> On Mon, Nov 18, 2019 at 09:19:55PM +, Peter Maydell wrote:
> > Why should it matter whether a feature is enabled
> > or disabled by default in the CPU type? It ought to be probeable
> > by QMP either way (ie there is a difference between
On Mon, Nov 18, 2019 at 09:19:55PM +, Peter Maydell wrote:
> On Mon, 18 Nov 2019 at 18:49, Eduardo Habkost wrote:
> > Be them experimental or deprecated, we need all features included
> > on "max" if we want to make them usable through libvirt. The
> > fact Peter cares about defaults in "max"
On Mon, 18 Nov 2019 at 18:49, Eduardo Habkost wrote:
> Be them experimental or deprecated, we need all features included
> on "max" if we want to make them usable through libvirt. The
> fact Peter cares about defaults in "max" when used by humans
> indicates we have incompatible definitions of "m
On Mon, Nov 18, 2019 at 11:56:43AM +0100, David Hildenbrand wrote:
> On 18.11.19 11:53, Peter Maydell wrote:
> > On Mon, 18 Nov 2019 at 10:47, David Hildenbrand wrote:
> > > My personal opinion: "max" really means "all features". If we want an
> > > automatic way to specify something you requested
On Mon, 18 Nov 2019 at 10:56, David Hildenbrand wrote:
>
> On 18.11.19 11:53, Peter Maydell wrote:
> > On Mon, 18 Nov 2019 at 10:47, David Hildenbrand wrote:
> >> My personal opinion: "max" really means "all features". If we want an
> >> automatic way to specify something you requested ("give me
On 18.11.19 11:53, Peter Maydell wrote:
On Mon, 18 Nov 2019 at 10:47, David Hildenbrand wrote:
My personal opinion: "max" really means "all features". If we want an
automatic way to specify something you requested ("give me something
that's going to work") we either have to change the definitio
On Mon, 18 Nov 2019 at 10:47, David Hildenbrand wrote:
> My personal opinion: "max" really means "all features". If we want an
> automatic way to specify something you requested ("give me something
> that's going to work") we either have to change the definition of the
> max model for alla rchitec
On 09.11.19 17:07, Peter Maydell wrote:
On Fri, 8 Nov 2019 at 19:11, Eduardo Habkost wrote:
On Fri, Nov 08, 2019 at 01:02:28PM +, Peter Maydell wrote:
On Fri, 8 Nov 2019 at 12:46, David Hildenbrand wrote:
There is a small but important difference between "max"/"host" and
"best". Max rea
On Fri, 8 Nov 2019 at 19:11, Eduardo Habkost wrote:
>
> On Fri, Nov 08, 2019 at 01:02:28PM +, Peter Maydell wrote:
> > On Fri, 8 Nov 2019 at 12:46, David Hildenbrand wrote:
> > > There is a small but important difference between "max"/"host" and
> > > "best". Max really means "all features",
On 08.11.19 20:10, Eduardo Habkost wrote:
On Fri, Nov 08, 2019 at 01:02:28PM +, Peter Maydell wrote:
On Fri, 8 Nov 2019 at 12:46, David Hildenbrand wrote:
There is a small but important difference between "max"/"host" and
"best". Max really means "all features", including deprecated ones.
On Fri, Nov 08, 2019 at 01:02:28PM +, Peter Maydell wrote:
> On Fri, 8 Nov 2019 at 12:46, David Hildenbrand wrote:
> > There is a small but important difference between "max"/"host" and
> > "best". Max really means "all features", including deprecated ones.
> > "best", however, can disable exp
Patchew URL: https://patchew.org/QEMU/20191108110714.7475-1-da...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants
Type: series
Message-id: 20191108110
On Fri, 8 Nov 2019 at 12:46, David Hildenbrand wrote:
> There is a small but important difference between "max"/"host" and
> "best". Max really means "all features", including deprecated ones.
> "best", however, can disable experimental or deprecated features. Or any
> other features we don't want
On 08.11.19 12:10, Peter Maydell wrote:
On Fri, 8 Nov 2019 at 11:08, David Hildenbrand wrote:
There was recently a discussion regarding CPU model versions. That concept
does not fit s390x where we have a lot of feature variability. I
proposed an alternative approach in [1], which might work fo
On Fri, 8 Nov 2019 at 11:08, David Hildenbrand wrote:
>
> There was recently a discussion regarding CPU model versions. That concept
> does not fit s390x where we have a lot of feature variability. I
> proposed an alternative approach in [1], which might work for x86 as well
> (but I am not sure i
There was recently a discussion regarding CPU model versions. That concept
does not fit s390x where we have a lot of feature variability. I
proposed an alternative approach in [1], which might work for x86 as well
(but I am not sure if x86 still can or wants to switch to that), and
requires no real
23 matches
Mail list logo
