Isaku Yamahata wrote:
Our justification is as follows. The difference is its scope. pv_ops for virtualization and machine vector is for platform difference. - pv_ops does cover the area which shouldn't belong to machine vector. For example, ia64 intrinsics paravirtualization. It shouldn't belong to the machine vector. It must be initialized very early before platform detection.
Hi Isaku, Ok this is a good point.
- pv_ops covers some performance critical part (e.g. ia64 intrinsics) so that in the future they should be optimized with binary patch like x86. We had the experimental patch to do that, but they are dropped for the merge. It reduced patch size greatly. After merging the first patch series, we're planning to optimize pv_ops with binary patch. The optimization with binary patch is out of the machine vector scope.
Rather than making these binary patches, why not make them fast syscalls and using a vdso page. Some of the priviledged instructions are simply reads and we could have that information in a read-only data page, so there is no need to do a context switch at all. Others could benefit from a fast system call that doesn't do a full context switch. It would be nice if we could come up with a generic implementation for such a vdso style interface that could be shared between xen/kvm/lguest.
- The current pv_ops implements only one for only domU, but in future pv_ops will support dom0. It means dom0 linux would run with the underlying machine vector + pv_ops, i.e. {dig, hpzx1, hpzx1_swiotlb, ...} machine vector + xen pv_ops Probably some hooks of pv_ops could be replaced with enhancing machine vector. But from the above separating pv_ops from machine vector looks reasonable.
Would it make sense to make the pv_ops pointer part of the machine vector? Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |