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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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,<dslutz@xxxxxxxxxxx>  wrote:
>>>>>> On 09/02/14 03:28, Jan Beulich wrote:
>>>>>>>>>> On 01.09.14 at 17:33,<dslutz@xxxxxxxxxxx>  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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel