From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:41293)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <hpa@zytor.com>) id 1UKCNu-0003Ke-2O
	for qemu-devel@nongnu.org; Mon, 25 Mar 2013 14:44:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hpa@zytor.com>) id 1UKCNr-0004hi-AQ
	for qemu-devel@nongnu.org; Mon, 25 Mar 2013 14:44:42 -0400
Received: from terminus.zytor.com ([2001:1868:205::10]:47425
	helo=mail.zytor.com) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <hpa@zytor.com>) id 1UKCNr-0004hD-0x
	for qemu-devel@nongnu.org; Mon, 25 Mar 2013 14:44:39 -0400
Message-ID: <51509B0E.40804@zytor.com>
Date: Mon, 25 Mar 2013 11:44:30 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
MIME-Version: 1.0
References: <1362017554-1260-1-git-send-email-hpa@zytor.com>
	<51501B58.1060300@suse.de>
	<20130325161515.06a2970b@nial.usersys.redhat.com>
In-Reply-To: <20130325161515.06a2970b@nial.usersys.redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486,
 and old486sx CPU models
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Orit Wasserman <owasserm@redhat.com>, Eduardo Habkost <ehabkost@redhat.com>, =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>, Anthony Liguori <anthony@codemonkey.ws>, qemu-devel@nongnu.org

On 03/25/2013 08:15 AM, Igor Mammedov wrote:
>>
>> Such changes have been rejected in the past (e.g., n270 Atom).
>> I personally wouldn't object to 486 changes, but I guess it should
>> rather be handled via Igor's CPU static properties that I have in my
>> review queue: The .model value would be set to 8 but the PC machine
>> would be changed alongside to set model = 0 for pc-1.4 and earlier.
> It doesn't relates to property refactoring nor to slim CPU sub-classes
> conversion either. So it could go in independently.
> 
> But is this change safe from migration POV?
> 

Well, given that the CPU model presented is actually closer to a model 8
than a model 0 it probably is... but the real question is what would
cause someone to do migration of a 486 CPU model.

The n270 issue is problematic, because right now "n270" can't actually
run software compiled for N270...

	-hpa