On 10/29/2012 10: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).
> 
Duplicating is indeed no the end of the world. But one note:

* If it is page-size aligned, it is automatically cacheline aligned.
Since we have to export the user page *anyway*, this is a non-issue.

That said, duplicating instead of integrating, which is technically
possible, is a design decision, and it needs to be documented somewhere
aside from this mail thread.



--
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