From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51271)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex.williamson@redhat.com>) id 1aW8GM-0002gZ-Pd
	for qemu-devel@nongnu.org; Wed, 17 Feb 2016 14:59:51 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <alex.williamson@redhat.com>) id 1aW8GL-00074W-Bc
	for qemu-devel@nongnu.org; Wed, 17 Feb 2016 14:59:50 -0500
Date: Wed, 17 Feb 2016 12:59:39 -0700
From: Alex Williamson <alex.williamson@redhat.com>
Message-ID: <20160217125939.6df646dc@t450s.home>
In-Reply-To: <CAFEAcA9UM_XQsd9nnZMnP3nxPwjf6PvW5KB5GdeJK+a29T0f2A@mail.gmail.com>
References: <1454334712-12360-1-git-send-email-eric.auger@linaro.org>
	<CAFEAcA9UM_XQsd9nnZMnP3nxPwjf6PvW5KB5GdeJK+a29T0f2A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v6 0/8] AMD XGBE KVM platform passthrough
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: Peter Maydell <peter.maydell@linaro.org>
Cc: Baptiste Reynal <b.reynal@virtualopensystems.com>, Thomas Huth <thuth@redhat.com>, eric.auger@st.com, Eric Auger <eric.auger@linaro.org>, Patch Tracking <patches@linaro.org>, QEMU Developers <qemu-devel@nongnu.org>, Peter Crosthwaite <crosthwaitepeter@gmail.com>, qemu-arm <qemu-arm@nongnu.org>, Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>, Paolo Bonzini <pbonzini@redhat.com>, thomas.lendacky@amd.com, Alex =?UTF-8?B?QmVubsOpZQ==?= <alex.bennee@linaro.org>, Christoffer Dall <christoffer.dall@linaro.org>, David Gibson <david@gibson.dropbear.id.au>

On Tue, 16 Feb 2016 18:40:47 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 1 February 2016 at 13:51, Eric Auger <eric.auger@linaro.org> wrote:
> > This series allows to set up AMD XGBE passthrough. This was tested on AMD
> > Seattle.
> >
> > The first upstreamed device supporting KVM platform passthrough was the
> > Calxeda Midway XGMAC. Compared to this latter, the XGBE XGMAC exposes a
> > much more complex device tree node.
> >
> > - First There are 2 device tree node formats:
> > one where XGBE and PHY are described in separate nodes and another one
> > that combines both description in a single node (only supported by 4.2
> > onwards kernels). Only the combined description is supported for passthrough,
> > meaning the host must be >= 4.2 and must feature a device tree with a combined
> > description. The guest will also be exposed with a combined description,
> > meaning only >= 4.2 guest are supported. It is not planned to support
> > separate node representation since assignment of the PHY is less
> > straigtforward.
> >
> > - the XGMAC/PHY node depends on 2 clock nodes (DMA and PTP).
> > The code checks those clocks are fixed to make sure they cannot be
> > switched off at some point after the native driver gets unbound.
> >
> > - there are many property values to populate on guest side. Most of them
> > cannot be hardcoded. That series implements host device tree blob extraction
> > from the host /proc/device-tree (inspired from dtc implementation)
> > and retrieve host property values to populate guest dtb.
> >
> > - the case where the host uses ACPI is not yet covered since there is
> >   no usable ACPI description for this HW yet.
> >
> > The patches can be found at
> > https://git.linaro.org/people/eric.auger/qemu.git/shortlog/refs/heads/v2.5.0-xgbe-v6
> >
> > Previous versions can be found at
> > https://git.linaro.org/people/eric.auger/qemu.git/shortlog/refs/heads/v2.5.0-xgbe-v<n>  
> 
> I think you have review on everything in this series now, but I'm assuming
> this is going to go via the vfio tree (or at any rate not via target-arm).
> Let me know if that's wrong.

The little bit of vfio here looks ok to me too.  Eric, this doesn't
apply cleanly, could you please rebase and incorporate all the acks and
reviews and I'll send a pull request with it?  Thanks,

Alex