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: Mon, 08 Sep 2014 18:41:50 -0400 Message-ID: <540E30AE.2040404@terremark.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> <540DD7A4020000780003211F@mail.emea.novell.com> <540DC867.3040209@oracle.com> <540DE7170200007800032248@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <540DE7170200007800032248@mail.emea.novell.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: Jan Beulich , Ian Campbell , Boris Ostrovsky , Don Slutz Cc: Tim Deegan , Kevin Tian , Keir Fraser , Jun Nakajima , Stefano Stabellini , Andrew Cooper , Eddie Dong , xen-devel@lists.xen.org, Aravind Gopalakrishnan , Suravee Suthikulpanit , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 09/08/14 11:27, Jan Beulich wrote: >>>> On 08.09.14 at 17:16, wrote: >> On 09/08/2014 10:21 AM, Jan Beulich wrote: >>>>>> On 08.09.14 at 15:56, 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(). >>> Not exactly - the conclusion rather is to not allow both to become >>> true at the same time. >> I have vague recollection of some Windows products (newer Microsoft >> Server releases?) expecting to run on hypervisor, i.e. Viridian. Would >> such restriction break these? Not directly, newer windows and multiple cpus need viridian to run on xen. We have no plans to adjust xen so that windows without viridian and multiple cpus would work. VMware does all a fall back mode: Testing the virtual BIOS DMI information and the hypervisor port Apart from the CPUID-based method for VMware virtual machine detection, VMware also provides a fallback mechanism for the following reasons: * This CPUID-based technique will not work for guest code running at CPL3 when VT/AMD-V is not available or not enabled. * The hypervisor present bit and hypervisor information leaf are only defined for products based on VMware hardware version 7. Which does require getting data into smbios xenstore entries before running the guest. But does allow use of vmware tools even when cpuid data says viridian. >> Or is this orthogonal to this discussion (assuming I am right about MS >> in the first place)? > The question is whether Windows, when run on VMware, makes use > of the VMware extensions _and_ after being migrated to Xen would > be capable of making use of the Viridian ones. I doubt that, i.e. I'd > assume that until rebooted they'd continue to use VMware's (with > the wild assumption that such a "live" migration is actually possible in > the first place), and they'd prefer using Viridian's after reboot. The > only dependency might be on devices that shouldn't disappear, but > that's independent of the hypervisor side foreign VMM emulation > afaict. Such a "live" migration would need a lot of work, and not clear this topic would apply. Most OSes like to determine what the hardware looks like at boot, and not have it change while they are running. As far as I know for standard windows images the VMware support is not enough with out the guest time faking that VMware does to get windows to work. So for 4.5 I see no issues with saying only viridian or vmware_hw, not both. -Don Slutz > Jan >