Re: [RFC] Paravirt timer for KVM

Glauber de Oliveira Costa
2007-10-16T01:15:32Z

> The basic issue is that on many architectures, the hardware MMU does
> *not* hold all mappings, and even if it does, performing MMU translation
> in software can be prohibitively complicated and slow. As a worst-case
> scenario, consider a software-controlled TLB which can hold a small
> finite number of simultaneous mappings. On the embedded PowerPC 440
> cores I'm working on, that number is 64. There is no hardware table
> walker.
>
> That means that if the hypervisor is passed a virtual address, it may
> not be present in the MMU at all. Ordinarily the hardware would deliver
> a TLB miss interrupt to the kernel, and the kernel would insert the
> appropriate mapping (as calculated or found in software-only data
> structures). However, consider the locking nightmare if the hypervisor
> delivers an interrupt while "inside" a guest hypercall...

that makes a lot of sense, thank you for the explanation.

> Longs everywhere. :) And not just that, but you are cementing this
> particular layout of timespec into the guest ABI. There is nothing to
> prevent Linux from changing timespec in some future version...

Yeah, have figured it out.
I think I'll stick to two fields then, with u64 for seconds and nanoseconds.
Or would it just be better to use a u64 nanoseconds field?

A _lot_ of time should have passed before such counter overflows. So
having two is possibly overkill.

--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."