From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWCrL-0000Dt-VQ for qemu-devel@nongnu.org; Mon, 22 Sep 2014 19:17:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWCrE-0006EA-78 for qemu-devel@nongnu.org; Mon, 22 Sep 2014 19:17:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWCrD-0006CU-V5 for qemu-devel@nongnu.org; Mon, 22 Sep 2014 19:17:24 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8MNHHCa011339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 22 Sep 2014 19:17:17 -0400 Message-ID: <5420ADF8.20003@redhat.com> Date: Mon, 22 Sep 2014 19:17:12 -0400 From: John Snow MIME-Version: 1.0 References: <1411063146-24058-1-git-send-email-jsnow@redhat.com> <878ulgq6m2.fsf@blackfin.pond.sub.org> In-Reply-To: <878ulgq6m2.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC v2 0/3] Q35/AHCI -cdrom/-hda desugaring List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org On 09/19/2014 05:53 AM, Markus Armbruster wrote: > John Snow writes: > >> This is an extremely rough/quick sketch of >> a -cdrom/-hda desugaring fix for Q35/AHCI. >> >> Before I spent any time on it, I wanted feedback >> from Markus or anyone else who had concerns about >> how this problem would get fixed. >> >> This is, then, rough approach #2. >> >> Highlights: >> (1) Add a board property (instead of a HBA property, sigh) >> that defines how we should map (index, (bus,unit)). > > Imperfect, but it'll do for now. The place in the boards that sets it > should point to the HBA in a comment. > >> (2) Modify drive_new to accept the MachineClass instead of >> the default interface type. This does not affect how >> default drives get added, because any over-rides to >> the "default type" get handled in options, so while >> it appears we have removed the type of default drives, >> we have not. >> >> (3) Create helpers for AHCI to assist the Q35 board in >> populating the AHCI device with the IDE drives. >> >> (4) Create a helper to whine at us for oversights and >> help bug reporters give us more meaningful information. > > General approach looks good to me; I can see only coding bugs, not > design flaws. > I rewrote this series and was about to send it out, but it does fail the=20 bios-tables-test because this test uses this command line: -net none -display none -machine q35,accel=3Dtcg -drive=20 file=3Dtests/acpi-test-disk.raw,id=3Dhd0 -device ide-hd,drive=3Dhd0, Notice it doesn't say if=3Dnone for the drive, so after fixing Q35, this=20 actually creates a new failure in this test because we will create the=20 drive (and device), then fail when trying to create the second device=20 attached to the same drive. I think this test is at fault, but I wanted to be duly diligent and ask=20 the question: "Is it a big deal if I break backwards compatibility with=20 broken scripts?" --=20 =97js