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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.09.14 at 15:56, <dslutz@xxxxxxxxxxx> 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().

Not exactly - the conclusion rather is to not allow both to become
true at the same time.

Jan


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