From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=50041 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OOf8g-0006Xk-E1
	for qemu-devel@nongnu.org; Tue, 15 Jun 2010 19:01:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OOf8T-0002yz-Sr
	for qemu-devel@nongnu.org; Tue, 15 Jun 2010 19:01:39 -0400
Received: from mail.codesourcery.com ([38.113.113.100]:36926)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OOf8T-0002yd-Iu
	for qemu-devel@nongnu.org; Tue, 15 Jun 2010 19:01:37 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
Date: Wed, 16 Jun 2010 00:01:30 +0100
References: <20100614054923.879.33717.stgit@localhost.localdomain>
	<201006152255.48221.paul@codesourcery.com>
	<1276641184.12015.932.camel@x201>
In-Reply-To: <1276641184.12015.932.camel@x201>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201006160001.31205.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: chrisw@redhat.com, kvm@vger.kernel.org, Jan Kiszka <jan.kiszka@siemens.com>, Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org, avi@redhat.com, kraxel@redhat.com

> > I find this argument contradictory. The migration code already needs to
> > check whether a device is compatible before it allows migration.  The
> > driver name is not sufficient to ensure compatibility, so I see no
> > benefit in including it in the device address.
> 
> See my comment above, I'm not seeing a sufficient argument about why
> driver name matching is a false sense of security.  If on an incoming
> migration I'm able to match the source provided e1000.03.0/vmstate
> against the target registered e1000.03.0/vmstate and hand off to the
> e1000 driver to check version ids, you bet I'm feeling a lot more secure
> than if I'm handing off to whatever happened to register 03.0/vmstate on
> the target.

I still say it should be the migration code that checks that both vmstate 
structures are for the same type of device. i.e. if necessary the device name 
should be embedded in the device state, not the device path.

Paul