On 10/31/2012 07:12 AM, Marcelo Tosatti wrote:
> 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 <[email protected]>
>>>>> 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.
>
You allocate it using bootmemory for vsyscall anyway. If they are
strictly in the same physical location, you are not allocating anything
extra.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
