From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v2 1/3] Add vmware_hw to xl.cfg Date: Tue, 09 Sep 2014 00:34:47 +0100 Message-ID: <540E3D17.8040508@citrix.com> References: <1409585629-25840-1-git-send-email-dslutz@verizon.com> <1409585629-25840-2-git-send-email-dslutz@verizon.com> <54058DC3020000780002FB1D@mail.emea.novell.com> <54060B5C.30205@terremark.com> <5406E32802000078000300E2@mail.emea.novell.com> <1410182429.3680.18.camel@kazak.uk.xensource.com> <540DB5A7.5060804@terremark.com> <540DB822.1080603@citrix.com> <540E2988.5000101@terremark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <540E2988.5000101@terremark.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: Don Slutz , Ian Campbell , Jan Beulich Cc: Kevin Tian , Keir Fraser , Jun Nakajima , Stefano Stabellini , Tim Deegan , Eddie Dong , xen-devel@lists.xen.org, Aravind Gopalakrishnan , Suravee Suthikulpanit , Boris Ostrovsky , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 08/09/2014 23:11, Don Slutz wrote: > On 09/08/14 10:07, Andrew Cooper wrote: >> On 08/09/14 14:56, Don Slutz wrote: >>> On 09/08/14 09:20, Ian Campbell wrote: >>>> On Wed, 2014-09-03 at 08:45 +0100, Jan Beulich wrote: >>>>>>>> On 02.09.14 at 20:24, wrote: >>>>>> On 09/02/14 03:28, Jan Beulich wrote: >>>>>>>>>> On 01.09.14 at 17:33, wrote: >>>>>>>> So based on this, I picked the order: >>>>>>>> >>>>>>>> 0x40000000 is viridian, vmware or xen >>>>>>>> 0x40000100 is vmware or xen >>>>>>>> 0x40000200 is xen >>>>>>> Is there really a point in enabling both Viridian and VMware >>>>>>> extensions >>>>>>> at the same time? >>>>>> Not that I know of (and I do not want to say there there is no code >>>>>> out there that can work with both). Instead of an error or warning >>>>>> I went with what xen is currently doing and that seabios was happy >>>>>> to find xen at 0x40000200. >>>>>> >>>>>> If the consensus is to ignore, or report an error or warning I will >>>>>> go that >>>>>> way. For now I am not planning on changing. >>>>> My personal take on this is that the hypervisor (or perhaps already >>>>> the tools) should reject enabling both at the same time. >>>> That sounds sensible to me. >>>> >>>> Generally we seem to have the hypervisor check these things as a >>>> backstop, to stop broken tools, but also check in the tools so we can >>>> give a better error message. >>>> >>> Ok, with 2 votes this way how about (for v4) I will drop the change to >>> xen/arch/x86/traps.c (I.E. 0x40000100 will be xen) And change >>> >>> cpuid_vmware_leaves to return 0 if is_viridian_domain(). >>> >>> And add some logic in the and doc in the tools patch to do this error >>> message. >>> >>> -Don Slutz >> I expect that Vmware will expose viridian to windows domains, as it is >> the only supported Microsoft way of doing doing virt for windows. >> Therefore it is entirely plausible that both could need to be active at >> once. (Although this does depend on whether the vmware leaf supports >> being somewhere other than 0x40000000, as the viridian leaf certainly >> doesn't.) > > As far as I can tell, VMware does not expose viridian to windows > domains. As I understand it they adjust the time that guest sees > so that windows does not BSOD 101. > > I only see VMware on ESXi 4.1.0, they may have added this in newer > versions. And (from the commit message which the following url:) > > > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458 > > > Which says "Updated Jul 29, 2014", it also does not support being > somewhere other than 0x40000000 . Hmm - that's interesting, and does simplify matters. In which case the current set of allowable leaves are: Xen at 0x40000000 or Viridian or Vmware at 0x40000000 and Xen at 0x40000100 Perhaps a doc in docs/misc/hypervisor-cpuid.{markdown/pandoc} explaining this? (or more appropriate name if applicable; pandoc being dependent on my migration v2 docs changes, although trivial to backport.) > > >> Either way, the current 0x4000xxxx leaf handling is somewhat special in >> Xen, as the viridian support was hacked in after the Xen leafs were >> already present. It is one area I was planning to fix up as part of my >> cpuid levelling work for 4.6 > > Ok. I just need to know what to provide for 4.5 -- which seems to be > allow only viridian or vmware_hw but not both. > > -Don Slutz Seems reasonable to me at this juncture. ~Andrew