On 01/03/2011 06:52 PM, Jan Kiszka wrote:
Am 03.01.2011 17:06, Avi Kivity wrote: > On 01/03/2011 10:33 AM, Jan Kiszka wrote: >> From: Jan Kiszka<jan.kiszka@xxxxxxxxxxx> >> >> First of all, we only need this EPT identity and TSS reservation on >> Intel CPUs. > > kvm-amd will ignore it just fine. I'd like to keep arch differences > away from userspace. And I would prefer to avoid needlessly cluttering the physical guest address space where not needed. Long term, we could even give user space a hint (unless it can test it directly) that this workaround is no longer needed as the host Intel CPU supports true real mode.
Having different physical address spaces based on the host cpu is bad, even disregarding live migration. If there's a real need, we can do it as an option. I don't see such a need though.
We can definitely add a new KVM_CAP for "tss/ept identity supported but not needed". If emulate_invalid_guest_state is eventually fully implemented and becomes the default, it will even be true across the board.
> >> Then, in order to support loading BIOSes> 256K, reorder the >> code, adjusting the base if the kernel supports moving the identity map. >> We can drop the check for KVM_CAP_SET_TSS_ADDR as we already depend on >> much newer features. > > There is no ordering on kvm features. Each can come and go as it pleases. > Well, at least this is not how kvm upstream works so far.
Let's change it then. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
