>>> On Wed, Mar 5, 2008 at 5:38 PM, in message
<20080305223827.GI19306@xxxxxxxxxx>, "Daniel P. Berrange" <berrange@xxxxxxxxxx>
wrote: 
> On Wed, Mar 05, 2008 at 10:28:28PM +0000, Daniel P. Berrange wrote:
>> On Wed, Mar 05, 2008 at 03:15:19PM -0700, Ky Srinivasan wrote:
>> > I am attaching updated versions of the patches that I posted a couple 
>> > of weeks ago. These have been merged up to the current unstable tip: 
>> > changeset 17186:854b0704962b
>> > 
>> > These patches have been tested on the unstable tip.
>> 
>> I'm not expert enough to comment on the HV extension implementation itself,
>> but in terms of the userspace side, the user visible configuration file 
>> option 'extid=1' is pretty unpleasant. It is akin to a 'magic constant'
>> in C code - no understandable meaning at all.
>> 
>> I'd like to see it accept a named extension type - if its possible to
>> have multiple extensions per guest, then using a list instead of a scalar
>> would be better. So how about something closer to
>> 
>> extensions = [ "win2k8" ]
>
> Or is there some way you can have some super light weight trap / hook
> always loaded, so when Win2k8 makes it first paravirt call, you can
> then automatically enable the full extension ? That could let Xen
> just 'do the right thing' without needing a config param, and without
> having to fully enable the full extension for non-Win2k8 guests.
I considered this. Unfortunately, we have no control on the mechanisms used by 
windows to discover the hypervisor. Furthermore, CPUID leaves used by longhorn 
collide with CPUID leaves used by Xen for supporting hypervisor discovery for 
PV drivers. Since we have no control on what Microsoft may do here, I felt the 
best way might be to tag the guest so that we can interpret the hypercalls, 
CPUID calls and MSR (read/write) calls within the guest namespace.
Regards,
K. Y
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel