On Fri, Dec 16, 2016 at 07:03:49PM +0000, Andrew Cooper wrote:
> On 16/12/16 13:43, Haozhong Zhang wrote:
> > diff --git a/include/arch/x86/hvm/vmx/vmcs.h 
> > b/include/arch/x86/hvm/vmx/vmcs.h
> > new file mode 100644
> > index 0000000..e1a6ef8
> > --- /dev/null
> > +++ b/include/arch/x86/hvm/vmx/vmcs.h
> > @@ -0,0 +1,179 @@
> > +#ifndef XTF_X86_HVM_VMX_VMCS_H
> > +#define XTF_X86_HVM_VMX_VMCS_H
> > +
> > +/* VMCS field encodings. */
> > +#define VMCS_HIGH(x) ((x) | 1)
> > +enum vmcs_field {
> > +    VIRTUAL_PROCESSOR_ID            = 0x00000000,
> > +    POSTED_INTR_NOTIFICATION_VECTOR = 0x00000002,
> > +    EPTP_INDEX                      = 0x00000004,
> > +#define GUEST_SEG_SELECTOR(sel) (GUEST_ES_SELECTOR + (sel) * 2) /* ES ... 
> > GS */
> 
> Unfortunately, there is probably a BSD/GPL licensing issue here.
> 
> XTF is BSD clause 2 licensed, because a lot of the core microkernel bits
> are generally useful to other microkernel projects, and I have specific
> plans to contribute improvements back to the likes of Mini-OS and
> HVMLoader.  I would specifically like to maintain this property.
> 
> Xen, following its Linux heritage, is strictly GPLv2 (other than the
> public headers, which are specifically different).

IANAL, but it seems quite weird to me that a set of defines or enums (without
any logic behind) can be put under a specific license, which seems to be the
case here. Certainly this is publicly available on the SDM, and it won't be
surprising for someone to code them in the exact same way AFAICT.

Roger.

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

Reply via email to