From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH v2 1/3] Add vmware_hw to xl.cfg Date: Tue, 09 Sep 2014 13:02:24 -0400 Message-ID: <540F32A0.2070609@terremark.com> References: <1409585629-25840-1-git-send-email-dslutz@verizon.com> <1409585629-25840-2-git-send-email-dslutz@verizon.com> <1410182256.3680.16.camel@kazak.uk.xensource.com> <540E00AB.1000501@terremark.com> <1410255568.8217.65.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1410255568.8217.65.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Don Slutz Cc: Kevin Tian , Keir Fraser , Eddie Dong , Stefano Stabellini , Andrew Cooper , Tim Deegan , xen-devel@lists.xen.org, Jan Beulich , Aravind Gopalakrishnan , Jun Nakajima , Suravee Suthikulpanit , Boris Ostrovsky , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 09/09/14 05:39, Ian Campbell wrote: > On Mon, 2014-09-08 at 15:16 -0400, Don Slutz wrote: >> On 09/08/14 09:17, Ian Campbell wrote: >>> On Mon, 2014-09-01 at 11:33 -0400, Don Slutz wrote: >>>> If non-zero then >>>> Return VMware's cpuid leaves. >>>> Not doing the hardcoded IRQ9 on PIIX4 ACPI PM. >>> Please can you say a words about why this is and what the implications >>> are? >> Duplicate -- windows activation. >> >>>> Force use of VMware's VGA in QEMU. >>>> >>>> The support of hypervisor cpuid leaves has not been agreed to. >>> Who needs to agree to this? Just us or do we need to be seeking >>> consensus with other hypervisors? >> Possible consensus with other hypervisors. The 2 that are an issue >> if MicroSoft (Hyper-V, viridian) and VMware. Xen is not the issue. >> >> >>>> So based on this, I picked the order: >>>> >>>> 0x40000000 is viridian, vmware or xen >>>> 0x40000100 is vmware or xen >>>> 0x40000200 is xen >>> Which is another way of saying that the enabled options will be >>> presented in the order viridian, vmware, xen. >>> >> Yes. >> >>>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 >>>> index f1fc906..34fb021 100644 >>>> --- a/docs/man/xl.cfg.pod.5 >>>> +++ b/docs/man/xl.cfg.pod.5 >>>> @@ -1139,6 +1139,12 @@ some other Operating Systems and in some circumstance can prevent >>>> Xen's own paravirtualisation interfaces for HVM guests from being >>>> used. >>>> >>>> +=item B >>>> + >>>> +Turns on or off the exposure of VMware cpuid. The number is the >>>> +VMware's hardware version number, where 0 is off. If on it also >>>> +forces the use of VMware's VGA in QEMU. >>> Do you have a reference of the non-zero values of this field? How can a >>> user determine what the correct number to use is? >> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003746 >> >> For most uses, any non-zero is good enough. Where it matters is how >> QEMU presents emulated hardware. VMware changes pci config space >> based on this number which is stored in a .vmx file. >> >> Is vmware_hw too short? Should I use vmware_virtual_hardware_version? >> >> or just adjust the xl.cfg.pod.5 description? > Just updating the description to give users some clue as to what number > they should use would be enough. How does the following look: vmware_hw numbers come from VMware config files. In a .vmx it is virtualHW.version In a .ovf it is part of the value of vssd:VirtualSystemType for vssd:VirtualSystemType == vmx-07, vmware_hw = 7 Should I refer them to the vmware web site? > I think you are implying that there are occasions where a user would > care about which specific value is used, so turning this into a boolean > isn't good enough. But an enum might be appropriate. (see below) Yes, a boolean is not enough. >>> Other than parroting this value back to the guest in a cpuid leaf does >>> this value control anything else? If so then we may want to consider >>> something like an enum to allow us to advertise more precisely which >>> versions of vmware we are prepared to ape, but at the least we need to >>> range check this input somewhere along the way. >> See above, mostly just QEMU. > What does qemu do with a number which it doesn't understand, perhaps > corresponding to a newer vmware version which it hasn't learnt about > yet? My version currently checks for various ranges. Like != 0, >= 4, >= 4 && < 7, >= 7. I do not expect that I can upstream it with this, but it should be similar. > This sort of issue is why I was proposing an enum, or at least some sort > of range checking. Since most of the use is in QEMU, I see no need for an enum in xen. All xen uses I know of are == 0 or != 0. I can add some range checking but think a warning might be better so that a newer QEMU with support for a given value could be used with an older xen without change to xen. -Don Slutz > Ian. >