From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40337)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1UwrXy-0003Gx-VV
	for qemu-devel@nongnu.org; Wed, 10 Jul 2013 06:23:02 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1UwrXs-0000lw-UQ
	for qemu-devel@nongnu.org; Wed, 10 Jul 2013 06:22:54 -0400
Received: from mx1.redhat.com ([209.132.183.28]:3881)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1UwrXs-0000lo-NR
	for qemu-devel@nongnu.org; Wed, 10 Jul 2013 06:22:48 -0400
Date: Wed, 10 Jul 2013 13:23:55 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20130710102355.GB10203@redhat.com>
References: <20130603163305.GC4094@irqsave.net>
	<1370282529.30975.344.camel@ul30vt.home>
	<51ACE1B5.2050102@redhat.com>
	<1370285865.30975.361.camel@ul30vt.home>
	<20130604155030.GA5991@irqsave.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <20130604155030.GA5991@irqsave.net>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] VFIO and scheduled SR-IOV cards
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: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@irqsave.net>
Cc: Alex Williamson <alex.williamson@redhat.com>, Don Dutile <ddutile@redhat.com>, iommu@lists.linux-foundation.org, qemu-devel@nongnu.org

On Tue, Jun 04, 2013 at 05:50:30PM +0200, Beno=EEt Canet wrote:
>=20
> Hello,
>=20
> More informations on how the hardware works.
>=20
> -Each VF will have its own memory and MMR, etc.
> That means the resources are not shared.
>=20
> -Each VF will have its own bus number, function number and device numbe=
r.
> That means request ID is separated for each VF.
>=20
> There is also VF save/restore area for the switch.
>=20
> A VF regular memory (not MMR) is still accessible after a switch out.
>=20
> But when a function VF1 is scheduled a read to a MRR of VF number 0 cou=
ld return
> the value of the same MMR in VF number 1 because VF number 1 is switche=
d on and
> the PF processor is busy servicing VF number 1.
>=20
> This could confuse the guest VF driver so the unmap and block or a same=
 goal
> achieving technique is required.
>=20
> I hope these informations makes the area of the problem to solve narrow=
er.
>=20
> Best regards
>=20
> Beno=EEt Canet

Confused.
You have one VF accessing BAR of another VF?
Why?

--=20
MST