> 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." ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
