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

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


Which says "Updated Jul 29, 2014", it also does not support being
somewhere other than 0x40000000 .

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


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®.