From: Wen Congyang <wency@xxxxxxxxxxxxxx> Subject: Re: [PATCH v4 2/3] KVM-INTEL: Add new module vmcsinfo-intel to fill VMCSINFO Date: Fri, 6 Jul 2012 16:25:23 +0800 > At 07/06/2012 04:04 PM, HATAYAMA Daisuke Wrote: >> From: Yanfei Zhang <zhangyanfei@xxxxxxxxxxxxxx> >> Subject: [PATCH v4 2/3] KVM-INTEL: Add new module vmcsinfo-intel to fill VMCSINFO >> Date: Wed, 4 Jul 2012 18:05:19 +0800 >> >>> Besides, this patch also exports vmcs revision identifier via >>> /sys/devices/system/cpu/vmcs_id and offsets of fields via >>> /sys/devices/system/cpu/vmcs/. >>> Individual offsets are contained in subfiles named by the filed's >>> encoding, e.g.: /sys/devices/cpu/vmcs/0800 >> >> According to the discussion starting from >> >> http://lkml.indiana.edu/hypermail/linux/kernel/1105.3/00749.html > > IIRC, kvm can not work in such environment. The vcpu can run on > different cpu. If the cpu's vmcs is different, I don't know what > will happen. So do we need to support for such environment now? > I think that if kvm can not work in such environment, we should > not provide vmcs information for each physical cpu. > Ah, I noticed my basic confusion: if it --- vcpu can run on cpus with differnet VMCS revision --- were possible, this vmcsinfo would be unnecessary because it would mean processer could read VMCS data with revision different from its own one or some kind of reverse engineering for convertion of differnet VMCS data were done. I think kvm could probably work if only processors that have the same VMCS revision are assigned to a single guest. But considering the VMCS nature, such processor with differnet revision seems unlikely to be used on host machine. Thanks. HATAYAMA, Daisuke -- 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
