qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH v2 16/17] kvm: x86: Rework identity map and TSS


From: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH v2 16/17] kvm: x86: Rework identity map and TSS setup for larger BIOS sizes
Date: Mon, 03 Jan 2011 18:59:49 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

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<address@hidden>
>>
>>  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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]