[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/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
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

    -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

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):


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


Xen-devel mailing list

Xen-devel mailing list



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