[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/09/14 05:39, Ian Campbell wrote:
On Mon, 2014-09-08 at 15:16 -0400, Don Slutz wrote:
On 09/08/14 09:17, Ian Campbell wrote:
On Mon, 2014-09-01 at 11:33 -0400, Don Slutz wrote:
If non-zero then
    Return VMware's cpuid leaves.
    Not doing the hardcoded IRQ9 on PIIX4 ACPI PM.
Please can you say a words about why this is and what the implications
Duplicate -- windows activation.

    Force use of VMware's VGA in QEMU.

The support of hypervisor cpuid leaves has not been agreed to.
Who needs to agree to this? Just us or do we need to be seeking
consensus with other hypervisors?
Possible consensus with other hypervisors.    The 2 that are an issue
if MicroSoft (Hyper-V, viridian) and VMware.  Xen is not the issue.

So based on this, I picked the order:

0x40000000 is viridian, vmware or xen
0x40000100 is vmware or xen
0x40000200 is xen
Which is another way of saying that the enabled options will be
presented in the order viridian, vmware, xen.


diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index f1fc906..34fb021 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1139,6 +1139,12 @@ some other Operating Systems and in some circumstance 
can prevent
   Xen's own paravirtualisation interfaces for HVM guests from being
+=item B<vmware_hw=NUMBER>
+Turns on or off the exposure of VMware cpuid.  The number is the
+VMware's hardware version number, where 0 is off.  If on it also
+forces the use of VMware's VGA in QEMU.
Do you have a reference of the non-zero values of this field? How can a
user determine what the correct number to use is?

For most uses, any non-zero is good enough.  Where it matters is how
QEMU presents emulated hardware.  VMware changes pci config space
based on this number which is stored in a .vmx file.

Is vmware_hw too short?  Should I use vmware_virtual_hardware_version?

or just adjust the xl.cfg.pod.5 description?
Just updating the description to give users some clue as to what number
they should use would be enough.

How does the following look:

  vmware_hw numbers come from VMware config files.

  In a .vmx it is virtualHW.version

  In a .ovf it is part of the value of vssd:VirtualSystemType

  for vssd:VirtualSystemType == vmx-07, vmware_hw = 7

Should I refer them to the vmware web site?

I think you are implying that there are occasions where a user would
care about which specific value is used, so turning this into a boolean
isn't good enough. But an enum might be appropriate. (see below)

Yes, a boolean is not enough.

Other than parroting this value back to the guest in a cpuid leaf does
this value control anything else? If so then we may want to consider
something like an enum to allow us to advertise more precisely which
versions of vmware we are prepared to ape, but at the least we need to
range check this input somewhere along the way.
See above, mostly just QEMU.
What does qemu do with a number which it doesn't understand, perhaps
corresponding to a newer vmware version which it hasn't learnt about

My version currently checks for various ranges.  Like != 0, >= 4,
>= 4 && < 7, >= 7.  I do not expect that I can upstream it with this,
but it should be similar.

This sort of issue is why I was proposing an enum, or at least some sort
of range checking.

Since most of the use is in QEMU, I see no need for an enum in xen.
All xen uses I know of are == 0 or != 0.  I can add some range checking
but think a warning might be better so that a newer QEMU with support
for a given value could be used with an older xen without change to

    -Don Slutz


Xen-devel mailing list



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