Re: [PATCH v2 1/3] Add vmware_hw to xl.cfg

[Don Slutz <dslutz@verizon.com>]

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, <dslutz@verizon.com> wrote:
>>>>> On 09/02/14 03:28, Jan Beulich wrote:
>>>>>>>>> On 01.09.14 at 17:33, <dslutz@verizon.com> 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.  They also adjust more things
so windows "works".  Going with viridian is much better.

I only see VMware on ESXi 4.1.0, they may have added this in newer
versions.  And (from the commit message's 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.

Xen is the only one that I know of that current supports being
somewhere other than 0x40000000.

So I am happy to go with "only one of viridian or vmware_hw can
be non-zero".  Just need to know which way to go.

    -Don Slutz


> 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
>
> ~Andrew
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel