|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH] cpuid handling for guest
To: |
"Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx> |
Subject: |
[Xen-devel] Re: [PATCH] cpuid handling for guest |
From: |
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> |
Date: |
Mon, 12 Jun 2006 09:52:03 +0100 |
Cc: |
"Mallick, Asit K" <asit.k.mallick@xxxxxxxxx>, Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, "Yu, Wilfred" <wilfred.yu@xxxxxxxxx> |
Delivery-date: |
Mon, 12 Jun 2006 01:52:18 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<5461330FA59EDB46BE9AB8AAF2C431AD2AC6F8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<5461330FA59EDB46BE9AB8AAF2C431AD2AC6F8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
On 9 Jun 2006, at 21:12, Kamble, Nitin A wrote:
Hi Keir, Ian,
Attached is a patch to provide right view of cpuid to the HVM
guests. Some of the CPU features such as APIC, PAE, MTRR, HT are
virtualized; while others are not virtualized yet such as TM1, TM2,
MCA and there are some features which do not need virtualization such
as MMX. With the patch Guest sees only those processor features in the
cpuid which are virtualized in the hyper visor, or do not need any
virtualization in hyper visor.
Accepted because it's fine as far as it goes, but this emulation of
CPUID is unsafe because you do not restrict the 'max leaf' values (as
returned in %eax by 0x0 and 0x80000000). So current HVM support cannot
be guaranteed to work on future processors because they may have extra
info leaves that you do not filter and emulate properly (because the
code cannot know about them).
At the very least you should be restricting max leaves to 0xA and
0x80000008 (highest documented leaves so far). You should also emulate
native behaviour of returning info of max basic leaf for invalid CPUID
indexes.
But, while doing this you may as well make your lives easier and only
advertise max leaves 0x3 and 0x80000004. This will avoid hassle of
properly emulating other leaves, many of which contain performance info
that may not be valid across save/restore and migration anyway.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|