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 <mtosa...@redhat.com>
>> > 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.

-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to