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

[Don Slutz <dslutz@xxxxxxxxxxx>]

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

    -Don Slutz


> Ian.

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