From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfuZT-00071O-Nn for qemu-devel@nongnu.org; Tue, 04 Dec 2012 10:38:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TfuZM-0002MZ-Ld for qemu-devel@nongnu.org; Tue, 04 Dec 2012 10:38:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfuZM-0002MO-Co for qemu-devel@nongnu.org; Tue, 04 Dec 2012 10:38:00 -0500 Message-ID: <50BE18CF.7070704@redhat.com> Date: Tue, 04 Dec 2012 16:37:51 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <1354529518-25534-1-git-send-email-kraxel@redhat.com> <20121203184704.GC20489@redhat.com> <50BDA8EB.5090402@redhat.com> <20121204143725.GA11368@redhat.com> In-Reply-To: <20121204143725.GA11368@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL for-1.3 0/3] seabios: q35 update List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Baron Cc: Jan Kiszka , somlo@cmu.edu, qemu-devel@nongnu.org, anthony@codemonkey.ws Hi, >>> '-machine q35,diskmode=ahci,ide,raid'? >> >> I'm wondering whenever we want to deal with that at all? >> >> "If your guest is too old to handle ahci natively, just stick to piix." >> is a sensible policy IMHO. >> > > There was some discussion of trying to make q35 the default for 1.4, in > which case it may be important to support older OS's such as WinXP. > > Anthony, do you have any opinion on this? The fundamental issue is that you have either good compatibility (makes old guests happy) or good performance (makes modern guests happy) by default. Picking a default which makes everybody happy is impossible. That problem doesn't change no matter whenever the choice is piix vs. q35 or q35+ide vs. q35+ahci. management apps (using libosinfo) can tackle this in a sensible manner by picking virtual hardware depending on the guest capabilities. So I wouldn't worry too much on qemu level. >>> 2) HPET ACPI error >>> >>> This line: 'IRQNoFlags () {2, 8}' in the HPET acpi table is causing the >>> folloing ACPI message (removing it makes it go away): >> >> Hmm. That was added to make macos x happy and is also present on real >> hardware, so I'm wondering what is going on here. >> > > I also noticed that on Windows 7, the 'IRQNoFlags' line above makes the RTC > clock complain that it does not have resources available. While removing the > above line, removes that error. Hmm. The IRQNoFlags for the RTC isn't new though, but I can see that with win7 on piix too. cheers, Gerd