From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZanp-0000Fc-E1 for qemu-devel@nongnu.org; Thu, 02 Oct 2014 03:27:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZanj-0003Mo-GE for qemu-devel@nongnu.org; Thu, 02 Oct 2014 03:27:53 -0400 Received: from thoth.sbs.de ([192.35.17.2]:51424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZanj-0003L6-5w for qemu-devel@nongnu.org; Thu, 02 Oct 2014 03:27:47 -0400 Message-ID: <542CFE6D.9090707@siemens.com> Date: Thu, 02 Oct 2014 09:27:41 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <592b4a2a2b00e21470bec1a2ecf259a64eb285b2.1406703720.git.jan.kiszka@siemens.com> <20140730085732.GA14263@redhat.com> <53D8B6B4.5070302@redhat.com> <87a97rnlfb.fsf@blackfin.pond.sub.org> <20140902151125.16792.32360@loki> In-Reply-To: <20140902151125.16792.32360@loki> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/3] pc: Fix disabling of vapic for compat PC models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth , Markus Armbruster , Paolo Bonzini Cc: qemu-devel , "Michael S. Tsirkin" On 2014-09-02 17:11, Michael Roth wrote: > Quoting Markus Armbruster (2014-07-30 06:19:36) >> Paolo Bonzini writes: >> >>> Il 30/07/2014 10:57, Michael S. Tsirkin ha scritto: >>>> On Wed, Jul 30, 2014 at 09:01:59AM +0200, Jan Kiszka wrote: >>>>> We used to be able to address both the QEMU and the KVM APIC via "apic". >>>>> This doesn't work anymore. So we need to use their parent class to turn >>>>> off the vapic on machines that should not expose them. >>>>> >>>>> Signed-off-by: Jan Kiszka >>>> >>>> >>>> >>>> OK so this is intended for 2.2? >> >> If yes, we should cc: qemu-stable. > > Ping for stable 2.1.1, freeze is on Wednesday Lost track of this: was I supposed to provide anything different, or did this just fall under the table? Jan > >> >>>> In that case, how about creating a macro with type name, >>>> and using that? This way things don't break if we rename >>>> something again. >>> >>> Don't we have warnings for that now? >> >> Warnings don't help much in cases like this: "apic" still exists and has >> the property, it's just not the device we want. Macros aren't >> foolproof, either. >> >>>>> --- >>>>> hw/i386/pc_piix.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c >>>>> index 9694f88..73ba77d 100644 >>>>> --- a/hw/i386/pc_piix.c >>>>> +++ b/hw/i386/pc_piix.c >>>>> @@ -645,7 +645,7 @@ static QEMUMachine pc_machine_v1_1 = { >>>>> .property = "class",\ >>>>> .value = stringify(PCI_CLASS_MEMORY_RAM),\ >>>>> },{\ >>>>> - .driver = "apic",\ >>>>> + .driver = "apic-common",\ >>>>> .property = "vapic",\ >>>>> .value = "off",\ >>>>> },{\ >>>>> -- >>>>> 1.8.1.1.298.ge7eed54 >> >> You could use TYPE_APIC_COMMON here. Including >> "hw/i386/apic_internal.h" for it would be not so nice, though. > -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux