Hi, On 02/17/2016 08:59 PM, Alex Williamson wrote: > On Tue, 16 Feb 2016 18:40:47 +0000 > Peter Maydell <peter.mayd...@linaro.org> wrote: > >> On 1 February 2016 at 13:51, Eric Auger <eric.au...@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,
Thanks Peter for the last R-b's. Alex, I rebased and sent v7. Once pulled I will update the qemu wiki. Thanks Eric > > Alex >
