[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 09/08/2014 10:21 AM, Jan Beulich wrote:
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.

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?

Or is this orthogonal to this discussion (assuming I am right about MS in the first place)?

-boris

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.