On 2/21/2017 10:23 AM, Auger Eric wrote: >> Note that the goal is to be able to instantiate any platform device by just >> passing a compatible string and the object from the host. We don't want >> to make changes to QEMU every time somebody comes up with a new platform >> device. >> This step is unnecessary. > Well we need to generate a device tree node for your device. We have not > proven yet the function that creates this latter can be generic. There > are some helpers that can read the host dt node, copy some properties > from the host to the guest. But still at the moment we can't make things > as generic as PCIe and this is why the platform passthrough still is > controversial. So this patch aims at lowering the integration efforts > but minimal specialization needs to be done in sysbus-fdt. Same on > kernel side with the reset module.
Understood. You need to bring in the entire device tree parameters for a full-blown solution. We can always treat this as a TODO. I was more interested in simple devices like XHCI, AHCI, HIDMA where there is no platform device attribute besides the interrupt number and memory resources. QEMU already has access to these. I was hoping to cover this at least. More complex objects need their own implementation like the AMD driver in your example. I'm pasting my comment from the archives here. https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg03267.html "Why submit a new SATA AHCI driver for QEMU just to set the compat string?" > > Thanks > > Eric > > -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
