On Thursday, December 19, 2013 1:54:51 pm Roger Pau Monne wrote: > Since Xen PVH guests doesn't have ACPI, we need to create a dummy > pvcpu device that will be used to fill the pcpu->pc_device field. Rather than have this hang directly off of nexus0, it might be better to create some sort of 'xenov0' device that takes the place of acpi0 and have the CPUs hang off of that. This is how the non-ACPI case works in the native case where the default nexus creates a 'legacy0' device that sits at the same spot in the device tree as acpi0. In sys/x86/legacy.c we create CPU devices that are a child of legacy0. In general the way the native code handes ACPI vs non-ACPI is to have a different nexus (as you've adopted) create a specific child bus (acpi0 vs legacy0). Drivers that want to only attach in one of the cases at the top- level then attach as children of those rather than children of 'nexus0'. This just adds an extra layer of protection to avoid the possibility of a top-level driver that is ACPI or non-ACPI specific being probed in the "wrong" case. Right now, all drivers that attach to 'nexus' aside from the top-level busses (acpi0 vs legacy0) are intended to work on any machine. I think the CPU driver itself looks fine, I would just encourage you to consider a xenpv0 device and to move anything PV specific to hang off of that rather than directly attaching to nexus0. -- John BaldwinReceived on Tue Dec 24 2013 - 14:51:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:45 UTC