On Tue, Oct 30, 2012 at 11:39:32AM +0200, Avi Kivity wrote: > On 10/29/2012 08:40 PM, Marcelo Tosatti wrote: > > On Mon, Oct 29, 2012 at 10:44:41AM -0700, Jeremy Fitzhardinge wrote: > >> On 10/29/2012 07:45 AM, Glauber Costa wrote: > >> > On 10/24/2012 05:13 PM, Marcelo Tosatti wrote: > >> >> Allow a guest to register a second location for the VCPU time info > >> >> > >> >> structure for each vcpu (as described by MSR_KVM_SYSTEM_TIME_NEW). > >> >> This is intended to allow the guest kernel to map this information > >> >> into a usermode accessible page, so that usermode can efficiently > >> >> calculate system time from the TSC without having to make a syscall. > >> >> > >> >> Signed-off-by: Marcelo Tosatti <mtosatti@xxxxxxxxxx> > >> > Can you please be a bit more specific about why we need this? Why does > >> > the host need to provide us with two pages with the exact same data? Why > >> > can't just do it with mapping tricks in the guest? > >> > >> In Xen the pvclock structure is embedded within a pile of other stuff > >> that shouldn't be mapped into guest memory, so providing for a second > >> location allows it to be placed whereever is convenient for the guest. > >> That's a restriction of the Xen ABI, but I don't know if it affects KVM. > >> > >> J > > > > It is possible to share the data for KVM in theory, but: > > > > - It is a small amount of memory. > > - It requires aligning to page size (the in-kernel percpu array > > is currently cacheline aligned). > > - It is possible to modify flags separately for userspace/kernelspace, > > if desired. > > > > This justifies the duplication IMO (code is simple and clean). > > > > What would be the changes required to remove the duplication? If it's > just page alignment, then is seems even smaller. In addition we avoid > expanding the ABI again. This would require changing the kernel copy from percpu data, which there is no guarantee is linear (necessary for fixmap mapping), to dynamically allocated (which in turn can be tricky due to early boot clock requirement). Hum, no thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
