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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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
> > are?
> 
> 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.
> >
> 
> Yes.
> 
> >> 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
> >>   used.
> >>   
> >> +=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?
> 
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003746
> 
> 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.

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)

> > 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
yet?

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

Ian.


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